Настройка репликации в Mysql 5.6

    После выхода mysql 5.6 с его GTID (global transaction identifier) репликация в mysql перестала быть кошмарным сном сисадмина и стала вполне рабочим инструментом. В инете есть некоторое количество информации по этому поводу, но вся она довольно разрозненная и не всегда доступна для понимания. По этому я решил сделать небольшую инструкцию-выжимку, больше для себя, но может и еще кому пригодится.


    Настройка мастера
    У меня довольно тепличные условия, и база пустая, дамп будем вливать после настройки

    my.cnf

    binlog-format=ROW

    Бывает трех видов — STATEMENT, MIXED и ROW
    В двух словах — statement пишет в бинлог по сути sql запросы. Преимущества — старый формат, оттестированный, лог небольшой, можно посмотреть запросы. Недостатки — проблемы с функциями и триггерами, запросы вида update user set a=1 order by rand(), а так же еще некоторые могут некорректно отрабатываться. ROW если совсем упрощенно — пишет в логи измененные бинарные данные. Преимущества — отлично логируются все виды запросов. Недостатки — огромный лог.Ну и mixed — промежуточный формат, который старается использовать statement, когда возможно, а когда нет — row. Говорят, что глючит на каких то очень сложных запросах. Именно его я и рискнул использовать

    binlog-checksum=crc32
    Новая фича mysql5.6, вроде как ускоряет работу бинлога

    gtid-mode=on
    Собственно и включает ту самую GTID mode репликацию

    enforce-gtid-consistency=true
    Запрещает все, что может поломать транзакции.

    log-slave-updates=true
    В родной документации написано: указывает подчиненному серверу, чтобы тот вел записи об обновлениях, происходящих на подчиненном сервере, в двоичном журнале. По умолчанию эта опция выключена. Ее следует включить, если требуется организовать подчиненные серверы в гирляндную цепь.

    server-id = 1
    Уникальный номер для каждого сервера

    ну и не забываем указать что именно мы будем реплицировать —
    replicate-do-db = mybase
    replicate-do-table=mybase.mytable1
    replicate-do-table=mybase.mytable2


    После этого необходимо создать пользователя mysql с правами репликации. Например так GRANT replication slave ON *.* TO «replication»@'192.168.1.102' IDENTIFIED BY 'password';

    На этом настройка мастера закончена. Вливаем дамп и в бой )

    Настройка слейва

    В простейшем варианте на слейв можно скопировать тот же конфиг, что и на мастере, единственное что — нужно сменить server_id, например на 2.

    Перезапускаем слейв, и запускаем репликацию

    change master to master_host='192.168.1.1", master_auto_position=1, Master_User=’replication’, master_password=’password';
    start slave;

    и любуемся

    show slave status \G
    Share post

    Comments 23

      0
      А где указания файла бинлога и позиции в нем?
        +1
        В том то и прикол, что в 5.6 с появлением GTID это не нужно…
          0
          Если я правильно понял выдержку из документации, то либо мы указываем MASTER_LOG_FILE и MASTER_LOG_POS, либо MASTER_AUTO_POSITION
            0
            Примерно так. В пером случае gtid репликация не используется
        +1
        А я уж подумал мастер-мастер репликация, а тут мастер-слейв…
          +1
          GTID позволяет не просто мастер-мастер репликацию, а мастер-мастер репликацию с произвольной топологией. Правда, сам я настраивал такое только в MariaDB 10, там синтаксис немного отличается.

          Жду теперь релиза MariaDB 10.1, там возможен мультидоменный GTID, это позволит простым способом один хост использовать в нескольких кластерах.
            0
            Увы, пока такой возможности нет ((
            А что Вы имели в виду под репликацией с произвольной топологией?
              +2
              Произвольная топология — это когда сервера соединяются не в кольцо (как было раньше: А —> Б —> В —> Г —> А) и не звездой вокруг выделенного сервера ( А <—> Б; А <—> В; А <—> Г), а в произвольном порядке. Например, А <—> Б <—> В <—> Г; Б <—> Д; В <—> Е. И изменения на любом из серверов разойдутся по всему кластеру.
                0
                Но это должна быть очень грамотно придуманная база, иначе при рассинхронизации схемы проще всего будет застрелиться )
                  0
                  Ну, чтобы избежать конфликтов ID, можно использовать UUID или auto_increment_increment/auto_increment_offset.

                  А при сбоях при копировании данных можно воспользоваться pt-table-sync.

                  В общем, задача не такая страшная :)



                  Для меня куда сложнее вопрос файловой синхронизации. Кластерные ФС отвратительно работают на разнесённых датацентрах. Приходится пользоваться lsyncd.
            0
            Это вообще решается в рамках My? Как там с фрагментацией (по колонкам и столбцам), есть ли фильтрация как в MS?
              0
              Вот-вот. Мастер-мастер интереснее. И мультимастер.
              0
              Для мастер-мастер репликации могу посоветовать посмотреть в сторону Galera, легко настраивается, хорошо работает.
              Лично я очень доволен этим решением.
              0
              del
                –1
                Будет ли обзор Mariadb vs Postgresql? По следам данной статьи
                  0
                  Это конечно крутое изменение, что не нужно указывать позиций.
                  Но я бы не сказал бы что их указывать было так тяжело.

                  Приятная мелочь, конечно.
                    0
                    Еще куча приятных мелочей появилась при отслеживании и лечении поломок
                      0
                      Приведите пример.
                        0
                        Например восстановление после сбоев. Манипулируем не абстрактным position, а вполне реальной и понятной транзакцией. Еще есть percona toolkit, в котором что то про это было интересное, но я ее рассматривал довольно обзорно
                    0
                    Погодите, я отстал от жизни. А как же момент заливки дампа на слейв? Раньше кошмар заключался в том что надо было стопарить мастер как минимум на время снятия дампа для слейва, запоминать позицию, заливать дамп на слейв и говорить с какой позиции лога стартовать. Ну ладно, теперь можно позицию не запоминать, но что это меняет?
                      +1
                      Если используем что-то типа xtrabackup, мастер останавливать не надо. Innobackupex сам его остановит в нужный момент для финализации изменений и копирования MyISAM-таблиц. Если MyISAM данных много, время простоя будет ощутимым.
                        0
                        если мы начинаем с чистой базы, то слейв вольется сам. А позицию запоминать не нужно, она будет сохранена в дампе

                    Only users with full accounts can post comments. Log in, please.