Настройка мастера
У меня довольно тепличные условия, и база пустая, дамп будем вливать после настройки
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
Комментарии (22)
tarasius
17.07.2015 22:54+1А я уж подумал мастер-мастер репликация, а тут мастер-слейв…
Bal
18.07.2015 09:54+1GTID позволяет не просто мастер-мастер репликацию, а мастер-мастер репликацию с произвольной топологией. Правда, сам я настраивал такое только в MariaDB 10, там синтаксис немного отличается.
Жду теперь релиза MariaDB 10.1, там возможен мультидоменный GTID, это позволит простым способом один хост использовать в нескольких кластерах.
greenh Автор
18.07.2015 10:55Увы, пока такой возможности нет ((
А что Вы имели в виду под репликацией с произвольной топологией?Bal
18.07.2015 11:39+2Произвольная топология — это когда сервера соединяются не в кольцо (как было раньше: А —> Б —> В —> Г —> А) и не звездой вокруг выделенного сервера ( А <—> Б; А <—> В; А <—> Г), а в произвольном порядке. Например, А <—> Б <—> В <—> Г; Б <—> Д; В <—> Е. И изменения на любом из серверов разойдутся по всему кластеру.
greenh Автор
18.07.2015 13:30Но это должна быть очень грамотно придуманная база, иначе при рассинхронизации схемы проще всего будет застрелиться )
Bal
24.07.2015 08:52Ну, чтобы избежать конфликтов ID, можно использовать UUID или auto_increment_increment/auto_increment_offset.
А при сбоях при копировании данных можно воспользоваться pt-table-sync.
В общем, задача не такая страшная :)
…
Для меня куда сложнее вопрос файловой синхронизации. Кластерные ФС отвратительно работают на разнесённых датацентрах. Приходится пользоваться lsyncd.
MacIn
18.07.2015 13:41Это вообще решается в рамках My? Как там с фрагментацией (по колонкам и столбцам), есть ли фильтрация как в MS?
Gular
18.07.2015 15:55Вот-вот. Мастер-мастер интереснее. И мультимастер.
TheRaven
19.07.2015 03:15+1GTID для этого и придумали, посмотрите доклад Осипова Константина на failoverconf
видео www.youtube.com/watch?v=v68l2YOur5M
pdf failoverconf.ru/upload/iblock/dc5/05_Osipov.pdf
dmiceman
19.07.2015 19:14Погодите, я отстал от жизни. А как же момент заливки дампа на слейв? Раньше кошмар заключался в том что надо было стопарить мастер как минимум на время снятия дампа для слейва, запоминать позицию, заливать дамп на слейв и говорить с какой позиции лога стартовать. Ну ладно, теперь можно позицию не запоминать, но что это меняет?
winduzoid
19.07.2015 20:54+1Если используем что-то типа xtrabackup, мастер останавливать не надо. Innobackupex сам его остановит в нужный момент для финализации изменений и копирования MyISAM-таблиц. Если MyISAM данных много, время простоя будет ощутимым.
greenh Автор
19.07.2015 23:11если мы начинаем с чистой базы, то слейв вольется сам. А позицию запоминать не нужно, она будет сохранена в дампе
script88
А где указания файла бинлога и позиции в нем?
greenh Автор
В том то и прикол, что в 5.6 с появлением GTID это не нужно…
script88
Если я правильно понял выдержку из документации, то либо мы указываем MASTER_LOG_FILE и MASTER_LOG_POS, либо MASTER_AUTO_POSITION
greenh Автор
Примерно так. В пером случае gtid репликация не используется