Предисловие:
В настоящее время наиболее часто используемой базой данных MySQL является архитектура «главный-подчиненный», и большинство архитектур высокой доступности также развиваются через архитектуру «главный-подчиненный». Однако после того, как архитектура ведущий-подчиненный работает в течение длительного времени, может возникнуть несогласованность данных, например, ошибки в работе или репликации, вызванные доступной для записи подчиненной библиотекой.В этой статье подробно рассматривается несогласованность ведущий-ведомый и способы ее решения проблема.
1. Причины несоответствия между ведущим и ведомым
Есть много возможных причин для несоответствия мастера-раба. Вот лишь несколько:
- Основной формат бинарного журнала библиотеки — Statement, что может привести к несогласованности ведущий-ведомый после синхронизации с подчиненной библиотекой.
- Если set sql_log_bin=0 выполняется до того, как основная библиотека выполнит изменение, основная библиотека не будет записывать binlog, и подчиненная библиотека не сможет изменить эту часть данных.
- Ведомый узел не настроен только для чтения, и данные записываются по ошибке.
- Непредвиденный сбой основной или подчиненной библиотеки.Время простоя может привести к повреждению файла binlog или relaylog, что приведет к несогласованности между ведущим и подчиненным.
- Версии главного и подчиненного экземпляров несовместимы, особенно если более высокая версия является главной, а более низкая версия — подчиненной, функции, поддерживаемые основной базой данных, могут не поддерживаться подчиненной базой данных.
- Вызвана собственная ошибка MySQL.
2. Метод устранения несоответствия ведущий-ведомый
Ниже описан метод устранения несоответствия ведущий-ведомый.Обратите внимание, что он предназначен для исправления несогласованности ведущий-ведомый, а не исправления ошибок синхронизации ведущий-ведомый.
Чтобы исправить несоответствие ведущий-ведомый, мы должны сначала найти несоответствие ведущий-ведомый.Ниже приведены соответствующие методы исправления в зависимости от различных ситуаций.
Первый случай: Например, при выполнении скрипта, чтобы завершить выполнение быстрее, в скрипт добавляется set sql_log_bin=0. Тогда все изменения данных этого скрипта не будут применяться к ведомой библиотеке.В это время данные master-slave будут несогласованными.Решение состоит в том, чтобы сначала остановить репликацию master-slave, а затем вручную выполнить скрипт в ведомом библиотеку и, наконец, запустить репликацию master-slave.
Второй случай: Возможно, ваша подчиненная библиотека не настроена только для чтения, а коллега не знал архитектуры и вызвал запись данных в подчиненную библиотеку из-за неправильной работы.Об этой ситуации следует сообщить и вовремя решить. Решение: Если эти операторы действительно необходимо выполнить, вы можете сначала выполнить set sql_log_bin=0 в главной библиотеке, а затем выполнить оператор; если вам не нужно выполнять эти операторы, вам нужно откатить предыдущую ошибочную операцию на рабская библиотека.
Однако иногда ситуация не так проста, может быть много ситуаций: два экземпляра ведущего и ведомого работают в течение длительного времени, в один прекрасный день выполняется проверка согласованности и обнаруживается, что ведущее и ведомое несовместимы.Трудно установить конкретную причину и время несогласованности. Итак, что мне делать в это время?Некоторые люди говорят, что переделывают подчиненную библиотеку.Хотя это тоже решение, время восстановления этого решения относительно медленное, и иногда подчиненная библиотека также берет на себя часть операции запроса и не может быть перестроен наспех. Далее основное внимание уделяется методу ремонта в этом случае.
- Используйте инструмент percona-toolkit для помощи.
Инструментарий PT содержит два инструмента, pt-table-checksum и pt-table-sync, которые в основном используются для определения согласованности ведущего и ведомого устройств и устранения несоответствий данных. Преимущество этого решения в том, что скорость ремонта высокая, и нет необходимости останавливать помощь master-slave. Недостаток в том, что требуется накопление знаний. Если вы не знаете, как использовать этот инструмент раньше, он может потребуется время, чтобы изучить и протестировать, особенно в производственной среде, вы должны быть осторожны в использовании. Чтобы узнать, как его использовать, перейдите по следующей ссылке:блог woo woo woo.cn на.com/flying people/afraid/77…
- Вручную перестраивать несогласованные таблицы.
Например, в подчиненной базе данных мы обнаружили, что некоторые таблицы не согласуются с данными основной базы данных, а объем данных этих таблиц относительно велик, сравнивать данные вручную нереально, а переделывать всю базу данных относительно медленно. на этот раз мы можем только переделать несколько таблиц, чтобы исправить несоответствие ведущий-ведомый. Например: главные и подчиненные данные трех таблиц a1 b1 c1 несовместимы, тогда мы можем сделать это:
1. Остановить подчиненную репликацию из библиотеки mysql> остановить раб;
2. Сделайте дамп этих трех таблиц в основной библиотеке и запишите синхронизированный бинлог и точки POS. mysqldump -uroot -p123456 -q --single-transaction --master-data=2 yourdb a1 b1 c1 > ./a1_b1_c1.sql
3. Проверьте файл a1_b1_c1.sql, чтобы узнать записанный бинлог и точки POS. больше a1_b1_c1.sql Например, MASTER_LOG_FILE='mysql-bin.002974', MASTER_LOG_POS=55056952;
4. Скопируйте файл a1_b1_c1.sql на подчиненную машину и сделайте так, чтобы Change master указывал на нее. mysql> запустить ведомое устройство до тех пор, пока MASTER_LOG_FILE='mysql-bin.002974', MASTER_LOG_POS=55056952; Примечание. Позвольте мне объяснить, что означает этот шаг. Чтобы данные других таблиц не потерялись, продолжайте синхронизацию до окончания синхронизации.Данные таблиц a1,b1,c1 уже сгенерировали снапшот в предыдущем дампе.Нам нужно только его импортировать,и затем запустите синхронизацию.
5. Импортируйте a1_b1_c1.sql на подчиненную машину (если binlog включен из библиотеки, для ускорения импорта вы можете сначала выполнить set sql_log_bin=0) mysql -uroot -p123456 yourdb
6. После завершения импорта запустите синхронизацию из библиотеки. mysql>запустить подчиненное устройство;
Таким образом мы восстановили 3 таблицы и исправили синхронизацию. Недостаток этого подхода в том, что копирование из библиотеки нужно останавливать во время импорта, но это допустимо.
Могут быть и другие методы восстановления, такие как сравнение и синхронизация с такими инструментами, как Navicat, но эти инструменты подходят только для небольших объемов данных, а когда данных десятки миллионов, использовать этот метод не реально. Если у вас есть подобный опыт, поделитесь им в комментариях.
3. Как избежать несоответствия ведущий-ведомый
Из приведенного выше введения вы также можете узнать, что ремонт не прост, поэтому мы должны избегать его из источника, поэтому, как мы можем избежать несоответствия главного и подчиненного, вот несколько предложений, я надеюсь, что это будет полезно для ты.
- Бинлог основной библиотеки имеет формат ROW.
- Версия базы данных экземпляра master-slave остается прежней.
- Основная библиотека должна управлять правами учетной записи и не может выполнять set sql_log_bin=0.
- Из библиотеки разрешено только чтение, запись вручную не разрешена.
- Регулярно выполняйте проверки согласованности ведущий-ведомый.
Суммировать:
В этой статье подробно описываются причины несогласованности ведущий-ведомый, методы устранения несоответствий и способы предотвращения несогласованности ведущий-ведомый. Особенно метод ремонта несоответствия, могут быть и другие решения, это должно учитывать реальную ситуацию, чтобы выбрать подходящий метод ремонта. Нелегко быть оригинальным, я надеюсь, что вы можете поддержать это.