Mysql Server1 работает как МАСТЕР.
Mysql Server2 работает как SLAVE.
Теперь репликация DB происходит от МАСТЕР до SLAVE.
Server2 удаляется из сети и повторно подключается через 1 день. После этого существует несоответствие в базе данных в master и slave.
Как повторно синхронизировать БД еще раз, так как после восстановления БД, взятого с Master на Slave, также не решается проблема?
Это полная пошаговая процедура для повторной синхронизации репликации master-slave с нуля:
У ведущего:
RESET MASTER;
FLUSH TABLES WITH READ LOCK;
SHOW MASTER STATUS;
И скопируйте значения результата последней команды где-нибудь.
Без закрытия соединения с клиентом (поскольку он освободит блокировку чтения) выпустите команду для получения дампа мастера:
mysqldump -u root -p --all-databases > /a/path/mysqldump.sql
Теперь вы можете освободить блокировку, даже если дамп еще не закончился. Чтобы сделать это, выполните следующую команду в клиенте MySQL:
UNLOCK TABLES;
Теперь скопируйте файл дампа в подчиненное устройство с помощью scp или вашего предпочтительного инструмента.
В подчиненном устройстве:
Откройте соединение с mysql и введите:
STOP SLAVE;
Загрузите мастер-данные с этой консольной командой:
mysql -uroot -p < mysqldump.sql
Синхронизировать ведомые и ведущие журналы:
RESET SLAVE;
CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=98;
Если значения вышеуказанных полей - это те, которые вы скопировали ранее.
Наконец, введите:
START SLAVE;
Чтобы проверить, что все работает снова, после ввода:
SHOW SLAVE STATUS;
вы должны увидеть:
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Что это!
Документация для этого на сайте MySQL ужасно устарела и пронизана ножными пушками (например, interactive_timeout). Выдача FLUSH TABLES WITH READ LOCK в качестве части вашего экспорта мастера обычно имеет смысл только при согласовании с моментальным снимком хранилища/файловой системы, таким как LVM или zfs.
Если вы собираетесь использовать mysqldump, вы должны полагаться вместо этого на опцию --master-data для защиты от человеческой ошибки и как можно быстрее освобождать блокировки на главном сервере.
Предположим, что мастер - 192.168.100.50, а подчиненный - 192.168.100.51, каждый сервер имеет отдельный идентификатор сервера, мастер имеет двоичный вход в систему, а ведомое устройство имеет только чтение = 1 в my.cnf
Чтобы подчинить ведомому устройству возможность запуска репликации сразу после импорта дампа, выполните команду CHANGE MASTER, но оставьте имя и положение файла журнала:
slaveserver> CHANGE MASTER TO MASTER_HOST='192.168.100.50', MASTER_USER='replica', MASTER_PASSWORD='asdmk3qwdq1';
Выдать GRANT на ведущем устройстве для использования ведомым:
masterserver> GRANT REPLICATION SLAVE ON *.* TO 'replica'@'192.168.100.51' IDENTIFIED BY 'asdmk3qwdq1';
Экспортируйте мастер (на экране) с помощью сжатия и автоматически фиксируйте правильные двоичные лог-координаты:
mysqldump --master-data --all-databases --flush-privileges | gzip -1 > replication.sql.gz
Скопируйте файл replication.sql.gz в подчиненное устройство и затем импортируйте его с помощью zcat в экземпляр MySQL, запущенного на подчиненном устройстве:
zcat replication.sql.gz | mysql
Запустите репликацию, отправив команду ведомому:
slaveserver> START SLAVE;
Необязательно обновить /root/.my.cnf на подчиненном устройстве, чтобы сохранить тот же пароль root, что и главный.
Если вы находитесь на 5.1+, лучше сначала установить мастер binlog_format в MIXED или ROW. Остерегайтесь, что события, записанные в журнале, медленны для таблиц, у которых отсутствует первичный ключ. Обычно это лучше, чем альтернативная (и по умолчанию) конфигурация инструкции binlog_format = (на главном), поскольку она менее вероятна для получения неверных данных на ведомом.
Если вы должны (но, вероятно, не должны) фильтровать репликацию, сделайте это с помощью slave-параметров replicate-wild-do-table = dbname.% или replicate-wild-ignore-table = badDB.% и используйте только binlog_format = row
Этот процесс будет удерживать глобальную блокировку мастера в течение всего времени выполнения команды mysqldump, но в противном случае не повлияет на мастер.
Если у вас возникли соблазны использовать mysqldump -master-data -all-databases -single-transaction (потому что вы используете только таблицы InnoDB), вам, возможно, лучше всего удается использовать MySQL Enterprise Backup или реализацию с открытым исходным кодом под названием xtrabackup (любезно предоставлено Перконой)
Если вы не пишете непосредственно на подчиненном устройстве (Server2), единственная проблема должна заключаться в том, что Server2 не имеет никаких обновлений, которые произошли с момента его отсоединения. Просто перезапустите рабочую станцию с помощью "START SLAVE"; должен получить все обратно к скорости.
Я думаю, Мааткит помогает тебе! Вы можете использовать mk-table-sync. См. Эту ссылку: http://www.maatkit.org/doc/mk-table-sync.html
Вот что я обычно делаю, когда подчиненное устройство mysql выходит из синхронизации. Я посмотрел на mk-table-sync, но подумал, что раздел "Риски" страшно выглядит.
На Мастере:
SHOW MASTER STATUS
Выведенные столбцы (File, Position) будут нам полезны.
В Slave:
STOP SLAVE
Затем выгрузите master db и импортируйте его в ведомый db.
Затем запустите следующее:
CHANGE MASTER TO
MASTER_LOG_FILE='[File]',
MASTER_LOG_POS=[Position];
START SLAVE;
Где [Файл] и [Позиция] - значения, выводимые из "SHOW MASTER STATUS", выше.
Надеюсь, это поможет!
В ответ на ответ Дэвида...
Использование SHOW SLAVE STATUS\G даст читаемый человеком вывод.
Я очень опоздал на этот вопрос, однако я столкнулся с этой проблемой, и после долгих поисков я нашел эту информацию у Брайана Кеннеди: http://plusbryan.com/mysql-replication-without-downtime
На Мастер сделать резервную копию, как это:
mysqldump --skip-lock-tables - одна транзакция --flush-logs --hex-blob --master-data = 2 -A> ~/dump.sql
Теперь проверьте заголовок файла и запишите значения для MASTER_LOG_FILE и MASTER_LOG_POS. Они понадобятся вам позже: head dump.sql -n80 | grep "MASTER_LOG"
Скопируйте файл "dump.sql" в Slave и восстановите его: mysql -u mysql -u ser -p <~/dump.sql
Подключитесь к ведомому mysql и выполните команду, подобную этой: CHANGE MASTER TO MASTER_HOST = 'master-server-ip', MASTER_USER = 'replication -u ser', MASTER_PASSWORD = 'slave-server -p assword', MASTER_LOG_FILE = 'value сверху ', MASTER_LOG_POS = значение сверху; НАЧАТЬ РАБА;
Чтобы проверить прогресс Раба: ПОКАЗАТЬ СТАТУС РАБА;
Если все хорошо, Last_Error будет пустым, и Slave_IO_State сообщит "Ожидание, когда мастер отправит событие". Ищите Seconds_Behind_Master, который указывает, насколько далеко он позади. YMMV. :)
Вот полный ответ, который, надеюсь, поможет другим...
Я хочу настроить репликацию mysql с помощью master и slave, и поскольку единственное, что я знал, это то, что он использует файлы журналов для синхронизации, если подчиненный переходит в автономный режим и выходит из синхронизации, теоретически он должен чтобы подключиться к своему ведущему и продолжить чтение файла журнала с того места, где он был остановлен, как упоминалось пользователем.
Итак, вот результат теста после настройки ведущего и ведомого, как указано: http://dev.mysql.com/doc/refman/5.0/en/replication-howto.html...
Если вы используете рекомендуемую конфигурацию главного/подчиненного устройства и не записываете в подчиненное устройство, он и я, где это правильно (в отношении mysql-server 5.x). Мне даже не нужно было использовать "START SLAVE", он просто догнал своего хозяина. Но по умолчанию 88000 что-то повторяет каждые 60 секунд, поэтому я думаю, если вы исчерпаете то, что вам, возможно, придется запустить или перезапустить ведомый. В любом случае, для таких, как я, кто хотел знать, если раб переходит в автономный режим и обратно, требуется ручное вмешательство. Нет, это не так.
Возможно, исходный плакат имел повреждение в лог файлах? Но, скорее всего, это не просто сервер, работающий в автономном режиме в течение дня.
извлекается из /usr/share/doc/mysql -server-5.1/README.Debian.gz, что, вероятно, имеет смысл и для не debian-серверов:
* FURTHER NOTES ON REPLICATION =============================== If the MySQL server is acting as a replication slave, you should not set --tmpdir to point to a directory on a memory-based filesystem or to a directory that is cleared when the server host restarts. A replication slave needs some of its temporary files to survive a machine restart so that it can replicate temporary tables or LOAD DATA INFILE operations. If files in the temporary file directory are lost when the server restarts, replication fails.
вы можете использовать что-то sql, например: показать переменные типа 'tmpdir';, чтобы узнать.
Добавление к популярному ответу для включения этой ошибки:
"ERROR 1200 (HY000): The server is not configured as slave; fix in config file or with CHANGE MASTER TO",
Репликация с ведомого в один снимок:
В одном окне терминала:
mysql -h <Master_IP_Address> -uroot -p
После подключения
RESET MASTER;
FLUSH TABLES WITH READ LOCK;
SHOW MASTER STATUS;
Состояние выглядит следующим образом: Обратите внимание, что номер позиции меняется!
+------------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000001 | 98 | your_DB | |
+------------------+----------+--------------+------------------+
Экспортируйте дамп, подобный тому, как он описал " с помощью другого терминала"!
Выйдите и подключитесь к своей собственной БД (которая является подчиненным):
mysql -u root -p
Введите следующие команды:
STOP SLAVE;
Импортируйте дамп, как указано (в другом терминале, конечно!) и введите следующие команды:
RESET SLAVE;
CHANGE MASTER TO
MASTER_HOST = 'Master_IP_Address',
MASTER_USER = 'your_Master_user', // usually the "root" user
MASTER_PASSWORD = 'Your_MasterDB_Password',
MASTER_PORT = 3306,
MASTER_LOG_FILE = 'mysql-bin.000001',
MASTER_LOG_POS = 98; // In this case
После регистрации задайте параметр server_id (как правило, для новых/не реплицированных БД, это не установлено по умолчанию),
set global server_id=4000;
Теперь запустите ведомый.
START SLAVE;
SHOW SLAVE STATUS\G;
Выход должен быть таким же, как он описал.
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Примечание. После репликации главный и подчиненный используют один и тот же пароль!
иногда вам просто нужно дать толчок рабу тоже
попробуйте
stop slave;
reset slave;
start slave;
show slave status;
довольно часто, рабы, они просто застряли, ребята :)
Восстановление раба с помощью LVM
Вот метод, который мы используем для перестройки подчиненных MySQL с использованием Linux LVM. Это гарантирует последовательный снимок, требуя при этом минимального времени простоя вашего мастера.
Установите на главном сервере MySQL значение innodb max грязных страниц в ноль. Это заставит MySQL записать все страницы на диск, что значительно ускорит перезапуск.
set global innodb_max_dirty_pages_pct = 0;
Для контроля количества грязных страниц выполните команду
mysqladmin ext -i10 | grep dirty
Как только число перестанет уменьшаться, вы достигнете точки, чтобы продолжить. Затем сбросьте мастер, чтобы очистить старые журналы bin/relay relay:
RESET MASTER;
Выполните lvdisplay, чтобы получить LV Path
lvdisplay
Вывод будет выглядеть так
--- Logical volume ---
LV Path /dev/vg_mysql/lv_data
LV Name lv_data
VG Name vg_mysql
Завершите работу базы данных master с помощью команды
service mysql stop
Затем сделайте снимок, имя нового логического тома будет mysql_snapshot. Если на диске ОС размещены двоичные журналы, они также должны быть моментальными снимками.
lvcreate --size 10G --snapshot --name mysql_snapshot /dev/vg_mysql/lv_data
Запустите мастер снова с командой
service mysql start
Восстановить грязные страницы с настройками по умолчанию
set global innodb_max_dirty_pages_pct = 75;
Запустите lvdisplay снова, чтобы убедиться, что снимок есть и виден
lvdisplay
Выход:
--- Logical volume ---
LV Path /dev/vg_mysql/mysql_snapshot
LV Name mysql_snapshot
VG Name vg_mysql
Смонтировать снимок
mkdir /mnt/mysql_snapshot
mount /dev/vg_mysql/mysql_snapshot /mnt/mysql_snapshot
Если у вас есть работающий MySQL Slave, вам нужно остановить его
service mysql stop
Далее вам нужно очистить папку данных MySQL
cd /var/lib/mysql
rm -fr *
Вернуться к мастеру. Теперь rsync снимок к ведомому MySQL
rsync --progress -harz /mnt/mysql_snapshot/ targethostname:/var/lib/mysql/
После завершения rsync вы можете размонтировать и удалить снимок
umount /mnt/mysql_snapshot
lvremove -f /dev/vg_mysql/mysql_snapshot
Создайте пользователя репликации на главном сервере, если старый пользователь репликации не существует или пароль неизвестен
GRANT REPLICATION SLAVE on *.* to 'replication'@'[SLAVE IP]' identified by 'YourPass';
Убедитесь, что файлы данных /var/lib/mysql принадлежат пользователю mysql, если вы можете пропустить следующую команду:
chown -R mysql:mysql /var/lib/mysql
Далее запишите позицию бинлога
ls -laF | grep mysql-bin
Вы увидите что-то вроде
..
-rw-rw---- 1 mysql mysql 1073750329 Aug 28 03:33 mysql-bin.000017
-rw-rw---- 1 mysql mysql 1073741932 Aug 28 08:32 mysql-bin.000018
-rw-rw---- 1 mysql mysql 963333441 Aug 28 15:37 mysql-bin.000019
-rw-rw---- 1 mysql mysql 65657162 Aug 28 16:44 mysql-bin.000020
Здесь главный файл журнала - это наивысший номер файла в последовательности, а позиция журнала bin - размер файла. Запишите эти значения:
master_log_file=mysql-bin.000020
master_log_post=65657162
Далее запустите раб MySQL
service mysql start
Выполните команду master master на ведомом устройстве, выполнив следующее:
CHANGE MASTER TO
master_host="10.0.0.12",
master_user="replication",
master_password="YourPass",
master_log_file="mysql-bin.000020",
master_log_pos=65657162;
Наконец начать раб
SLAVE START;
Проверьте статус ведомого:
SHOW SLAVE STATUS;
Убедитесь, что ведомый ввод-вывод работает и нет ошибок соединения. Удачи!
БР, Юха Вехня
Я недавно написал об этом в своем блоге, который находится здесь... Там есть еще несколько деталей, но история такая же.
http://www.juhavehnia.com/2015/05/rebuilding-mysql-slave-using-linux-lvm.html
Я создал репозиторий GitHub с помощью script, чтобы быстро решить эту проблему. Просто измените пару переменных и запустите их (во-первых, script создает резервную копию вашей базы данных).
Я надеюсь, что это поможет вам (и другим людям тоже).
Как Reset (повторная синхронизация) Репликация мастер-ведомого MySQL
Мы используем технику репликации мастер-мастер MySQL, и если один сервер MySQL, скажем, 1 удаляется из сети, он восстанавливает соединение после восстановления соединения и передачи всех записей, которые были зафиксированы на сервере 2, который находился в сети. к серверу 1, который потерял соединение после восстановления. Ведомый поток в MySQL пытается подключиться к своему хозяину через каждые 60 секунд по умолчанию. Это свойство может быть изменено как MySQL, имеющий флаг "master_connect_retry = 5", где 5 в секундах. Это означает, что мы хотим повторить попытку через каждые 5 секунд.
Но вам нужно убедиться, что сервер, который потерял соединение, не показывает никаких изменений в базе данных, так как вы получаете дубликат. Ошибка ключа Код ошибки: 1062
Мастер:
mysqldump -u root -p --all-databases --master-data | gzip > /tmp/dump.sql.gz
scp master:/tmp/dump.sql.gz slave:/tmp/ Переместить файл дампа на подчиненный сервер
Подчиненный:
STOP SLAVE;
zcat /tmp/dump.sql.gz | mysql -u root -p
START SLAVE;
SHOW SLAVE STATUS;
Примечание:
На ведущем устройстве вы можете запустить SET GLOBAL expire_logs_days = 3, чтобы хранить журналы в течение 3 дней в случае ведомых проблем.