MySQL подчиненный не синхронизирован с ведущим
Наш подчиненный, который просто используется для резервного копирования, не синхронизирован. Он разбился на ключе сдержанности.
Я хотел бы найти способ повторно синхронизировать подчиненное устройство, не переводя мастер в автономный режим, я знаю, что могу сделать это таким образом, но я верю, что это невозможно.
Передо мной "Высокопроизводительный MySQL", и он указывает мне направление maatkit, в частности, mk-table-sync.
На всю жизнь я не могу заставить работать mk-table-sync.
Я запускаю это так на рабе
root@machine:~# mk-table-sync --sync-to-master --dry-run 127.0.0.1
# Syncing h=127.0.0.1
# DELETE REPLACE INSERT UPDATE ALGORITHM EXIT DATABASE.TABLE
# 0 0 0 0 Chunk 0 database.case_study_product
# 0 0 0 0 Chunk 0 database.case_study_region
# 0 0 0 0 Chunk 0 database.case_study_sector
# 0 0 0 0 Chunk 0 database.contact
# 0 0 0 0 Chunk 0 database.contact_issue
# 0 0 0 0 Chunk 0 database.feedback
# 0 0 0 0 Chunk 0 database.feedback_rating
# 0 0 0 0 Chunk 0 database.feedback_usefulness
# 0 0 0 0 Chunk 0 database.help
# 0 0 0 0 Chunk 0 database.help_issue
# 0 0 0 0 Chunk 0 database.search_weight
# 0 0 0 0 Chunk 0 database.contented_content
# 0 0 0 0 Nibble 0 database.contented_content_index
# 0 0 0 0 Chunk 0 database.contented_content_log
Я точно знаю, что contented_content и contented_content_index не синхронизированы. Но из того, что я могу сказать, что выходной maatkit думает, что все в порядке.
Вот вывод статуса ведомого:
mysql> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 10.0.40.12
Master_User: rep1
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000023
Read_Master_Log_Pos: 25832973
Relay_Log_File: mysql-relay-bin.000002
Relay_Log_Pos: 19098703
Relay_Master_Log_File: mysql-bin.000001
Slave_IO_Running: Yes
Slave_SQL_Running: No
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 1452
Любая помощь, указатели... попросить больше информации.. и т. Д.
5 ответов
Сразу после того, как я много почесал голову и поиграл в моей виртуальной среде, именно так мне удалось синхронизировать своего раба с мастером.
1) В базе данных (mydb) на мастере я хочу создать следующую таблицу:
CREATE TABLE checksum (
db char(64) NOT NULL,
tbl char(64) NOT NULL,
chunk int NOT NULL,
boundaries char(100) NOT NULL,
this_crc char(40) NOT NULL,
this_cnt int NOT NULL,
master_crc char(40) NULL,
master_cnt int NULL,
ts timestamp NOT NULL,
PRIMARY KEY (db, tbl, chunk)
);
2) На мастере выполните следующую команду:
mk-table-checksum -d mydb --replicate mydb.checksum 127.0.0.1
3) На ведомом компьютере выполните следующую команду:
mk-table-sync -d mydb --replicate mydb.checksum --sync-to-master --no-foreign-key-checks --execute 127.0.0.1
Когда я пытался запустить команду контрольной суммы репликации на ведомом устройстве, прежде чем запустить команду синхронизации, которая вообще ничего не делала.
Подчиненный подключен и работает в моем примере, также я отключил проверку внешних ключей, потому что мы используем INNODB и получал проблемы с ограничениями внешнего ключа при выполнении синхронизации.
У меня похожая ситуация, когда мне нужно регулярно проверять согласованность данных между моим ведущим и ведомым.
Я написал скрипт для обработки этого, который я бросил в crontab и запускаю его каждое воскресенье, в то время, когда я знаю, что не будет много данных, записываемых в реплицированные базы данных.
Я должен отметить, что это написано на PHP, и ведомый / ведущий находится в одной сети с NFS, размещенной на диске хозяина @ /home/sharefiles/
Я уверен, что некоторые люди могут ворчать о том, как это делается, но это вполне отвечает моим потребностям и занимает всего пару секунд.
/ * Этот скрипт запускается еженедельно, чтобы остановить репликацию, удалить базы данных, скопировать их с главного на подчиненный * /
/ * И снова начинается репликация. Не трогайте этот скрипт! * /
// Остановить раба на рабе
$ slave = mysql_connect ("slave", "user", "pw");
mysql_query ("STOP SLAVE", $ slave);
// Сброс положения
mysql_query ("RESET SLAVE", $ slave);
// Получить основную информацию, положение и т. Д.
$ master = mysql_connect ("localhost", "user", "pw");
$ masterinfo = mysql_fetch_assoc (mysql_query ("SHOW MASTER STATUS", $ master)); // $ masterinfo [File], $ masterinfo [Position]
// БД для репликации
$ dbArray = array ("db1", "db2", "db3", "db4");
// Дамп каждой БД и копирование в раб
foreach($dbArray как $ db) {
system("mysqldump $db > /home/sharefiles/$db.sql");
system("mysql -h slaveaddress -u root --password=pw --database=$db < /home/sharefiles/$db.sql");
}
mysql_query ("CHANGE MASTER TO MASTER_HOST = 'master', MASTER_USER = 'replication', MASTER_PASSWORD = 'replicationuserpassword', MASTER_LOG_FILE = '$ masterinfo [File]', MASTER_LOG_POS = $ masterinfo [Position]", $ slave);
mysql_query ("START SLAVE", $ slave);
Может быть, это поможет, если вы поставите на подчиненный сервер:
mysql> STOP SLAVE;
mysql> SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;
mysql> START SLAVE;
Данные ведомого будут отличаться после его завершения. Запустите mk-table-checkum --replicate на главном сервере, затем на ведомом устройстве, запустите mk-table-sync --replicate (пример в документации).
Мне непонятно, что вы поняли о состоянии вашего ведомого по выводу --dry-run, но --dry-run НЕ сравнивает никаких данных. Он просто говорит вам, какие таблицы он будет проверять и с каким алгоритмом синхронизации.
Я думаю, что необходима более четкая информация о том, что делает --dry-run, поэтому я создал запрос функции: http://code.google.com/p/maatkit/issues/detail?id=691
Я приветствую ваши комментарии там и в списке рассылки Maatkit!