網(wǎng)上有很多關(guān)于pos機(jī)錯(cuò)誤碼ff,快速溯源與排查錯(cuò)誤全解的知識(shí)，也有很多人為大家解答關(guān)于pos機(jī)錯(cuò)誤碼ff的問題，今天pos機(jī)之家(m.afbey.com)為大家整理了關(guān)于這方面的知識(shí)，讓我們一起來看下吧!
本文目錄一覽：
pos機(jī)錯(cuò)誤碼ff
作者介紹王松磊，現(xiàn)任職于UCloud，從事MySQL數(shù)據(jù)庫(kù)內(nèi)核研發(fā)工作，主要負(fù)責(zé)UCloud云數(shù)據(jù)庫(kù)UDB的內(nèi)核故障排查工作以及數(shù)據(jù)庫(kù)新特性的研發(fā)工作。
復(fù)制作為MySQL原生的數(shù)據(jù)同步功能，在MySQL高可用架構(gòu)中起著至關(guān)重要的作用。本文梳理了MySQL高可用產(chǎn)品UDB在日常運(yùn)維中遇到的復(fù)制問題，并總結(jié)了當(dāng)復(fù)制發(fā)生異常時(shí)，排查復(fù)制異常的方法。
一、錯(cuò)誤排查1、收集復(fù)制信息
在復(fù)制發(fā)生異常時(shí)，我們首先要收集復(fù)制相關(guān)的信息以及錯(cuò)誤相關(guān)的信息，主要通過如下手段收集。
（1）查看show slave status
執(zhí)行命令"show slave status"查看復(fù)制相關(guān)信息。主要關(guān)注以下幾條信息：
Master_Log_File: mysql-bin.000063
Read_Master_Log_Pos: 282657539
IO線程讀取到的主庫(kù)的binlog文件名和該binlog中的位置。這兩個(gè)字段代表復(fù)制過程中binlog由主庫(kù)傳輸?shù)絺鋷?kù)的進(jìn)度。
Relay_Log_File: mysql-relay.000002
Relay_Log_Pos: 313885
SQL線程執(zhí)行到的relay log的文件名和該relay log中的位置。
Relay_Master_Log_File: mysql-bin.000002
Exec_Master_Log_Pos: 316585
SQL線程執(zhí)行到的relay log對(duì)應(yīng)的主庫(kù)中的binlog文件名和該binlog的位置。
這四個(gè)字段代表復(fù)制過程中，主庫(kù)的數(shù)據(jù)在備庫(kù)上重放的進(jìn)度。
Slave_IO_Running: Yes
Slave_SQL_Running: No
當(dāng)前發(fā)生問題的是哪個(gè)線程，IO線程或者時(shí)SQL線程。
Retrieved_Gtid_Set: ed7c5ee4-762d-11e6-ab9e-6c92bf24c36a:14-3920163
Executed_Gtid_Set: 04ffb4f5-762e-11e6-81e4-6c92bf26c5c2:1
這兩個(gè)字段在開啟GTID后才有意義。分別代表IO線程接收到的binlog中的事務(wù)對(duì)應(yīng)的GTID和SQL線程執(zhí)行過的事務(wù)對(duì)應(yīng)的GTID。
這里的GTID不會(huì)因?yàn)閺?fù)制而發(fā)生改變，即主庫(kù)的GTID對(duì)應(yīng)的事務(wù)一定是主庫(kù)執(zhí)行過之后，通過復(fù)制發(fā)送過來的。備庫(kù)的GTID對(duì)應(yīng)的事務(wù)一定是備庫(kù)執(zhí)行的。
Last_Errno/Last_IO_Errno/Last_SQL_Errno
Laset_Error/Last_IO_Error/Last_SQL_Error
IO/SQL線程發(fā)生的錯(cuò)誤的相關(guān)描述。
（2）查看錯(cuò)誤日志
錯(cuò)誤日志記錄了mysqld發(fā)生的錯(cuò)誤信息，即復(fù)制的錯(cuò)誤信息，同時(shí)也會(huì)記錄復(fù)制的開始和停止的相關(guān)信息，記錄位置可以通過如下方式查看：
在error log中，主要關(guān)注如下的信息。
開始復(fù)制（start slave）
在從庫(kù)啟動(dòng)復(fù)制時(shí)，error log中會(huì)記錄復(fù)制起始位置，包括IO線程讀取主庫(kù)端binlog的起始位置和SQL線程執(zhí)行的relay log的起始位置。同時(shí)error log中還會(huì)記錄開始復(fù)制的具體時(shí)間。
停止復(fù)制（stop slave）
在從庫(kù)停止復(fù)制時(shí)，error log會(huì)記錄IO線程停止時(shí)讀取到的主庫(kù)的binlog的位置，以及停止復(fù)制的時(shí)間。
復(fù)制錯(cuò)誤信息
復(fù)制錯(cuò)誤信息的描述會(huì)在show slave status中的last_error中展現(xiàn)，但是如果錯(cuò)誤信息較長(zhǎng)的話（尤其是在多線程復(fù)制的情況下），show slave status并不能完全的顯示錯(cuò)誤的全部信息，需要查看錯(cuò)誤日志才能查看到完整的錯(cuò)誤信息。比如
上述錯(cuò)誤信息并不是一個(gè)完整的錯(cuò)誤信息描述，可以在error log中看到更完成的信息描述，以及發(fā)生錯(cuò)誤的時(shí)間。
（3）查看二進(jìn)制日志文件
這里的二進(jìn)制日志文件包括主庫(kù)的binlog、從庫(kù)的relay log、從庫(kù)的binlog。
主庫(kù)的binlog是指主庫(kù)執(zhí)行過的事務(wù)記錄的binlog日志。
從庫(kù)的relay log是指從庫(kù)接收到的主庫(kù)的binlog日志。
從庫(kù)的binlog是指從庫(kù)SQL線程復(fù)現(xiàn)relay log后記錄的日志（log-slave-updates開啟）以及從庫(kù)執(zhí)行過的事務(wù)記錄的binlog日志。
二進(jìn)制日志文件中記錄的日志是以event為單位進(jìn)行記錄，比如一個(gè)DML語句通常由4-5個(gè)event組成，一個(gè)DDL語句通常由2個(gè)event組成。
二進(jìn)制日志文件可以通過命令“show binlog events”或者工具mysqlbinlog來將binlog日志轉(zhuǎn)換為可識(shí)別的格式。
show binlog events格式如下：
上圖顯示的為ROW格式的binlog中記錄的內(nèi)容，其中包含了一個(gè)DML語句和一條DDL語句。DML語句包含了GTID、QUERY、TABLE_MAP、WRITE_ROW、XID五個(gè)event，DDL語句包含了GTID、QUERY兩個(gè)event。
mysqlbinlog工具同樣可以解析binlog，提供與show binlog event類似的event信息，以其中一個(gè)event為例來說明：
Event的時(shí)間
為主庫(kù)執(zhí)行事務(wù)的時(shí)間，無論從庫(kù)的relay log和binlog，時(shí)間均為主庫(kù)執(zhí)行事務(wù)的時(shí)間
Event的server_id
記錄的是執(zhí)行該事務(wù)的數(shù)據(jù)庫(kù)的server_id，可以用來區(qū)分這條事務(wù)是主庫(kù)還是從庫(kù)執(zhí)行的
Event 的end_log_pos
從庫(kù)的relay log中的end_log_pos為對(duì)應(yīng)的主庫(kù)中的binlog的該event的真實(shí)文件位置
主庫(kù)和從庫(kù)的binlog中的end_log_pos為該binlog的文件真實(shí)位置
EVENT的at xxx
at xxx代表該event在文件中的真實(shí)位置
對(duì)于以上的二進(jìn)制日志文件的內(nèi)容，我們需要關(guān)注的信息包括：
Previous_gtids events記錄了當(dāng)前binlog之前執(zhí)行過的所有的gtid信息，用來定位具體的gtid。
GTID event中對(duì)應(yīng)的GTID，與事務(wù)是一一對(duì)應(yīng)的，表名該事務(wù)是由主庫(kù)執(zhí)行還是由重庫(kù)執(zhí)行的。
當(dāng)錯(cuò)誤發(fā)生時(shí)，事務(wù)執(zhí)行的時(shí)間，事務(wù)的執(zhí)行具體語句。
主庫(kù)執(zhí)行數(shù)據(jù)庫(kù)操作后，將相關(guān)日志記錄到主庫(kù)的binlog中。備庫(kù)的IO線程接收到主庫(kù)傳輸?shù)腷inlog日志后，將這些日志記錄到relay log中，如果備庫(kù)開啟了log_slave_updates選項(xiàng)，那么SQL線程在重放relay log的過程中，會(huì)記錄相關(guān)binlog日志。這三個(gè)二進(jìn)制文件日志，執(zhí)行內(nèi)容上應(yīng)該是相同的。
（4）查看其他變量
查看其他復(fù)制相關(guān)的系統(tǒng)變量或者狀態(tài)，如：
執(zhí)行“show variables like‘gtid_mode’”查看gtid是否開啟；
執(zhí)行“show status like ‘Rpl_semi_sync_master_status’”查看半同步復(fù)制的狀態(tài)。
這里不再一一列舉。
二、排查錯(cuò)誤在收集到以上復(fù)制信息后，主要通過如下手段排查復(fù)制錯(cuò)誤：
1、查看show slave status
查看發(fā)生錯(cuò)誤的是哪個(gè)線程（IO線程或者SQL線程），查看錯(cuò)誤原因；
如果是IO線程發(fā)生錯(cuò)誤，記錄發(fā)生錯(cuò)誤時(shí)接收到的binlog的文件名和位置（如果開啟了GTID則記錄GTID）；
如果是SQL線程發(fā)生錯(cuò)誤，記錄發(fā)生錯(cuò)誤時(shí)執(zhí)行到的relay log的文件名和位置（如果開啟了GTID則記錄GTID）。
2、查看錯(cuò)誤日志
進(jìn)一步確認(rèn)發(fā)生錯(cuò)誤的原因，部分原因只會(huì)記錄在錯(cuò)誤日志中，不會(huì)在show slave status中展示。比如空間不足導(dǎo)致IO線程出錯(cuò)、比如網(wǎng)絡(luò)中斷導(dǎo)致IO線程異常等等。
查看是否是由于其他用戶正常關(guān)閉復(fù)制或者kill復(fù)制相關(guān)的線程導(dǎo)致復(fù)制不可用。
查看發(fā)生錯(cuò)誤時(shí)，是否為剛剛啟動(dòng)復(fù)制、發(fā)生錯(cuò)誤的語句是否為第一條復(fù)制執(zhí)行的語句。如果為第一條語句，則需要考慮是否由于搭建復(fù)制錯(cuò)誤的原因?qū)е聫?fù)制異常，是否由于意外宕機(jī)等其他因素導(dǎo)致復(fù)制相關(guān)二進(jìn)制日志文件不正確。
對(duì)比主庫(kù)和備庫(kù)的錯(cuò)誤日志，查看是否均發(fā)生了同樣的復(fù)制錯(cuò)誤，是否主庫(kù)做了特殊的錯(cuò)誤處理。
3、對(duì)比二進(jìn)制日志文件
對(duì)比備庫(kù)正在接收的binlog與主庫(kù)正在執(zhí)行的binlog是否存在沖突（備庫(kù)接收的binlog的文件和位置要大于主庫(kù)執(zhí)行的）。
如果開啟了GTID，查看備庫(kù)是否本身執(zhí)行了數(shù)據(jù)庫(kù)操作產(chǎn)生了GTID，查看備庫(kù)執(zhí)行過的GTID是否要多于主庫(kù)，備庫(kù)是否執(zhí)行過其他主機(jī)的GTID。
根據(jù)發(fā)生錯(cuò)誤時(shí)的binlog的文件和位置（或者GTID），解析主庫(kù)和備庫(kù)的二進(jìn)制文件，對(duì)比相同的文件和位置（或者相同的GTID）時(shí)日志中記錄的操作是否相同。
查看備庫(kù)的二進(jìn)制文件，備庫(kù)是否執(zhí)行過與主庫(kù)沖突的操作。
總結(jié)
對(duì)于處于正常狀態(tài)的復(fù)制，應(yīng)處于以下狀態(tài)：
查看復(fù)制狀態(tài)應(yīng)該是正常狀態(tài)，如show slave status顯示IO線程和SQL線程的運(yùn)行狀態(tài)均為YES，如半同步復(fù)制中show status like “rpl%”顯示的半同步復(fù)制狀態(tài)為ON。
主庫(kù)和備庫(kù)均沒有復(fù)制相關(guān)的錯(cuò)誤信息報(bào)出。
主庫(kù)和備庫(kù)的二進(jìn)制日志文件中記錄的數(shù)據(jù)庫(kù)操作內(nèi)容應(yīng)一致，主庫(kù)和備庫(kù)中的數(shù)據(jù)內(nèi)容應(yīng)保持一致。
通過對(duì)比分析上述信息，查看異常的狀態(tài)或者日志，可以為我們排查復(fù)制相關(guān)的錯(cuò)誤提供更多的幫助。
三、版本和配置總體來說，版本和配置的不同，只是會(huì)造成各種信息的顯示格式不同，并不會(huì)對(duì)上述的方法造成過多的影響。
1、版本
上述信息收集和分析的舉例均是在mysql-5.7版本上進(jìn)行的舉例，不同的大版本在信息的內(nèi)容或者信息的存放方式上可能存在一定的差異。
mysql-5.6版本與mysql-5.7版本在復(fù)制相關(guān)信息上存在以下差異：
日志：
在mysql-5.6在停止復(fù)制時(shí)，error log會(huì)有錯(cuò)誤的信息記錄：
GTID：
mysql-5.6的gtid_executed以global system variables的方式的展現(xiàn)，mysql-5.7是以mysql.gtid_executed表的方式展現(xiàn)。
BINLOG：
mysql-5.6版本在使用自增ID時(shí)，會(huì)使用如下event來記錄自增ID。
#170419 11:27:12 server id 30061 end_log_pos 494 CRC32 0x7a9f75c6 Intvar
SET INSERT_ID=1/*!*/;
2、配置
主要體現(xiàn)差異的配置包括gtid_mode和binlog_format。
（1）gtid_mode
當(dāng)gtid開啟時(shí)，gtid作為判斷事務(wù)是由誰執(zhí)行，是否執(zhí)行過、事務(wù)接收和執(zhí)行進(jìn)度的判斷標(biāo)準(zhǔn)。同時(shí)可以通過show slave status可以直觀的看出gtid的接收、執(zhí)行的情況。
當(dāng)gtid關(guān)閉時(shí)，file和pos作為接收和執(zhí)行的判斷標(biāo)準(zhǔn)，server_id作為事務(wù)由誰執(zhí)行的標(biāo)準(zhǔn)。但是事務(wù)對(duì)應(yīng)的所有的server_id并沒有完全的展現(xiàn)出來，所以對(duì)于我們排查問題，造成一定的困難。
（2）binlog_format
binlog_format影響的是記錄到binlog中的日志內(nèi)容的格式，以同一條INSERT語句為例，statement格式記錄到binlog中的格式如下（只顯示差異部分）：
row格式記錄到binlog中的格式如下：
四、常見復(fù)制錯(cuò)誤原因及分析過程在收集到上述復(fù)制相關(guān)信息和錯(cuò)誤信息后，我們需要根據(jù)實(shí)際的錯(cuò)誤信息進(jìn)行分析，這里羅列了幾種常見的復(fù)制錯(cuò)誤，我們可以通過部分或者全部在上述章節(jié)收集的相關(guān)信息，分析出復(fù)制錯(cuò)誤發(fā)生原因。
1、從庫(kù)執(zhí)行語句與主庫(kù)沖突
（1）錯(cuò)誤原因
從庫(kù)執(zhí)行DML語句或者DDL語句后，主庫(kù)和從庫(kù)會(huì)出現(xiàn)數(shù)據(jù)不一致的情況。從而導(dǎo)致主庫(kù)執(zhí)行的語句在從庫(kù)沒有辦法正常執(zhí)行。
（2）錯(cuò)誤信息
由于從庫(kù)執(zhí)行與主庫(kù)沖突的語句而導(dǎo)致復(fù)制錯(cuò)誤，常見的錯(cuò)誤信息如下：
創(chuàng)建庫(kù)或者表失敗
插入語句主鍵沖突
刪除語句找不到對(duì)應(yīng)的語句
由于這是比較常見的原因，所有導(dǎo)致主從沖突的操作均會(huì)導(dǎo)致復(fù)制出錯(cuò)，這里不再一一列舉。
（3）原因分析過程
這里以由于數(shù)據(jù)庫(kù)存在而導(dǎo)致創(chuàng)建數(shù)據(jù)庫(kù)出錯(cuò)為例來分析原因。
查看error log
Error log中顯示的詳細(xì)錯(cuò)誤信息如下：
顯示在執(zhí)行GTID 0c1b77a7-c113-11e6-9bd6-d4ae52a34783:6時(shí)失敗。錯(cuò)誤原因?yàn)閿?shù)據(jù)庫(kù)已經(jīng)存在，無法創(chuàng)建。
查看show slave status
當(dāng)錯(cuò)誤發(fā)生后，查看show slave status顯示的信息時(shí)，會(huì)發(fā)現(xiàn)如下信息：
在Executed_Gtid_Set顯示的信息中，除了Master的UUID對(duì)應(yīng)的GTID外，還存在另外一個(gè)GTID，我們可以查看從庫(kù)的GTID，執(zhí)行如下語句：
發(fā)現(xiàn)另外的GTID是由從庫(kù)執(zhí)行而產(chǎn)生的。
查看從庫(kù)binlog日志
從庫(kù)binlog日志記錄的是SQL線程復(fù)現(xiàn)的主機(jī)的binlog信息或者時(shí)從庫(kù)本身執(zhí)行的事務(wù)的binlog日志。這些事務(wù)是可以通過server_id或者GTID來區(qū)分。
這里以創(chuàng)建數(shù)據(jù)庫(kù)失敗為例，在從庫(kù)binlog中，查找3a169e6c-f1d0-11e6-bb30-d4ae52a34783:1對(duì)應(yīng)的事務(wù)，發(fā)現(xiàn)如下信息：
查看從庫(kù)relay log日志
從庫(kù)relay log日志記錄的是IO線程從主庫(kù)接收到的binlog日志信息，我們查看執(zhí)行失敗的GTID對(duì)應(yīng)的事務(wù)信息：
總結(jié)
最終可以確認(rèn)是由于從庫(kù)執(zhí)行了創(chuàng)建數(shù)據(jù)庫(kù)語句后，SQL線程再次執(zhí)行創(chuàng)建數(shù)據(jù)庫(kù)的語句時(shí)發(fā)生復(fù)制失敗的情況。
2、主庫(kù)的binlog丟失
（1）錯(cuò)誤原因
復(fù)制過程中，由于從庫(kù)需要讀取的主庫(kù)的binlog丟失，從而導(dǎo)致復(fù)制發(fā)生異常。導(dǎo)致主庫(kù)binlog丟失的主要原因如下：
主庫(kù)執(zhí)行reset master命令
主庫(kù)執(zhí)行purge binary/master logs命令
主庫(kù)設(shè)置了expire_logs_days，自動(dòng)刪除了binlog
主庫(kù)的binlog被誤刪除
（2）錯(cuò)誤信息
如果發(fā)生找不到主機(jī)binlog的情況，從庫(kù)error log會(huì)報(bào)出如下錯(cuò)誤：
（3）原因分析過程
查看error log
Error log中顯示的詳細(xì)錯(cuò)誤信息如下：
錯(cuò)誤信息顯示無法找到對(duì)應(yīng)的binlog文件。
查看主庫(kù)binlog日志
查看主庫(kù)的binlog日志文件列表，可能會(huì)發(fā)現(xiàn)主庫(kù)的binlog變成重新開始記錄：
或者需要復(fù)制的binlog已經(jīng)被刪除：
總結(jié)
如果binlog重新開始記錄，通常是由于主庫(kù)執(zhí)行了reset master命令，導(dǎo)致所有的binlog被刪除。
如果binlog任然在繼續(xù)記錄，只是從庫(kù)需要的binlog被刪除，通常是由于主庫(kù)手動(dòng)執(zhí)行了purge binary logs命令，或者日志的保留時(shí)間超過了expire_logs_days設(shè)置的時(shí)間。
3、從庫(kù)沒有執(zhí)行主庫(kù)復(fù)制的語句
由于GTID的特性，SQL線程不會(huì)去執(zhí)行相同的GTID對(duì)應(yīng)的事務(wù)，即如果SQL線程發(fā)現(xiàn)從relay log中讀取到的事務(wù)對(duì)應(yīng)的GTID已經(jīng)存在于從庫(kù)的GTID_EXECUTED中，那么SQL線程便不會(huì)存在。
（1）錯(cuò)誤原因
復(fù)制過程中，用于主庫(kù)執(zhí)行的事務(wù)對(duì)應(yīng)的GTID已經(jīng)存在于從庫(kù)的GTID_EXECUTED中，那么從庫(kù)便不會(huì)執(zhí)行這些事務(wù)，從而導(dǎo)致主庫(kù)和從庫(kù)的數(shù)據(jù)不一致。通常有如下情況：
主機(jī)執(zhí)行了reset master（從庫(kù)當(dāng)前讀取主機(jī)的第一個(gè)binlog，并不會(huì)因?yàn)閞eset master而導(dǎo)致找不到文件）
重做主從，從庫(kù)沒有清除從庫(kù)的binlog
（2）錯(cuò)誤信息
在從庫(kù)忽略主機(jī)執(zhí)行的事務(wù)的過程中，從庫(kù)復(fù)制不會(huì)報(bào)出任何錯(cuò)誤，所以這種復(fù)制的異常容易被忽略，沒有辦法及時(shí)的發(fā)現(xiàn)。
由于主庫(kù)和從庫(kù)的數(shù)據(jù)庫(kù)不一致，后續(xù)的DML和DDL操作可能會(huì)發(fā)生執(zhí)行失敗的錯(cuò)誤。
（3）原因分析過程
這里我們以插入語句找不到對(duì)應(yīng)的表為例。
查看error log
Error log中記錄錯(cuò)誤信息：
查看show slave status
show slave status顯示的信息全部正常，無從庫(kù)執(zhí)行事務(wù)的binlog產(chǎn)生。這里不排除從庫(kù)關(guān)閉binlog執(zhí)行drop table操作的可能。
查看表
分別在主機(jī)和從庫(kù)執(zhí)行命令show create table mydb.mytbl4，發(fā)現(xiàn)從庫(kù)上并未不存在mydb.mytbl4。
（4）解析binlog日志
解析主機(jī)binlog日志，查看建表的事務(wù)日志：
解析從庫(kù)的binlog日志，查找是否存在建表的事務(wù)日志：
這時(shí)我們發(fā)現(xiàn)對(duì)于相同的GTID，從庫(kù)和主機(jī)執(zhí)行的語句是不相同的。
（5）總結(jié)
通過上述分析，我們推斷是從庫(kù)并沒有執(zhí)行建表語句，從而導(dǎo)致主庫(kù)數(shù)據(jù)不一致。
（6）說明
這種情況在mysql-5.7版本會(huì)在復(fù)制時(shí)有更嚴(yán)格的校驗(yàn)，如果主機(jī)發(fā)送GTID要少于從庫(kù)的GTID，那么會(huì)報(bào)告出如下的錯(cuò)誤：
但是即使在5.7版本，如果啟動(dòng)復(fù)制的時(shí)（錯(cuò)誤后重新啟動(dòng)），主庫(kù)執(zhí)行的GTID超過了從庫(kù)，仍然會(huì)報(bào)出同樣的錯(cuò)誤。
4、主庫(kù)執(zhí)行了不進(jìn)行復(fù)制的語句
（1）錯(cuò)誤原因
主庫(kù)上執(zhí)行的操作并不會(huì)寫入binlog。這里不考慮主庫(kù)主動(dòng)關(guān)閉binlog的情況。
（2）錯(cuò)誤信息
由于主庫(kù)和從庫(kù)的數(shù)據(jù)不一致，從而導(dǎo)致主庫(kù)執(zhí)行的操作復(fù)制到從庫(kù)后，發(fā)生從庫(kù)執(zhí)行失敗的情況。如：
創(chuàng)建FEDERATED引擎的表失敗
（3）原因分析過程
這里以使用CONNECTION創(chuàng)建FEDERATED引擎的表為例。
查看error log
Error log中記錄錯(cuò)誤信息：
查看主庫(kù)和從庫(kù)的server表
主庫(kù)中server表中存在名字為s的記錄：
從庫(kù)中不存在名字為s的記錄：
查看CREATE SERVER文檔說明
文檔中記錄，create server語句并不會(huì)記錄到binlog中。所以導(dǎo)致了主庫(kù)和從庫(kù)的數(shù)據(jù)不一致。復(fù)制無法正常進(jìn)行。
總結(jié)
對(duì)于不記入binlog的操作，需要主庫(kù)和從庫(kù)同時(shí)執(zhí)行，以防發(fā)生主庫(kù)和從庫(kù)不一致的情況。
5、從庫(kù)重復(fù)執(zhí)行relay log的語句（非GTID，非多線程復(fù)制）
當(dāng)變量relay_log_info_repository設(shè)置為FILE時(shí)，從庫(kù)的SQL線程每次執(zhí)行完一個(gè)事務(wù)后，會(huì)把對(duì)應(yīng)的文件和位置信息更新到文件relay_log.info中。用于在從庫(kù)重啟時(shí)，SQL能夠從正確的位置繼續(xù)進(jìn)行復(fù)制。
（1）錯(cuò)誤原因
如果物理機(jī)發(fā)生宕機(jī)或者從庫(kù)發(fā)生意外中斷，那么可能發(fā)生SQL線程已經(jīng)執(zhí)行過了某一個(gè)relay log中的事務(wù)，但是這個(gè)事務(wù)對(duì)應(yīng)文件和位置信息并沒有及時(shí)更新到relay_log.info中的情況。在從庫(kù)發(fā)生重啟之后，會(huì)將執(zhí)行過的事務(wù)重新再次執(zhí)行。
（2）錯(cuò)誤信息
重復(fù)執(zhí)行的事務(wù)包括任何記錄到relay log中的事務(wù)，可能出現(xiàn)的錯(cuò)誤信息包括：
創(chuàng)建庫(kù)或者表失?。?/p>
插入語句主鍵沖突：
刪除語句找不到對(duì)應(yīng)的語句：
由于各種類型的事務(wù)均可能執(zhí)行，這里不再一一列舉。
（3）原因分析過程
這里以插入語句主鍵沖突為例。
查看error log
Error log中記錄以下報(bào)錯(cuò)信息：
可以看到是SQL線程在啟動(dòng)后執(zhí)行的第一個(gè)事務(wù)就發(fā)生主鍵沖突的錯(cuò)誤。
查看show slave status
show slave status顯示的信息全部正常，無從庫(kù)執(zhí)行事務(wù)的binlog產(chǎn)生。
查看表mydb.k2
表中已經(jīng)存在了這條記錄。
查看從庫(kù)的relay log和binlog
查看從庫(kù)的relay log，從復(fù)制的起始位置./relaylog002.000002：616查看
查看從庫(kù)的binlog：
總結(jié)
通過分析上述binlog內(nèi)容，relay log中并沒有記錄相同的insert語句，而從庫(kù)的binlog顯示已經(jīng)執(zhí)行過該語句，當(dāng)從庫(kù)重啟后，試圖再次執(zhí)行相同的insert語句，從而導(dǎo)致插入語句的主鍵沖突。
說明
如果復(fù)制使用GTID，那么GTID的特性會(huì)使從庫(kù)不執(zhí)行相同的語句。
如果在5.7版本復(fù)制使用多線程復(fù)制，那么mts_recovery會(huì)修復(fù)這個(gè)問題。
只有在非多線程復(fù)制、非GTID復(fù)制的情況下才可能出現(xiàn)這個(gè)錯(cuò)誤。
五、總結(jié)如果復(fù)制發(fā)生了錯(cuò)誤，通過收集上述的復(fù)制相關(guān)信息和錯(cuò)誤相關(guān)信息，分析這些信息中與正常復(fù)制異常的地方，便可為排查復(fù)制錯(cuò)誤提供更多的可以用來排除異常的信息。
當(dāng)然復(fù)制的錯(cuò)誤是多種多樣的，并不是所有的錯(cuò)誤都可以排查到具體的產(chǎn)生原因。很多復(fù)制錯(cuò)誤是較難或者無法進(jìn)行排查的，比如主庫(kù)或者從庫(kù)的binlog日志文件已經(jīng)丟失、比如關(guān)閉binlog后執(zhí)行某些操作導(dǎo)致復(fù)制不一致，再比如某些內(nèi)核BUG導(dǎo)致MySQL的復(fù)制邏輯本身發(fā)生了異常等。
End.
來自：DBAplus社群
國(guó)統(tǒng)計(jì)網(wǎng)，是國(guó)內(nèi)最早的大數(shù)據(jù)學(xué)習(xí)網(wǎng)站，歡迎關(guān)注！以上就是關(guān)于pos機(jī)錯(cuò)誤碼ff,快速溯源與排查錯(cuò)誤全解的知識(shí)，后面我們會(huì)繼續(xù)為大家整理關(guān)于pos機(jī)錯(cuò)誤碼ff的知識(shí)，希望能夠幫助到大家！
