После аварийного рестарта mysql-сервера, исполняющего роль master-а, на slave-е вылезла вот такая проблемка:
[ERROR] Slave I/O: Got fatal error 1236 from master when reading data from binary log: ‘Client requested master to start replication from position > file size’, Error_code: 1236
Ну и процесс репликации, естественно, остановился.
Как можно догадаться из сообщения об ошибке, slave захотел выполнить команды из такого места бинлога, которого на мастере не оказалось после рестарта последнего (наверное, потому, что часть бинлога не успела записаться на диск мастера за мгновение до того, как он был перезагружен по питанию).
Смотрим позицию, до которой дошел slave:
[slave]$ echo "show slave status G" | mysql | grep -E "[[:space:]]Master_Log_File|Read_Master_Log_Pos" Master_Log_File: s10-bin.000253 Exec_Master_Log_Pos: 783374391
Смотрим последнюю позицию, которая реально присутствует в этом бинлоге мастера:
[master]$ mysqlbinlog s10-bin.000253 | tail -n 9 /*!*/; # at 783367615 #150704 18:12:45 server id 62 end_log_pos 783367646 CRC32 0x2be04f67 Xid = 22088173 COMMIT/*!*/; DELIMITER ; # End of log file ROLLBACK /* added by mysqlbinlog */; /*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/; /*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;
И видим, что последняя позиция — 783367646. В то время как slave пытается исполнить позицию 783374391, которая, очевидно, дальше, чем 783367646. Вывод – надо «отмотать» slave немного назад:
[slave] mysql> stop slave; [slave] mysql> change master to master_log_pos=783367646; [slave] mysql> start slave;
В логе видим:
[Note] 'CHANGE MASTER TO executed'. Previous state master_host='10.10.10.10', master_port= 3306, master_log_file='s10-bin.000253', master_log_pos=783374391, master_bind=''. New state master_host='10.10.10.10', master_port= 3306, master_log_file='s10-bin.000253', master_log_pos=783367646, master_bind=''. [Note] Slave I/O thread: connected to master 'repl@10.10.10.10:3306',replication started in log 's10-bin.000253' at position 783367646
Ну и далее show slave status нам говорит, что slave начал догонять master.
Happy end.
P.S. Альтерантивным вариантом посмотреть бинлог является команда SHOW BINLOG EVENTS. Например:
mysql> show binlog events in 's9-bin.000125' from 24084942 limit 10; +---------------+----------+-------------+-----------+-------------+------------------+ | Log_name | Pos | Event_type | Server_id | End_log_pos | Info | +---------------+----------+-------------+-----------+-------------+------------------+ | s9-bin.000125 | 24084942 | Write_rows | 8 | 24085025 | table_id: 244461 | | s9-bin.000125 | 24085025 | Update_rows | 8 | 24086045 | table_id: 244461 | | s9-bin.000125 | 24086045 | Write_rows | 8 | 24086128 | table_id: 244461 | | s9-bin.000125 | 24086128 | Update_rows | 8 | 24086518 | table_id: 244461 | | s9-bin.000125 | 24086518 | Write_rows | 8 | 24086600 | table_id: 244461 | | s9-bin.000125 | 24086600 | Update_rows | 8 | 24086876 | table_id: 244461 | | s9-bin.000125 | 24086876 | Write_rows | 8 | 24087008 | table_id: 244461 | | s9-bin.000125 | 24087008 | Update_rows | 8 | 24087138 | table_id: 244461 | | s9-bin.000125 | 24087138 | Write_rows | 8 | 24087221 | table_id: 244461 | | s9-bin.000125 | 24087221 | Update_rows | 8 | 24087611 | table_id: 244461 | +---------------+----------+-------------+-----------+-------------+------------------+ 10 rows in set (0.00 sec)
Posted in Howto.
Tagged with mysql, репликация.
– 05.07.2015
Если MySQL master-сервер по какой-то причине «упал», например из-за kernel panic или выключения питания, то после его запуска, вы можете увидеть на MySQL slave-сервер сообщение вида: Got fatal error 1236 from master when reading data from binary log: ‘Client requested master to start replication from position > file size’. При этом команда START SLAVE работать не будет. Что же делать в такой ситуации?
Всё это означает, что бинарный лог, который у вас есть на master-сервере повреждён в результате некорректного завершения MySQL. Допустим вывод команды: SHOW SLAVE STATUS G; на slave-сервере выглядит так:
mysql> show slave statusG
*************************** 1. row ***************************
Slave_IO_State:
Master_Host: 192.168.0.1
Master_User: replicator
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.004783
Read_Master_Log_Pos: 643318915
Relay_Log_File: db-master1-relay-bin.000747
Relay_Log_Pos: 635452116
Relay_Master_Log_File: mysql-bin.004783
Slave_IO_Running: No
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB: information_schema,mysql,performance_schema
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 643318915
Relay_Log_Space: 1701816887
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: NULL
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 1236
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'Client requested master to start replication from position > file size'
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 3
Master_UUID: 510103d3-3583-11e7-b931-00103007afb8
Master_Info_File: mysql.slave_master_info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp: 171128 08:35:49
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set:
Executed_Gtid_Set:
Auto_Position: 0
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
1 row in set (0.00 sec)
Тогда у вас два пути:
- Сделать дамп с master-сервера с ключём —master-data и перезалить дамп на slave-сервер. Однако, особенно на работающей системе, это не всегда возможно.
- Пропустить проблемное место. Для этого заходим на master-сервер и ищем первую валидную позицию в указанном бинарном логе (строка подсвечена красным):
# mysqlbinlog mysql-bin.004783 | tail -n 9
видим что такое:
'/*!*/;
# at 643202777
#171128 8:25:10 server id 1 end_log_pos 643202808 CRC32 0xc7842fa3 Xid = 167808175
COMMIT/*!*/;
SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/;
DELIMITER ;
# End of log file
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;
и искомую нами позицию 643202808.
Далее на slave-сервере выполняем команды:
stop slave; change master to master_log_file='mysql-bin.004783', master_log_pos=643202808; start slave;
После чего работа у вас восстанавливается и slave нагоняет master:
mysql> show slave statusG;
...
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
...
Seconds_Behind_Master: 0
...
Это мы сделали как бы отмотку назад, а можно сделать отмотку вперёд, т.е. выбрать следующий бинарный лог и перейти на первую валидную позицию в нём (4). Если отматывать назад, то некоторые транзакции будут пытаться накатится повторно, если вперёд, то часть транзакций будет потеряно, поэтому:
Внимание: Учтите, что при этом ваши базы на master’е и slave будут чем-то отличаться. Если это недопустимо — не применяйте данный способ!
- 5296 просмотров
Rebuild MySQL Master Master Replication after receiving the error below. This procedure can also be used to setup Mysql Master / Master replication.
Possible error in the mysql error log:
Got fatal error 1236 from master when reading data from binary log: 'Found old binary log without GTIDs while looking for the oldest binary log that contains any GTID that is not in the given gtid set', Error_code: 1236
This post is about the following configuration. A pair of MySQL servers running CENTOS 6.5 and MySQL 5.6.
The MySQL servers are running salves to one another Multi-Master. The SQL clients write to a Virtual IP which is configured to float between the MASTER and SLAVE in the event of a failover.
Reference Architecture:
MYSQLSERVER01 – Primary Master
MYSQLSERVER02 – Backup Master
Keepalived – Virtual IP
STEP 1: ON MYSQLSERVER02
Log into MySQL Workbench and execute the following commands
STOP SLAVE; RESET SLAVE; RESET MASTER;
STEP 2: ON MYSQLSERVER01
Log into MySQL Workbench and execute the following commands
STOP SLAVE; RESET SLAVE; RESET MASTER;
STEP 3: ON MYSQLSERVER01 take a backup with mysqldump from the master:
SSH into the server and execute the following
mysqldump --all-databases --single-transaction --triggers --routines --events --user=root -p > /tmp/dump.sql
STEP 4: ON MYSQLSERVER01 transfer the mysqldump backup file form MYSQLSERVER01 to MYSQLSERVER02
SSH into the server and execute the following
scp /tmp/dump.sql root@MYSQLSERVER02:/tmp/dump.sql
STEP 5: ON MYSQLSERVER01 load the mysqldump file
SSH into the server and execute the following
mysql -u root -p
STEP 6: ON MYSQLSERVER02
CHANGE MASTER TO MASTER_HOST='MYSQLSERVER01.lab.net', MASTER_USER='repl', MASTER_PASSWORD='replPassword', MASTER_AUTO_POSITION = 1;
STEP 7. ON MYSQLSERVER02
Verify the Slave_IO_Running and Slave_SQL_Running both have a status of YES
SHOW SLAVE STATUS; start slave; SHOW SLAVE STATUS;
STEP 8. ON MYSQLSERVER01
Log into MySQL Workbench and execute the following commands
CHANGE MASTER TO MASTER_HOST='MYSQLSERVER02.lab.net', MASTER_USER='repl', MASTER_PASSWORD='replPassword', MASTER_AUTO_POSITION = 1;
STEP 9. ON MYSQLSERVER01 start the slave and check the status of the slave operations
Log into MySQL Workbench and execute the following commands
Verify the Slave_IO_Running and Slave_SQL_Running both have a status of YES
SHOW SLAVE STATUS; start slave; SHOW SLAVE STATUS;
STEP 10. Additional testing can be done to confirm that the bi directional replication is working by inserting a record into the testdb.
Log into MySQL Workbench and execute the following commands
Perform insert test on MYSQLSERVER01, verify that the record has replicated to MYSQLSERVER02.