Что я действительно могу сделать с помощью pt-table-sync из набора инструментов Percona?

Я искал инструмент для синхронизации таблиц из 2 разных баз данных и нашел pt-table-sync, Я прочитал документацию и запутался: в основном они используют примеры, относящиеся к реплицированной среде, но я думал, что весь смысл репликации в том, чтобы позаботиться о синхронизации данных для вас, отсюда и мои вопросы:

ВОПРОСЫ

  1. Какой смысл использовать pt-table-sync если процесс репликации должен позаботиться о синхронизации данных для вас?

  2. Могу ли я использовать pt-table-sync в не реплицированной среде (между 2+ хостами, которые не имеют ничего общего друг с другом, это роль pt-table-sync --execute host1 host2 host3 пример дан)?

  3. Если я должен использовать pt-table-sync в реплицированной среде, могу ли я обойтись без bin-logs на master (есть пример, говорящий о разрешении разногласий, обнаруженных pt-table-checksum так интересно, если bin-logs абсолютно необходимы)?

Источник

3 ответа

Решение

Ответ на вопрос 1

MySQL Replication страдает от двух основных проблем

  • Репликация MySQL является асинхронной. Это может привести к задержке репликации. Это проявляется в проблемах связи между мастером и подчиненным через поток подчиненного ввода / вывода. Это можно логически и численно увидеть в Seconds_Behind_Master,

  • Data Drift, Это прерывистое состояние, когда ведущий и ведомый просто несинхронизированы из-за факторов, выходящих за рамки репликации MySQL. Например, обратите внимание на один способ лучше синхронизировать репликацию: используйте опцию sync-binlog, Когда вы установите sync-binlog в 1 mysqld выполнит сброс текущего двоичного журнала для каждой записи, которую вы записываете в двоичном журнале. Это может смешно тормозить Мастера. По умолчанию, sync-binlog это 0.

    • Вот вопрос: с sync-binlog=0 Кто отвечает за сброс двоичного журнала на диск?
    • Ответ (пожалуйста, сядьте за это): ОПЕРАЦИОННАЯ СИСТЕМА!!!
    • С этим ответом он ставит подчиненное устройство в ужасное неудобство, поскольку его поток ввода-вывода зависит от операционной системы мастера. Когда ОС Мастера приступает к сбросу двоичных изменений журнала на диск, и Поток ввода-вывода подчиненного устройства может обнаружить следующий входящий оператор SQL, тогда этот оператор передается через Поток ввода-вывода подчиненному.
    • У Percona есть хороший PDF-файл о работе с данными.

Ответ на вопрос 2

Прямого ответа здесь нет, потому что pt-table-sync был разработан для обнаружения потока ввода / вывода ведомого с помощью --sync-to-master вариант.

Ответ на вопрос 3

Прямой ответ здесь - нет, потому что MySQL Replication требует знать

  • какой текущий двоичный журнал на Мастер? (это Master_Log_File от SHOW SLAVE STATUS\G)
  • Какую последнюю позицию Slave прочитал из текущего двоичного журнала Мастера? (это Read_Master_Log_Pos от SHOW SLAVE STATUS\G)

Если вы просто хотите, чтобы ваши двоичные журналы убирались с пути, вы можете сделать одну из двух вещей

  • ВАРИАНТ 1: На мастере установите expire-logs-days 3, чтобы сохранить бинарные логи за последние 3 дня
    • добавлять expire-logs-days=3 в /etc/my.cnf
    • Перезагрузка не требуется: просто запустите SET GLOBAL expire_logs_days = 3;
  • ВАРИАНТ 2: Выполнить SHOW SLAVE STATUS\G на Рабе. Принять значение Relay_Master_Log_File, и используйте его, чтобы очистить двоичные журналы на Master, чтобы поднять этот файл журнала.
    • Предположим, вы бежите SHOW SLAVE STATUS\G на Рабе
    • Вы получаете это Relay_Master_Log_File: mysql-bin.000035
    • Запустите это на Мастере: PURGE BINARY LOGS TO 'mysql-bin.000035';

ПРЕДЛОЖЕНИЕ

Если вы хотите больше доверять pt-table-sync, попробуйте использовать --print вариант и перенаправление в текстовый файл вместо --execute вариант. Это сгенерирует SQL, который обычно выполняется на Master. После этого вы можете просто запустить SQL непосредственно на этом подчиненном устройстве. Думайте об этом как генеральная репетиция для --execute,

Источник

но я думал, что весь смысл репликации должен был позаботиться о синхронизации данных для вас

Да, репликация MySQL пытается синхронизировать реплицированную базу данных. Тем не менее, репликация MySQL сложна, и репликация может произойти сбой по разным причинам. Ошибки репликации в моем опыте редки, но они случаются во время неожиданных сбоев сервера, когда пользователи нажимают "Control-C" в середине большой вставки на мастер-диске и т. Д. MySQL.com не предоставляет хороших инструментов для работы со многими из этих проблем. К счастью, несколько инженеров, таких как Барон Шварц (первоначальный автор Percona Toolkit (ранее известный как Maatkit)) разработали инструменты, облегчающие администрирование MySQL.

Например, у меня в настоящее время есть таблица с 50 миллионами строк. Несколько строк не синхронизированы из-за сбоя сервера несколько недель назад. Мне нужно выяснить, какие строки не синхронизированы, но это было бы больно делать вручную. Я использую контрольную сумму pt-table для проверки ошибок репликации в реплике и синхронизацию pt-table для определения, какие строки отсутствуют в реплике.

Если вы рассматриваете вопрос репликации 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 группы: удаляет, заменяет, вставляет, обновляет).

Источник
Другие вопросы по тегам