pos機錯誤碼ff,快速溯源與排查錯誤全解

網(wǎng)上有很多關(guān)于pos機錯誤碼ff,快速溯源與排查錯誤全解的知識，也有很多人為大家解答關(guān)于pos機錯誤碼ff的問(wèn)題，今天pos機之家(www.xjcwpx.cn)為大家整理了關(guān)于這方面的知識，讓我們一起來(lái)看下吧!

本文目錄一覽：

1、pos機錯誤碼ff

pos機錯誤碼ff

王松磊，現任職于UCloud，從事MySQL數據庫內核研發(fā)工作，主要負責UCloud云數據庫UDB的內核故障排查工作以及數據庫新特性的研發(fā)工作。

復制作為MySQL原生的數據同步功能，在MySQL高可用架構中起著(zhù)至關(guān)重要的作用。本文梳理了MySQL高可用產(chǎn)品UDB在日常運維中遇到的復制問(wèn)題，并總結了當復制發(fā)生異常時(shí)，排查復制異常的方法。

1、收集復制信息

在復制發(fā)生異常時(shí)，我們首先要收集復制相關(guān)的信息以及錯誤相關(guān)的信息，主要通過(guò)如下手段收集。

（1）查看show slave status

執行命令"show slave status"查看復制相關(guān)信息。主要關(guān)注以下幾條信息：

Master_Log_File: mysql-bin.000063

Read_Master_Log_Pos: 282657539

IO線(xiàn)程讀取到的主庫的binlog文件名和該binlog中的位置。這兩個(gè)字段代表復制過(guò)程中binlog由主庫傳輸到備庫的進(jìn)度。

Relay_Log_File: mysql-relay.000002

Relay_Log_Pos: 313885

SQL線(xiàn)程執行到的relay log的文件名和該relay log中的位置。

Relay_Master_Log_File: mysql-bin.000002

Exec_Master_Log_Pos: 316585

SQL線(xiàn)程執行到的relay log對應的主庫中的binlog文件名和該binlog的位置。

這四個(gè)字段代表復制過(guò)程中，主庫的數據在備庫上重放的進(jìn)度。

Slave_IO_Running: Yes

Slave_SQL_Running: No

當前發(fā)生問(wèn)題的是哪個(gè)線(xiàn)程，IO線(xiàn)程或者時(shí)SQL線(xiàn)程。

Retrieved_Gtid_Set: ed7c5ee4-762d-11e6-ab9e-6c92bf24c36a:14-3920163

Executed_Gtid_Set: 04ffb4f5-762e-11e6-81e4-6c92bf26c5c2:1

這兩個(gè)字段在開(kāi)啟GTID后才有意義。分別代表IO線(xiàn)程接收到的binlog中的事務(wù)對應的GTID和SQL線(xiàn)程執行過(guò)的事務(wù)對應的GTID。

這里的GTID不會(huì )因為復制而發(fā)生改變，即主庫的GTID對應的事務(wù)一定是主庫執行過(guò)之后，通過(guò)復制發(fā)送過(guò)來(lái)的。備庫的GTID對應的事務(wù)一定是備庫執行的。

Last_Errno/Last_IO_Errno/Last_SQL_Errno

Laset_Error/Last_IO_Error/Last_SQL_Error

IO/SQL線(xiàn)程發(fā)生的錯誤的相關(guān)描述。

（2）查看錯誤日志

錯誤日志記錄了mysqld發(fā)生的錯誤信息，即復制的錯誤信息，同時(shí)也會(huì )記錄復制的開(kāi)始和停止的相關(guān)信息，記錄位置可以通過(guò)如下方式查看：

在error log中，主要關(guān)注如下的信息。

開(kāi)始復制（start slave）

在從庫啟動(dòng)復制時(shí)，error log中會(huì )記錄復制起始位置，包括IO線(xiàn)程讀取主庫端binlog的起始位置和SQL線(xiàn)程執行的relay log的起始位置。同時(shí)error log中還會(huì )記錄開(kāi)始復制的具體時(shí)間。

停止復制（stop slave）

在從庫停止復制時(shí)，error log會(huì )記錄IO線(xiàn)程停止時(shí)讀取到的主庫的binlog的位置，以及停止復制的時(shí)間。

復制錯誤信息

復制錯誤信息的描述會(huì )在show slave status中的last_error中展現，但是如果錯誤信息較長(cháng)的話(huà)（尤其是在多線(xiàn)程復制的情況下），show slave status并不能完全的顯示錯誤的全部信息，需要查看錯誤日志才能查看到完整的錯誤信息。比如

上述錯誤信息并不是一個(gè)完整的錯誤信息描述，可以在error log中看到更完成的信息描述，以及發(fā)生錯誤的時(shí)間。

（3）查看二進(jìn)制日志文件

這里的二進(jìn)制日志文件包括主庫的binlog、從庫的relay log、從庫的binlog。

主庫的binlog是指主庫執行過(guò)的事務(wù)記錄的binlog日志。

從庫的relay log是指從庫接收到的主庫的binlog日志。

從庫的binlog是指從庫SQL線(xiàn)程復現relay log后記錄的日志（log-slave-updates開(kāi)啟）以及從庫執行過(guò)的事務(wù)記錄的binlog日志。

二進(jìn)制日志文件中記錄的日志是以event為單位進(jìn)行記錄，比如一個(gè)DML語(yǔ)句通常由4-5個(gè)event組成，一個(gè)DDL語(yǔ)句通常由2個(gè)event組成。

二進(jìn)制日志文件可以通過(guò)命令“show binlog events”或者工具mysqlbinlog來(lái)將binlog日志轉換為可識別的格式。

show binlog events格式如下：

上圖顯示的為ROW格式的binlog中記錄的內容，其中包含了一個(gè)DML語(yǔ)句和一條DDL語(yǔ)句。DML語(yǔ)句包含了GTID、QUERY、TABLE_MAP、WRITE_ROW、XID五個(gè)event，DDL語(yǔ)句包含了GTID、QUERY兩個(gè)event。

mysqlbinlog工具同樣可以解析binlog，提供與show binlog event類(lèi)似的event信息，以其中一個(gè)event為例來(lái)說(shuō)明：

Event的時(shí)間

為主庫執行事務(wù)的時(shí)間，無(wú)論從庫的relay log和binlog，時(shí)間均為主庫執行事務(wù)的時(shí)間

Event的server_id

記錄的是執行該事務(wù)的數據庫的server_id，可以用來(lái)區分這條事務(wù)是主庫還是從庫執行的

Event 的end_log_pos

從庫的relay log中的end_log_pos為對應的主庫中的binlog的該event的真實(shí)文件位置

主庫和從庫的binlog中的end_log_pos為該binlog的文件真實(shí)位置

EVENT的at xxx

at xxx代表該event在文件中的真實(shí)位置

對于以上的二進(jìn)制日志文件的內容，我們需要關(guān)注的信息包括：

Previous_gtids events記錄了當前binlog之前執行過(guò)的所有的gtid信息，用來(lái)定位具體的gtid。

GTID event中對應的GTID，與事務(wù)是一一對應的，表名該事務(wù)是由主庫執行還是由重庫執行的。

當錯誤發(fā)生時(shí)，事務(wù)執行的時(shí)間，事務(wù)的執行具體語(yǔ)句。

主庫執行數據庫操作后，將相關(guān)日志記錄到主庫的binlog中。備庫的IO線(xiàn)程接收到主庫傳輸的binlog日志后，將這些日志記錄到relay log中，如果備庫開(kāi)啟了log_slave_updates選項，那么SQL線(xiàn)程在重放relay log的過(guò)程中，會(huì )記錄相關(guān)binlog日志。這三個(gè)二進(jìn)制文件日志，執行內容上應該是相同的。

（4）查看其他變量

查看其他復制相關(guān)的系統變量或者狀態(tài)，如：

執行“show variables like‘gtid_mode’”查看gtid是否開(kāi)啟；

執行“show status like ‘Rpl_semi_sync_master_status’”查看半同步復制的狀態(tài)。

這里不再一一列舉。

在收集到以上復制信息后，主要通過(guò)如下手段排查復制錯誤：

1、查看show slave status

查看發(fā)生錯誤的是哪個(gè)線(xiàn)程（IO線(xiàn)程或者SQL線(xiàn)程），查看錯誤原因；

如果是IO線(xiàn)程發(fā)生錯誤，記錄發(fā)生錯誤時(shí)接收到的binlog的文件名和位置（如果開(kāi)啟了GTID則記錄GTID）；

如果是SQL線(xiàn)程發(fā)生錯誤，記錄發(fā)生錯誤時(shí)執行到的relay log的文件名和位置（如果開(kāi)啟了GTID則記錄GTID）。

2、查看錯誤日志

進(jìn)一步確認發(fā)生錯誤的原因，部分原因只會(huì )記錄在錯誤日志中，不會(huì )在show slave status中展示。比如空間不足導致IO線(xiàn)程出錯、比如網(wǎng)絡(luò )中斷導致IO線(xiàn)程異常等等。

查看是否是由于其他用戶(hù)正常關(guān)閉復制或者kill復制相關(guān)的線(xiàn)程導致復制不可用。

查看發(fā)生錯誤時(shí)，是否為剛剛啟動(dòng)復制、發(fā)生錯誤的語(yǔ)句是否為第一條復制執行的語(yǔ)句。如果為第一條語(yǔ)句，則需要考慮是否由于搭建復制錯誤的原因導致復制異常，是否由于意外宕機等其他因素導致復制相關(guān)二進(jìn)制日志文件不正確。

對比主庫和備庫的錯誤日志，查看是否均發(fā)生了同樣的復制錯誤，是否主庫做了特殊的錯誤處理。

3、對比二進(jìn)制日志文件

對比備庫正在接收的binlog與主庫正在執行的binlog是否存在沖突（備庫接收的binlog的文件和位置要大于主庫執行的）。

如果開(kāi)啟了GTID，查看備庫是否本身執行了數據庫操作產(chǎn)生了GTID，查看備庫執行過(guò)的GTID是否要多于主庫，備庫是否執行過(guò)其他主機的GTID。

根據發(fā)生錯誤時(shí)的binlog的文件和位置（或者GTID），解析主庫和備庫的二進(jìn)制文件，對比相同的文件和位置（或者相同的GTID）時(shí)日志中記錄的操作是否相同。

查看備庫的二進(jìn)制文件，備庫是否執行過(guò)與主庫沖突的操作。

總結

對于處于正常狀態(tài)的復制，應處于以下?tīng)顟B(tài)：

查看復制狀態(tài)應該是正常狀態(tài)，如show slave status顯示IO線(xiàn)程和SQL線(xiàn)程的運行狀態(tài)均為YES，如半同步復制中show status like “rpl%”顯示的半同步復制狀態(tài)為ON。

主庫和備庫均沒(méi)有復制相關(guān)的錯誤信息報出。

主庫和備庫的二進(jìn)制日志文件中記錄的數據庫操作內容應一致，主庫和備庫中的數據內容應保持一致。

通過(guò)對比分析上述信息，查看異常的狀態(tài)或者日志，可以為我們排查復制相關(guān)的錯誤提供更多的幫助。

總體來(lái)說(shuō)，版本和配置的不同，只是會(huì )造成各種信息的顯示格式不同，并不會(huì )對上述的方法造成過(guò)多的影響。

1、版本

上述信息收集和分析的舉例均是在mysql-5.7版本上進(jìn)行的舉例，不同的大版本在信息的內容或者信息的存放方式上可能存在一定的差異。

mysql-5.6版本與mysql-5.7版本在復制相關(guān)信息上存在以下差異：

日志：

在mysql-5.6在停止復制時(shí)，error log會(huì )有錯誤的信息記錄：

GTID：

mysql-5.6的gtid_executed以global system variables的方式的展現，mysql-5.7是以mysql.gtid_executed表的方式展現。

BINLOG：

mysql-5.6版本在使用自增ID時(shí)，會(huì )使用如下event來(lái)記錄自增ID。

#170419 11:27:12 server id 30061 end_log_pos 494 CRC32 0x7a9f75c6 Intvar

SET INSERT_ID=1/*!*/;

2、配置

主要體現差異的配置包括gtid_mode和binlog_format。

（1）gtid_mode

當gtid開(kāi)啟時(shí)，gtid作為判斷事務(wù)是由誰(shuí)執行，是否執行過(guò)、事務(wù)接收和執行進(jìn)度的判斷標準。同時(shí)可以通過(guò)show slave status可以直觀(guān)的看出gtid的接收、執行的情況。

當gtid關(guān)閉時(shí)，file和pos作為接收和執行的判斷標準，server_id作為事務(wù)由誰(shuí)執行的標準。但是事務(wù)對應的所有的server_id并沒(méi)有完全的展現出來(lái)，所以對于我們排查問(wèn)題，造成一定的困難。

（2）binlog_format

binlog_format影響的是記錄到binlog中的日志內容的格式，以同一條INSERT語(yǔ)句為例，statement格式記錄到binlog中的格式如下（只顯示差異部分）：

row格式記錄到binlog中的格式如下：

在收集到上述復制相關(guān)信息和錯誤信息后，我們需要根據實(shí)際的錯誤信息進(jìn)行分析，這里羅列了幾種常見(jiàn)的復制錯誤，我們可以通過(guò)部分或者全部在上述章節收集的相關(guān)信息，分析出復制錯誤發(fā)生原因。

1、從庫執行語(yǔ)句與主庫沖突

（1）錯誤原因

從庫執行DML語(yǔ)句或者DDL語(yǔ)句后，主庫和從庫會(huì )出現數據不一致的情況。從而導致主庫執行的語(yǔ)句在從庫沒(méi)有辦法正常執行。

（2）錯誤信息

由于從庫執行與主庫沖突的語(yǔ)句而導致復制錯誤，常見(jiàn)的錯誤信息如下：

創(chuàng )建庫或者表失敗

插入語(yǔ)句主鍵沖突

刪除語(yǔ)句找不到對應的語(yǔ)句

由于這是比較常見(jiàn)的原因，所有導致主從沖突的操作均會(huì )導致復制出錯，這里不再一一列舉。

（3）原因分析過(guò)程

這里以由于數據庫存在而導致創(chuàng )建數據庫出錯為例來(lái)分析原因。

查看error log

Error log中顯示的詳細錯誤信息如下：

顯示在執行GTID 0c1b77a7-c113-11e6-9bd6-d4ae52a34783:6時(shí)失敗。錯誤原因為數據庫已經(jīng)存在，無(wú)法創(chuàng )建。

查看show slave status

當錯誤發(fā)生后，查看show slave status顯示的信息時(shí)，會(huì )發(fā)現如下信息：

在Executed_Gtid_Set顯示的信息中，除了Master的UUID對應的GTID外，還存在另外一個(gè)GTID，我們可以查看從庫的GTID，執行如下語(yǔ)句：

發(fā)現另外的GTID是由從庫執行而產(chǎn)生的。

查看從庫binlog日志

從庫binlog日志記錄的是SQL線(xiàn)程復現的主機的binlog信息或者時(shí)從庫本身執行的事務(wù)的binlog日志。這些事務(wù)是可以通過(guò)server_id或者GTID來(lái)區分。

這里以創(chuàng )建數據庫失敗為例，在從庫binlog中，查找3a169e6c-f1d0-11e6-bb30-d4ae52a34783:1對應的事務(wù)，發(fā)現如下信息：

查看從庫relay log日志

從庫relay log日志記錄的是IO線(xiàn)程從主庫接收到的binlog日志信息，我們查看執行失敗的GTID對應的事務(wù)信息：

總結

最終可以確認是由于從庫執行了創(chuàng )建數據庫語(yǔ)句后，SQL線(xiàn)程再次執行創(chuàng )建數據庫的語(yǔ)句時(shí)發(fā)生復制失敗的情況。

2、主庫的binlog丟失

（1）錯誤原因

復制過(guò)程中，由于從庫需要讀取的主庫的binlog丟失，從而導致復制發(fā)生異常。導致主庫binlog丟失的主要原因如下：

主庫執行reset master命令

主庫執行purge binary/master logs命令

主庫設置了expire_logs_days，自動(dòng)刪除了binlog

主庫的binlog被誤刪除

（2）錯誤信息

如果發(fā)生找不到主機binlog的情況，從庫error log會(huì )報出如下錯誤：

（3）原因分析過(guò)程

查看error log

Error log中顯示的詳細錯誤信息如下：

錯誤信息顯示無(wú)法找到對應的binlog文件。

查看主庫binlog日志

查看主庫的binlog日志文件列表，可能會(huì )發(fā)現主庫的binlog變成重新開(kāi)始記錄：

或者需要復制的binlog已經(jīng)被刪除：

總結

如果binlog重新開(kāi)始記錄，通常是由于主庫執行了reset master命令，導致所有的binlog被刪除。

如果binlog任然在繼續記錄，只是從庫需要的binlog被刪除，通常是由于主庫手動(dòng)執行了purge binary logs命令，或者日志的保留時(shí)間超過(guò)了expire_logs_days設置的時(shí)間。

3、從庫沒(méi)有執行主庫復制的語(yǔ)句

由于GTID的特性，SQL線(xiàn)程不會(huì )去執行相同的GTID對應的事務(wù)，即如果SQL線(xiàn)程發(fā)現從relay log中讀取到的事務(wù)對應的GTID已經(jīng)存在于從庫的GTID_EXECUTED中，那么SQL線(xiàn)程便不會(huì )存在。

（1）錯誤原因

復制過(guò)程中，用于主庫執行的事務(wù)對應的GTID已經(jīng)存在于從庫的GTID_EXECUTED中，那么從庫便不會(huì )執行這些事務(wù)，從而導致主庫和從庫的數據不一致。通常有如下情況：

主機執行了reset master（從庫當前讀取主機的第一個(gè)binlog，并不會(huì )因為reset master而導致找不到文件）

重做主從，從庫沒(méi)有清除從庫的binlog

（2）錯誤信息

在從庫忽略主機執行的事務(wù)的過(guò)程中，從庫復制不會(huì )報出任何錯誤，所以這種復制的異常容易被忽略，沒(méi)有辦法及時(shí)的發(fā)現。

由于主庫和從庫的數據庫不一致，后續的DML和DDL操作可能會(huì )發(fā)生執行失敗的錯誤。

（3）原因分析過(guò)程

這里我們以插入語(yǔ)句找不到對應的表為例。

查看error log

Error log中記錄錯誤信息：

查看show slave status

show slave status顯示的信息全部正常，無(wú)從庫執行事務(wù)的binlog產(chǎn)生。這里不排除從庫關(guān)閉binlog執行drop table操作的可能。

查看表

分別在主機和從庫執行命令show create table mydb.mytbl4，發(fā)現從庫上并未不存在mydb.mytbl4。

（4）解析binlog日志

解析主機binlog日志，查看建表的事務(wù)日志：

解析從庫的binlog日志，查找是否存在建表的事務(wù)日志：

這時(shí)我們發(fā)現對于相同的GTID，從庫和主機執行的語(yǔ)句是不相同的。

（5）總結

通過(guò)上述分析，我們推斷是從庫并沒(méi)有執行建表語(yǔ)句，從而導致主庫數據不一致。

（6）說(shuō)明

這種情況在mysql-5.7版本會(huì )在復制時(shí)有更嚴格的校驗，如果主機發(fā)送GTID要少于從庫的GTID，那么會(huì )報告出如下的錯誤：

但是即使在5.7版本，如果啟動(dòng)復制的時(shí)（錯誤后重新啟動(dòng)），主庫執行的GTID超過(guò)了從庫，仍然會(huì )報出同樣的錯誤。

4、主庫執行了不進(jìn)行復制的語(yǔ)句

（1）錯誤原因

主庫上執行的操作并不會(huì )寫(xiě)入binlog。這里不考慮主庫主動(dòng)關(guān)閉binlog的情況。

（2）錯誤信息

由于主庫和從庫的數據不一致，從而導致主庫執行的操作復制到從庫后，發(fā)生從庫執行失敗的情況。如：

創(chuàng )建FEDERATED引擎的表失敗

（3）原因分析過(guò)程

這里以使用CONNECTION創(chuàng )建FEDERATED引擎的表為例。

查看error log

Error log中記錄錯誤信息：

查看主庫和從庫的server表

主庫中server表中存在名字為s的記錄：

從庫中不存在名字為s的記錄：

查看CREATE SERVER文檔說(shuō)明

文檔中記錄，create server語(yǔ)句并不會(huì )記錄到binlog中。所以導致了主庫和從庫的數據不一致。復制無(wú)法正常進(jìn)行。

總結

對于不記入binlog的操作，需要主庫和從庫同時(shí)執行，以防發(fā)生主庫和從庫不一致的情況。

5、從庫重復執行relay log的語(yǔ)句（非GTID，非多線(xiàn)程復制）

當變量relay_log_info_repository設置為FILE時(shí)，從庫的SQL線(xiàn)程每次執行完一個(gè)事務(wù)后，會(huì )把對應的文件和位置信息更新到文件relay_log.info中。用于在從庫重啟時(shí)，SQL能夠從正確的位置繼續進(jìn)行復制。

（1）錯誤原因

如果物理機發(fā)生宕機或者從庫發(fā)生意外中斷，那么可能發(fā)生SQL線(xiàn)程已經(jīng)執行過(guò)了某一個(gè)relay log中的事務(wù)，但是這個(gè)事務(wù)對應文件和位置信息并沒(méi)有及時(shí)更新到relay_log.info中的情況。在從庫發(fā)生重啟之后，會(huì )將執行過(guò)的事務(wù)重新再次執行。

（2）錯誤信息

重復執行的事務(wù)包括任何記錄到relay log中的事務(wù)，可能出現的錯誤信息包括：

創(chuàng )建庫或者表失?。?/p>

插入語(yǔ)句主鍵沖突：

刪除語(yǔ)句找不到對應的語(yǔ)句：

由于各種類(lèi)型的事務(wù)均可能執行，這里不再一一列舉。

（3）原因分析過(guò)程

這里以插入語(yǔ)句主鍵沖突為例。

查看error log

Error log中記錄以下報錯信息：

可以看到是SQL線(xiàn)程在啟動(dòng)后執行的第一個(gè)事務(wù)就發(fā)生主鍵沖突的錯誤。

查看show slave status

show slave status顯示的信息全部正常，無(wú)從庫執行事務(wù)的binlog產(chǎn)生。

查看表mydb.k2

表中已經(jīng)存在了這條記錄。

查看從庫的relay log和binlog

查看從庫的relay log，從復制的起始位置./relaylog002.000002：616查看

查看從庫的binlog：

總結

通過(guò)分析上述binlog內容，relay log中并沒(méi)有記錄相同的insert語(yǔ)句，而從庫的binlog顯示已經(jīng)執行過(guò)該語(yǔ)句，當從庫重啟后，試圖再次執行相同的insert語(yǔ)句，從而導致插入語(yǔ)句的主鍵沖突。

說(shuō)明

如果復制使用GTID，那么GTID的特性會(huì )使從庫不執行相同的語(yǔ)句。

如果在5.7版本復制使用多線(xiàn)程復制，那么mts_recovery會(huì )修復這個(gè)問(wèn)題。

只有在非多線(xiàn)程復制、非GTID復制的情況下才可能出現這個(gè)錯誤。

如果復制發(fā)生了錯誤，通過(guò)收集上述的復制相關(guān)信息和錯誤相關(guān)信息，分析這些信息中與正常復制異常的地方，便可為排查復制錯誤提供更多的可以用來(lái)排除異常的信息。

當然復制的錯誤是多種多樣的，并不是所有的錯誤都可以排查到具體的產(chǎn)生原因。很多復制錯誤是較難或者無(wú)法進(jìn)行排查的，比如主庫或者從庫的binlog日志文件已經(jīng)丟失、比如關(guān)閉binlog后執行某些操作導致復制不一致，再比如某些內核BUG導致MySQL的復制邏輯本身發(fā)生了異常等。

End.

來(lái)自：DBAplus社群

以上就是關(guān)于pos機錯誤碼ff,快速溯源與排查錯誤全解的知識，后面我們會(huì )繼續為大家整理關(guān)于pos機錯誤碼ff的知識，希望能夠幫助到大家！