mysql log 记录报错 sql语句_MySQL生产库中添加修改表字段引起主从崩溃的问题总结...
上周末和開發人員對線上庫中的部分表的在線DDL和update，這過程中出現了一些意料之外的問題，現將過程、分析和解決方案在這里總結一下
一、 需求背景：
要在如下表中添加字段(modified_at)并且更改默認值
table_name {
baby_comp
baby_comp_status
baby_usr
baby_ad_user
baby_camp
baby_ord
baby_acc_eva
}
每張表執行如下操作
ALTER TABLE `$table_name` ADD COLUMN `modified_at` TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT ‘創建時間/最后修改時間‘");
更新的語句
UPDATE `baby_camp`
SET `modified_at` = FROM_UNIXTIME(updated_time + 60)
WHERE `modified_at` <= ‘1970-01-01 08:00:00‘;
二、 數據庫架構
master：192.168.100.18 >主庫寫數據復制源
slave1:192.168.100.17 >搜索用
slave2:192.168.100.19 >查詢用
slave3:192.168.100.10 >查詢用
slave4:192.168.100.15 >備份用
三、故障的相關信息截取：
問題 1. max binlog cache 不足引起的復制崩潰 涉及從庫(192.168.100.17-搜索用 和 192.168.100.15-備份用)
161009 21:42:49 [ERROR] Slave SQL: Could not execute Write_rows event on table baby.baby_delta; Multi-statement transaction required more than ‘max_binlog_cache_size‘ bytes of storage; increase this mysqld variable and try again, Error_code: 1197; Writing one row to the row-based binary log failed, Error_code: 1534; handler error HA_ERR_RBR_LOGGING_FAILED; the event‘s master log mysql-bin.007759, end_log_pos 3856759100, Error_code: 1197
161009 21:42:49 [Warning] Slave: Multi-statement transaction required more than ‘max_binlog_cache_size‘ bytes of storage; increase this mysqld variable and try?again Error_code: 1197
161009 21:42:49 [Warning] Slave: Writing one row to the row-based binary log failed Error_code: 1534
161009 21:42:49 [ERROR] Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log ‘mysql-bin.007759‘ position 633959791
161009 21:43:48 [ERROR] Error reading packet from server: Lost connection to MySQL server during query ( server_errno=2013)
161009 21:43:48 [Note] Slave I/O thread killed while reading event
161009 21:43:48 [Note] Slave I/O thread exiting, read up to log ‘mysql-bin.007760‘, position 301659
161009 21:43:53 [Note] Slave SQL thread initialized, starting replication in log ‘mysql-bin.007759‘ at position 633959791, relay log ‘./serverdb01-relay-bin.009618‘ position: 633959937
161009 21:43:53 [Note] Slave I/O thread: connected to master ‘[email?protected]:3306‘,replication started in log ‘mysql-bin.007760‘ at position 301659
++++
解釋：
報錯主要是：從庫上對于表baby.baby_delta的操作不能寫到binlog中，多語句的事物請求更多的max_binlog_cache_szie，增加max_binlog_cache_szie大小重試
++++
問題 2. max allowed packet 不足引起的復制崩潰 涉及從庫(192.168.100.15-備份用)
161009 21:42:49 [ERROR] Error reading packet from server: log event entry exceeded max_allowed_packet; Increase max_allowed_packet on master (server_errno=1236) 131118
161009 21:42:49 [ERROR] Slave I/O: Got fatal error 1236 from master when reading data from binary log: ‘log event entry exceeded max_allowed_packet; Increase max_allowed_packet on master‘, Error_code: 1236
++++
解釋：
報錯主要是：從庫讀取主庫的binlog的packet的大小超出了設定的max_allowed_packet大小,在主庫上增加此參數的值。
++++
四、 原因分析：
首先單獨操作了表：baby_ord, 此表數據量大大概4百多萬的數據條目.
其中在此表上有多個觸發器涉及到INSERT\UPDATE\DELETE操作,會觸發將相應的數據行插入到baby_delta表中,執行完除了主從延時并沒有出現其他的狀況
于是過于樂觀的認為余下的表沒有太大的數據量,除了主從延遲,不會造成其他的問題,索性就全部放在了集中一次發布中修改.
在DBMigrate后監控SQL在主庫的執行,主庫正常執行完成,從庫17和15出現復制崩潰.
查看變更完最后一批表后的binlog大小,其中mysql-bin.007759這一文件達到了將近9G,配置文件中限定產生的binlog文件的最大大小是1G
因為后面一批的表字段添加變更執行是一個事務,同一個事務產生的binlog不會被分配到兩個binlog文件中.導致出現上述問題 1和2
事后發現babysitter_campagin 表物理文件有6G大小,其中有幾個列的數據類型是text.
但為什么binlog文件會變得這么大呢？超出了限定大小？
因為主庫配置的binlog的格式是mixed,由系統根據SQL的類型判斷是記錄row格式還是stmt格式,但默認是記錄stmt格式的,那什么時候會記錄
row格式呢？
1.當SQL語句是update或者delete
row格式的缺點就是將每條數據的變化都詳細的記錄下來,結果就是binlog文件很大,會占用更大的binlog cache.
mysql> show master logs;
+------------------+------------+
| Log_name | File_size |
+------------------+------------+
| mysql-bin.007758 | 2514487585 |
| mysql-bin.007759 | 9107651572 |
+------------------+------------+
mysql> desc baby_camp;
+-----------------------------------+-----------------------+------+-----+-------------------+-----------------------------+
| Field | Type | Null | Key | Default | Extra |
+-----------------------------------+-----------------------+------+-----+-------------------+-----------------------------+
| content | mediumtext | YES | | NULL | |
| tweet_url | text | YES | | NULL | |
| note | text | YES | | NULL | |
| requirement | text | YES | | NULL | |
省略了部分內容。。。。
+-----------------------------------+-----------------------+------+-----+-------------------+-----------------------------+
mysql> select count(*) from baby_camp;
+----------+
| count(*) |
+----------+
| 1131460 |
+----------+
1 row in set (0.50 sec)
mysql> select count(*) from baby_delta;
+----------+
| count(*) |
+----------+
| 10136301 |
+----------+
1 row in set (1.12 sec)
五、再次有添加變更列,類型的需求的解決方案：
1.能不增加、不修改表列或者默認值盡量不要做,要求似乎不合情理啊,該做的還得做:(
2.多個表要變更字段等操作分批處理,減少binlog的產生,雖然麻煩一些,安全穩定重要
3.沒有辦法的辦法就是暴力改動數據庫的參數,缺點是有些參數需要重啟數據庫實例
六、疑惑之處：
復制的源主庫只有一個,其中17和15出現復制崩潰(注：都開啟了binlog,且格式是row,都會出現問題1,但是只有15問題1和2都出現了),而查詢專用的19和10兩從庫(注：兩庫都沒有開啟binlog)沒有出現問題2,不解？
原文：http://andylhz2009.blog.51cto.com/728703/1861133
總結
以上是生活随笔為你收集整理的mysql log 记录报错 sql语句_MySQL生产库中添加修改表字段引起主从崩溃的问题总结...的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Python进阶_wxpy学习：愉快的探
- 下一篇： linux cmake编译源码,linu