MySQL ошибка 1236 При использовании GTID

Question

Я хочу, чтобы создать копию на мой Percona сервер с GTID включена, но получила эту ошибку, когда я показать статус подчиненного:

Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.' 

Обычно, я бы остановить мой раб, его сброс , сбросить мастер (на подчиненном устройстве) и получить новое значение GTID_PURGED от мастера. Но на этот раз, мастер имеет очень необычное значение (я), и я не знаю, как определить, какой из них использовать:

mysql> show master status\G 
*************************** 1. row *************************** 
      File: mysqld-bin.000283 
     Position: 316137263 
    Binlog_Do_DB: 
Binlog_Ignore_DB: 
Executed_Gtid_Set: 1570dee1-165b-11e6-a4a2-00e081e93212:1-3537, 
c73f3ee7-e8d4-ee19-6507-f898a9930ccd:1-18609, 
cdb70eaa-f753-ee1b-5c95-ecb8024ae729:1-2357789559:2357789561-2357790104:2357790106-2514115701:2514115703-2514115705:2514115707-2546512667 
1 row in set (0.00 sec) 

От ведомого устройства с новой резервной копией, я получаю это:

root@ubuntu:/var/lib/mysql# cat xtrabackup_binlog_info 
mysqld-bin.000283  294922064  1570dee1-165b-11e6-a4a2-00e081e93212:1-3537, 
c73f3ee7-e8d4-ee19-6507-f898a9930ccd:1-18609, 
cdb70eaa-f753-ee1b-5c95-ecb8024ae729:1-2357789559:2357789561-2357790104:2357790106-2514115701:2514115703-2514115705:2514115707-2546400960 

Еще одна вещь, я просто очистил двоичные журналы на главном компьютере, прежде чем сделать резервную копию. автоматическая очистка binlog установлена ​​на 7 дней. Поэтому я знаю его не потому, что журнал bin был очищен, как указывает ошибка.

Я запускаю Ubuntu 14:04 и версию сервера Percona 5.6.31-77.

Как я могу решить эту проблему? Какова правильная ценность GTID_PURGED мастера?

Answer 1

mysql 5.6 Ошибки и исправления GTID Что такое GTID? 

4c2ad77f-697e-11e3-b2c3-c80aa9f17dc4

• Это 128 бит идентификационный номер сервера (SERVER_UUID). Он определяет, где была создана транзакция. Каждый сервер имеет свой собственный SERVER_UUID. Какие проблемы решает GTID?

• Можно идентифицировать транзакцию однозначно на серверах репликации. Сделайте автоматизацию процесса переключения при сбое намного проще. Нет необходимости делать расчеты, проверять двоичный журнал и т. Д. Просто MASTER_AUTO_POSITION = 1.

• На уровне приложений легче сделать WRITE/READ split. После записи на MASTER у вас есть GTID, поэтому просто проверьте, был ли этот GTID выполнен на SLAVE, который вы используете для чтения.
• Разработка новых средств автоматизации теперь не боль. Как это реализовать?

Три переменные необходимы во всех серверах сети репликации

• gtid_mode: Он может быть включен или OFF (не 1 или 0). Это позволяет GTID на сервере.
• log_bin: включить двоичные журналы. Обязательно создать среду репликации.
• log-slave-updates: ведомые серверы должны регистрировать изменения, которые поступают от мастера в его собственном двоичном журнале.
• принудительно-gtid-консистенция: сообщения, которые не могут быть зарегистрированы безопасным способом, отказываются от сервера. исх: http://dev.mysql.com/doc/refman/5.6/en/replication-gtids-howto.html

Ошибки репликации и исправления:

«'Получили неисправимая ошибка +1236 от мастера при чтении данных из двоичного журнала:» Подчиненный подключается с помощью CHANGE MASTER TO MASTER_AUTO_POSITION = 1, но мастер очистил двоичные журналы, содержащие GTID, которые требуется подчиненному. "slave_io thread stop running running.

Разрешение: Учитывая следующие мастер - раб UUID в

MASTER UUID: 4c2ad77f-697e-11e3-b2c3-c80aa9f17dc4

SLAVE UUID: 5b37def1-6189-11e3-bee0-e89a8f22a444

Этапы:

slave> stop slave;

slave> FLUSH TABLES WITH READ LOCK;

slave> показать статус хозяина;

«4c2ad77f-697e-11e3-b2c3-c80aa9f17dc4: 1-83345127,5b37def1-6189-11e3-bee0-e89a8f22a444: 1-13030: 13032-13317: 13322-13325: 13328-653183: 653185-654126: 654128 -1400817: 1400820-3423394: 3423401-5779965 '

(здесь 83345127 последнего GTID выполнен на мастер и 5779965 последней ведомой GTID выполнен на Master)

ведомого> сброс мастера;

ведомое> установить глобальный GTID_PURGED =»4c2ad77f-697e-11e3-b2c3-c80aa9f17dc4: 1-83345127,5b37def1-6189-11e3-bee0-e89a8f22a444: 1-5779965 ';

slave> start slave;

slave> разблокировать столы;

невольник> статус раба;

ПРИМЕЧАНИЕ. После этого перезапустите другие ведомые цепи, если они перестанут реплицироваться;

ОШИБКА: таблица «Ошибка» ... «не существует» по запросу. По умолчанию база данных: ... Запрос: «INSERT INTO ИЛИ Last_SQL_Error: ... .error„Дублировать запись“ПРОПУСТИТЬ сделку на рабе (slave_sql Thread остановки бега) Примечание:

• SQL_SLAVE_SKIP_COUNTER больше не работает с GTID.
• Нам нужно найти, какая транзакция вызывает потерю репликации.
  • - Из бинарного журнала
  • - От SHOW SLAVE STATUS (получено против выполнения) Типа ошибки: (проверить последнюю ошибку SQL в состоянии показать ведомое)

Разрешения: Учитывая следующего являются мастер - раб UUID в

MASTER UUID: 4c2ad77f-697e-11e3-b2c3-c80aa9f17dc4

SLAVE UUID: 5b37def1-6189-11e3-bee0-e89a8f22a444

невольник> статус раба;

копировать значение «Executed_Gtid_Set». '4c2ad77f-697e-11e3-b2c3-c80aa9f17dc4: 1-659731804,5b37def1-6189-11e3-bee0-e89a8f22a444: 1-70734947-80436012: 80436021-80437839'

-Seems, что ведомый (с UUID 5b37def1-6189- 11e3-bee0-e89a8f22a444), транзакция «80437840» вызывает здесь проблему.

slave> STOP SLAVE;

slave> SET GTID_NEXT = "5b37def1-6189-11e3-bee0-e89a8f22a444: 80437840"; (last_executed_slave_gtid_on_master + 1)

slave> BEGIN; COMMIT;

slave> SET GTID_NEXT = "AUTOMATIC";

slave> START SLAVE;

невольник> статус раба;

и все это SET !!!