Я искал инструмент для синхронизации таблиц из двух разных баз данных и нашел pt-table-sync. Я прочитал документацию и запутался: они в основном используют примеры, относящиеся к реплицированной среде, но я думал, что весь смысл репликации заключается в том, чтобы позаботиться о синхронизации данных для вас, поэтому мои вопросы:
В чем смысл использования pt-table-sync если предполагается, что процесс репликации позаботится о синхронизации данных за вас?
Могу ли я использовать pt-table-sync в нереплицированной среде (между 2+ хостами, которые не имеют ничего общего друг с другом, это роль pt-table-sync --execute host1 host2 host3 пример приведен)?
Если я должен использовать pt-table-sync в реплицируемой среде, могу ли я обойтись без bin-logs на master (есть пример, говорящий об устранении различий, обнаруженных pt-table-checksum так интересно, если bin-logs абсолютно необходимы)?
Репликация MySQL страдает от двух основных проблем
Репликация MySQL асинхронная. Это может вызвать задержку репликации. Это проявляется в проблемах связи между ведущим и ведомым через поток ввода-вывода ведомого. Это можно логически и численно увидеть в Seconds_Behind_Master.
Data Drift. Это прерывистое состояние, при котором главный и подчиненный сервер просто не синхронизированы из-за факторов, выходящих за рамки репликации MySQL. Например, обратите внимание на один способ лучше синхронизировать репликацию: используйте параметр sync-binlog. Когда вы устанавливаете sync-binlog равным 1, mysqld будет очищать текущий двоичный журнал для каждой записи, которую вы записываете в двоичный журнал. Это может до смешного замедлить Мастера. По умолчанию, sync-binlog равно 0.
sync-binlog=0, кто отвечает за сброс двоичного журнала на диск?Прямой ответ здесь нет, потому что pt-table-sync был разработан для обнаружения потока ввода-вывода ведомого устройства с помощью --sync-to-master вариант.
Прямой ответ здесь - нет, потому что репликация MySQL требует знать
Master_Log_File из SHOW SLAVE STATUS\G)Read_Master_Log_Pos из SHOW SLAVE STATUS\G)Если вы просто хотите, чтобы ваши двоичные журналы не мешали, вы можете сделать одно из двух
expire-logs-days до 3, чтобы хранить двоичные журналы за последние 3 дня expire-logs-days=3 в /etc/my.cnfSET GLOBAL expire_logs_days = 3;SHOW SLAVE STATUS\G на Раб. Примите значение Relay_Master_Log_File. и используйте его для очистки двоичных журналов на Мастере до этого файла журнала. SHOW SLAVE STATUS\G на рабеRelay_Master_Log_File: mysql-bin.000035PURGE BINARY LOGS TO 'mysql-bin.000035';Если вы хотите больше доверять pt-table-sync, попробуйте использовать --print вариант и перенаправление в текстовый файл вместо --execute вариант. Это сгенерирует SQL, который обычно выполняется на Мастере. После этого вы можете просто запустить SQL непосредственно на этом ведомом устройстве. Думайте об этом как о генеральной репетиции для --execute.
но я думал, что весь смысл репликации в том, чтобы позаботиться о синхронизации данных за вас
Да, репликация MySQL пытается синхронизировать реплицированную базу данных. Однако репликация MySQL сложна, и репликация может завершиться ошибкой по разным причинам. По моему опыту, ошибки репликации случаются редко, но они случаются во время неожиданных сбоев сервера, когда пользователи нажимают «Control-C» в середине большой вставки на мастере и т. Д. MySQL.com не предоставляет хороших инструментов для решения многих этих проблем. К счастью, несколько инженеров, таких как Барон Шварц (оригинальный автор Percona Toolkit (ранее известного как Maatkit), разработали инструменты, упрощающие администрирование MySQL.
Например, у меня сейчас есть таблица с 50 миллионами строк. Несколько строк не синхронизированы из-за сбоя сервера несколько недель назад. Мне нужно выяснить, какие строки не синхронизированы, но делать это вручную было бы болезненно. Я использую pt-table-контрольную сумму для проверки ошибок репликации на реплике и pt-table-sync, чтобы определить, какие строки отсутствуют на реплике.
Если вы рассматриваете возможность репликации MySQL, я настоятельно рекомендую вам изучить и использовать Percona Toolkit. Если бы мы начали с Percona Toolkit, администрирование наших баз данных MySQL было бы намного проще.
Прочитал документацию и запутался:
Документация Percona Toolkit написана как техническое руководство. К сожалению, он не очень хорошо описывает, как использовать инструменты, как они помогают вам и т. Д. http://www.mysqlperformanceblog.com есть часть этой информации, но она в основном сосредоточена на Percona-форке MySQL (именно так они зарабатывают на жизнь), что требует от читателя сделать некоторый перевод.
Ответ на вопрос 1
pt-table-sync (вместе с pt-table-checksum) можно использовать для исправления ошибок репликации, таких как повреждение данных, непосредственное изменение данных на ведомом устройстве, сбои сервера, изменения схемы в неправильном порядке и т. д.
тем не мение pt-table-sync может также использоваться без репликации для синхронизации таблиц в режиме, близком к реальному времени, если данные не меняются слишком сильно.
Правильный ответ на вопрос 2
Конечно, вы можете использовать его и в нереплицируемой среде, руководство также упоминает об этом. Я использую его из cron, чтобы «синхронизировать» 3 сервера mysql каждые 5 минут. У них есть одна и та же копия данных, которая изменяется только иногда (на первом сервере), поэтому репликация для этой цели была бы излишней.
Вы можете указать отдельные базы данных или отдельные таблицы для синхронизации. У вас может быть несколько целевых серверов. pt-table-sync использует несколько эффективных алгоритмов для обнаружения изменений в таблицах базы данных и копирования только изменений (он классифицирует изменения на 4 группы: удаление, замена, вставка, обновления).