MySQL 8.0因關閉Gtid 引發從庫故障

smartqiu發表於2021-11-19

前期,由於業務變更原因線上修改主從的GITD由ON到OFF,後面發從庫一旦start slave 就出現crash的情況,具體日誌如下:

09:00:22 UTC - mysqld got signal 11 ;
Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware.
Thread pointer: 0x7f9e440008f0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 7fa0c51ef098 thread_stack 0x30000
/usr/local/mysql/bin/mysqld(my_print_stacktrace(unsigned char const*, unsigned long)+0x2e) [0x1f40a3e]
/usr/local/mysql/bin/mysqld(handle_fatal_signal+0x323) [0xfd02b3]
/lib64/libpthread.so.0(+0xf5d0) [0x7fa0dce3f5d0]
/usr/local/mysql/bin/mysqld(ha_federated::rnd_pos(unsigned char*, unsigned char*)+0x2f) [0x23ffdcf]
/usr/local/mysql/bin/mysqld(handler::ha_rnd_pos(unsigned char*, unsigned char*)+0x16b) [0x10d734b]
/usr/local/mysql/bin/mysqld(Rows_log_event::do_index_scan_and_update(Relay_log_info const*)+0x100) [0x1b5ff60]
/usr/local/mysql/bin/mysqld(Rows_log_event::do_apply_event(Relay_log_info const*)+0x1426) [0x1b6ef46]
/usr/local/mysql/bin/mysqld(Log_event::apply_event(Relay_log_info*)+0x8d) [0x1b630dd]
/usr/local/mysql/bin/mysqld() [0x1bcd164]
/usr/local/mysql/bin/mysqld() [0x1bdc99a]
/usr/local/mysql/bin/mysqld(handle_slave_sql+0x2a41) [0x1bdfb41]
/usr/local/mysql/bin/mysqld() [0x245661c]
/lib64/libpthread.so.0(+0x7dd5) [0x7fa0dce37dd5]
/lib64/libc.so.6(clone+0x6d) [0x7fa0daf1dead]

後續檢視相關資訊,無法定位引發故障的具體原因。

判斷可能是從庫環境損壞,立即重新初始化從庫,匯入主庫匯入資料,start slave,出現一樣的錯誤,判斷問題出在 主庫端。

檢視主庫資訊

show variables ‘%gtid%’
show master status\G;

發現 gtid_purged,gtid_executed 仍然有值。想到清空該配置資訊。

由於系統公告上線不久,資料量還不是特別龐大。

主庫端執行:

reset master;

備庫端執行:

reset slave all;

重置主庫的所有binlog 資訊,順便清空了上述提到的gtid 配置資訊。

由於執行reset master 會清空所有的日誌資訊,如果已經儲存多個從庫或者資料量較大的情況建議評估後執行。

在做好相關備份操作後執行 主庫reset 操作。重新搭建從庫

start slave;

從庫沒有再出現之前的錯誤資訊。


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/70008134/viewspace-2843033/,如需轉載,請註明出處,否則將追究法律責任。

相關文章