報(bào)錯(cuò)內(nèi)容

2016-04-29 00:09:57 9242 [ERROR] Slave SQL: Error 'This function has none of DETERMINISTIC, NO SQL, or READS SQL DATA in its declaration and binary logging is enabled (you *might* want to use the less safe log_bin_trust_function_creators variable)' on query. Default database: 'epsp_db'. Query: 'CREATE DEFINER=`unionpayb2b`@`%` FUNCTION `currval`(v_seq_name VARCHAR(50)) RETURNS int(11) BEGIN DECLARE val,val1 INTEGER; SET val = 0; SELECT current_val INTO val1 FROM tbl_sequence WHERE seq_name = v_seq_name; IF (val1 IS NULL)THENINSERT INTO tbl_sequence VALUES(v_seq_name,0,1);ELSESET val=val1;END IF;RETURN val; END', Error_code: 1418 2016-04-29 00:09:57 9242 [Warning] Slave: This function has none of DETERMINISTIC, NO SQL, or READS SQL DATA in its declaration and binary logging is enabled (you *might* want to use the less safe log_bin_trust_function_creators variable) Error_code: 1418 2016-04-29 00:09:57 9242 [Warning] Slave: Failed to CREATE FUNCTION currval Error_code: 1307 2016-04-29 00:09:57 9242 [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.000002' position 326441 2016-04-29 00:10:01 9242 [Note] /data/mysql/base/bin/mysqld: Normal shutdown

?

錯(cuò)誤分析1

根據(jù)錯(cuò)誤信息得知由于創(chuàng)建的這個(gè)函數(shù)對(duì)數(shù)據(jù)的操作對(duì)于replication場景,存在不確定性,也就是說這個(gè)函數(shù)在主庫和從庫上執(zhí)行可能產(chǎn)生不一樣的結(jié)果。 所以該函數(shù)在從庫應(yīng)用時(shí)產(chǎn)生了錯(cuò)誤,并導(dǎo)致從庫sql apply中斷,錯(cuò)誤信息中也記錄了中斷的文件及對(duì)應(yīng)的position點(diǎn)

?

錯(cuò)誤分析2

根據(jù)錯(cuò)誤信息給出的提示,可能需要設(shè)置log_bin_trust_function_creators這個(gè)變量來解決這個(gè)錯(cuò)誤 通過查詢官方文檔,得知了該參數(shù)的含義：log_bin_trust_function_creators這是一個(gè)安全參數(shù),針對(duì)于主從復(fù)制時(shí)對(duì)于函數(shù)和觸發(fā)器的處理,默認(rèn)值為0,表示不允許對(duì)數(shù)據(jù)操作存在不確定性的函數(shù)和觸發(fā)器的創(chuàng)建,因?yàn)檫@類語句會(huì)導(dǎo)致主從數(shù)據(jù)不一致的情況發(fā)生。同時(shí)官方文檔對(duì)這類語句產(chǎn)生不一致的場景進(jìn)行了進(jìn)一步說明：通常二進(jìn)制日志設(shè)置為statement或mixed格式時(shí)會(huì)出現(xiàn)這種情況，如果是row格式則不會(huì)，因?yàn)閞ow格式不是記錄的對(duì)這個(gè)函數(shù)的調(diào)用語句，而是記錄的函數(shù)調(diào)用后對(duì)行的改變的記錄。同樣對(duì)于觸發(fā)器也是一樣。所以在基于row格式的情況下不會(huì)發(fā)生這種不一致的情況。mixed格式雖然會(huì)根據(jù)不同的情況動(dòng)態(tài)的使用statement或row格式,但對(duì)于函數(shù)和觸發(fā)器，mixed總是使用statement方式進(jìn)行記錄，所以基于mixed格式也會(huì)存在這種問題。官方鏈接說明：https://dev.mysql.com/doc/refman/5.7/en/stored-programs-logging.html

?

解決辦法

[master/slave]修改二進(jìn)制日志格式為row格式
　　SHOW VARIABLES LIKE 'BIN%';
　　SET GLOBAL BINLOG_FORMAT=ROW
　　SET SESSION BINLOG_FORMAT=ROW
　　#vi /etc/my.cnf
　　 ##add
　　　 binlog_format = 1[master/slave]修改log_bin_trust_function_creators參數(shù)，將其設(shè)置為1
　　SHOW VARIABLES LIKE 'LOG_BIN_TRUST_FUNCTION_CREATORS';SET GLOBAL log_bin_trust_function_creators = 1;

提前啟用該參數(shù)，避免主從復(fù)制時(shí)函數(shù)或觸發(fā)器導(dǎo)致從庫復(fù)制中斷的問題，
但由于該參數(shù)開啟后，如果不是基于row格式的復(fù)制，很難保證當(dāng)執(zhí)行相關(guān)自定義的函數(shù)時(shí)，對(duì)數(shù)據(jù)的操作在主從上是一致的，存在不確定性，這也是為什么MySQL默認(rèn)是
禁止這類函數(shù)和觸發(fā)器的原因，目的是為了保持主從數(shù)據(jù)的一致性。所以建議可能的情況下，還是采用基于row格式的復(fù)制，并開啟該參數(shù)，避免產(chǎn)生相關(guān)錯(cuò)誤。
同時(shí)也要關(guān)注不同的日志格式的區(qū)別及對(duì)性能的影響。

?

轉(zhuǎn)載于:https://www.cnblogs.com/zhenxing/p/5460062.html

總結(jié)

以上是生活随笔為你收集整理的故障分析--主从复制故障1的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。