Причины и решения задержки синхронизации (репликации) mysql

MySQL

Природа задержек синхронизации

Появляется, когда подчиненная библиотека не успевает за ходом обновления главной библиотеки.Задержка синхронизации (репликации), в это время в подчиненной библиотеке будут накапливаться несинхронизированные модификации в relay_log, и версия данных будет постепенно все больше отличаться от основной библиотеки.

Причины задержки синхронизации

Чтобы определить причину задержки, нам нужно определить, в каком потоке репликации возникают проблемы. В MySQL пара синхронных соединений ведущий-ведомый опирается на три разных потока, два из которых создаются подчиненной библиотекой, а один — главной библиотекой.

  • из библиотекиI/o线程: когда ты проходишьStart SlaveПосле того, как команда настроит информацию о синхронизации главной библиотеки, этот поток будет создан подчиненной библиотекой. Используется для запроса резервной копии журнала binlog основной библиотеки.
  • основная библиотекаBin log Dump线程: Когда подчиненная библиотека подключена к основной библиотеке, этот поток будет создан, а затем его бинлог будет отправлен в подчиненную библиотеку.
  • из библиотекиSlave SQL 线程: Создайте этот поток из библиотеки, затем прочитайте содержимое из полученного бинлога и примените его.

Синхронизация решений

Задержки репликации возникают, когда поток ввода-вывода или поток SQL не может обработать сделанные ему запросы.

Возможные проблемы с потоками ввода/вывода

  1. медленная сеть
  2. Большой объем передаваемых данных
  3. В паре ведущий-ведомый чтение binlog выполняется последовательно, а запись — параллельно.

Решения возможных проблем с потоками ввода/вывода

  1. Открыт для 1.2.slave_compressed_protocolвозможность сжатия данных
  2. Для 3. Параллельное чтение на уровне библиотеки

Возможные проблемы с потоками SQL

  1. Оператор не оптимизирован или неуместен, что приводит к медленной синхронизации подчиненной библиотеки, например, к большому количеству долгосрочных транзакций или слишком большому количеству операций ввода-вывода.
  2. При использовании формата Row/Mixed возникнет проблема, если таблица из библиотеки не имеет первичного ключа.

Возможные решения проблем для потоков SQL

  1. Уменьшить долгосрочные транзакции или IO
  2. Проверьте мастер, есть ли у вас Primary Key из библиотеки

Как увидеть, в каком потоке возникла проблема

Как синхронизируются имя и местоположение файла binlog

Использовать в этом режиме синхронизацииShow master statusа такжеshow slave statueКоманды могут просматривать необходимую информацию, такую ​​как: Что видит команда Show master status:

  • пройти черезpostion-Read_Master_Log_PosПолучите количество байтов, ваша тема IO находится за основным журналом библиотеки
  • пройти черезpostion-Exec_Master_Log_PosПолучите количество байтов, на которое ваш поток SQL отстает от журнала основной библиотеки.
  • пройти черезRead_Master_Log_Pos-Exec_Master_Log_PosПолучите количество байтов, на которое ваш поток SQL отстает от ввода-вывода Что видит команда Show slave status:
  • seconds_behind_masterВы можете ссылаться на количество секунд, отстающих от основной библиотеки, но не слишком на него полагаться, потому что его статистика не очень точна.

Синхронизация GTID

Метрики, используемые для диагностики (показать статус ведомого устройства)

  • Выполненные GTIDS: Мастер может видеть, что идентификатор выполненной транзакции возвращается. Вы также можете получить последний идентификатор выполненного транзакции, запросивая глобальную переменную GTID_EXCURED.
  • Полученные GTID: видны только из библиотеки, используются для возврата идентификатора транзакции, полученного потоком ввода-вывода.
  • Очищенные GTID: показывает, какие завершенные транзакции были удалены из бинарного журнала. Вообще вас интересует только этот лог из библиотеки

После получения GTID вы можете использоватьGTID_SUBTRACT()Функция вычисляет разницу между ведомой библиотекой и главной библиотекой. Например, следующий запрос к подчиненной библиотеке показывает GTID (задержка потока SQL), считанные из двоичного журнала, которые еще не были применены:

slave> SELECT GTID_SUBTRACT('96985d6f-2ebc-11e7-84df-08002715584a:5-133', 
        '96985d6f-2ebc-11e7-84df-08002715584a:26-132') AS MissingGTIDs;
+-----------------------------------------------+
| MissingGTIDs                                  |
+-----------------------------------------------+
| 96985d6f-2ebc-11e7-84df-08002715584a:5-25:133 |
+-----------------------------------------------+
1 row in set (0.00 sec)

Введение в GIID

По GTIDs] [глобальные идентификаторы транзакций могут идентифицировать каждую транзакцию и могут находиться в любой ведомой дорожке и быть отправлены после применения; BinaryLog например, так что никакая репликация не зависит от файла журнала и местоположения. GTID полностью основаны на транзакции, все транзакции, представленные в Master, выполняются на Commit Slave, тогда мы можем гарантировать согласованность данных между Master и Slave. Вы можете использовать для достижения на основе GTID SBR или RBR. RBR [рекомендуется] Репликация на основе строк.

Ссылаться на

What Causes Replication Lag?

Категории