網上有很多關于pos機刷卡慢,分析慢查詢導致主從宕機的知識，也有很多人為大家解答關于pos機刷卡慢的問題，今天pos機之家(www.www690aa.com)為大家整理了關于這方面的知識，讓我們一起來看下吧!
本文目錄一覽：
1、pos機刷卡慢
pos機刷卡慢
標簽mysql主從中斷， 慢查詢，慢查詢太大，my_net_writ()
作者Matthew
時間2022-02-09
告警出現告警！觸發告警名: 192.168.32.79:MySQL IO thread stopped告警開始時間:2022.02.09 09:08:20告警狀態: PROBLEM告警級別: 嚴重監控項值:Slave IO thread running (06_slave_192.168.32.79:mysql.slave.Slave_IO_Running): Connecting原始事件ID: 170558153當前時間:2022.02.09 09:08:23查看錯誤日志
數據庫異常的時間。022-02-09T08:42:12.598396+08:00 50408604 [Note] Aborted connection 50408604 to db: 'finenter' user: 'finenter' host: '192.168.50.56' (Got an error reading communication packets)2022-02-09T01:07:34.069934Z mysqld_safe Number of processes running now: 02022-02-09T01:07:34.073206Z mysqld_safe mysqld restarted2022-02-09T09:07:34.308228+08:00 0 [Warning] 'NO_ZERO_DATE', 'NO_ZERO_IN_DATE' and 'ERROR_FOR_DIVISION_BY_ZERO' sql modes should be used with strict mode. They will be merged with strict mode in a future release.2022-02-09T09:07:34.308361+08:00 0 [Note] --secure-file-priv is set to NULL. Operations related to importing and exporting data are disabled2022-02-09T09:07:34.308395+08:00 0 [Note] /usr/local/mysql/bin/mysqld (mysqld 5.7.16-log) starting as process 22048 ..這一段是mysql開始啟動的sql2022-02-09T09:07:37.104002+08:00 0 [Note] InnoDB: Opened 3 undo tablespaces2022-02-09T09:07:37.104025+08:00 0 [Note] InnoDB: 3 undo tablespaces made active2022-02-09T09:07:37.104252+08:00 0 [Note] InnoDB: Highest supported file format is Barracuda.2022-02-09T09:07:37.303950+08:00 0 [Note] InnoDB: Log scan progressed past the checkpoint lsn 93524331760522022-02-09T09:07:37.304003+08:00 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 93524331811522022-02-09T09:07:37.501117+08:00 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 93524331811522022-02-09T09:07:37.506272+08:00 0 [Note] InnoDB: Database was not shutdown normally!2022-02-09T09:07:37.506291+08:00 0 [Note] InnoDB: Starting crash recovery.2022-02-09T09:07:37.816635+08:00 0 [Note] InnoDB: transaction 11296772973 was in the XA prepared state.2022-02-09T09:07:37.824610+08:00 0 [Note] InnoDB: Transaction 11296772973 was in the XA prepared state.2022-02-09T09:07:37.828609+08:00 0 [Note] InnoDB: Transaction 11296772975 was in the XA prepared state.2022-02-09T09:07:37.828632+08:00 0 [Note] InnoDB: Transaction 11296772975 was in the XA prepared state.2022-02-09T09:07:37.828647+08:00 0 [Note] InnoDB: 2 transaction(s) which must be rolled back or cleaned up in total 0 row operations to undo數據庫啟動完成2022-02-09T09:07:41.579857+08:00 0 [Note] /usr/local/mysql/bin/mysqld: ready for connections.Version: '5.7.16-log' socket: '/usr/local/mysql/mysql.sock' port: 3306 MySQL Community Server (GPL)2022-02-09T09:07:44.746676+08:00 47 [Note] Aborted connection 47 to db: 'unconnected' user: 'app_finenter' host: '192.168.50.116' (Got an error reading communication packets)2022-02-09T09:07:45.907252+08:00 75 [Note] Aborted connection 75 to db: 'unconnected' user: 'app_finenter' host: '192.168.50.115' (Got an error reading communication packets)2022-02-09T09:08:34.038236+08:00 259 [Note] Start binlog_dump to master_thread_id(259) slave_server(32110), pos(, 4)2022-02-09T09:08:34.039017+08:00 260 [Note] Start binlog_dump to master_thread_id(260) slave_server(3280), pos(, 4)2022-02-09T09:08:34.042458+08:00 261 [Note] Start binlog_dump to master_thread_id(261) slave_server(3279), pos(, 4)2022-02-09T09:08:34.046842+08:00 262 [Note] Start binlog_dump to master_thread_id(262) slave_server(3309), pos(, 4)2022-02-09T09:08:34.077449+08:00 264 [Note] Start binlog_dump to master_thread_id(264) slave_server(3217), pos(, 4)2022-02-09T09:08:34.083366+08:00 261 [Note] Aborted connection 261 to db: 'unconnected' user: 'repl' host: '192.168.32.79' (Failed on my_net_write())2022-02-09T09:08:34.111652+08:00 263 [Note] Start binlog_dump to master_thread_id(263) slave_server(3331), pos(, 4)2022-02-09T09:09:12.242692+08:00 0 [Note] InnoDB: Buffer pool(s) load completed at 220209 9:09:12重啟原因
用pt工具分析一個比較大的慢查詢文件，資源不夠用導致mysql異常重啟了從庫報錯
Last_IO_Error: Fatal error: Failed to run 'after_read_event' hook分析源碼
我們知道,mysqld是一個多線程的C/S架構的網絡應用，因此少不了通過網絡來讀寫數據，所以可能會出現寫數據失敗的情況。如果mysql的錯誤日志中出現此類錯誤，就說明是mysqld在向客戶端發送網絡包時失敗導致的，當然，引申到復制場景，則說明是復制過程中，master向slave推送binlog時，寫網絡數據包失敗。查看master_dump_thread 邏輯
需要確定master在send binlog失敗的情況下退出dump thread的邏輯，根據錯誤日志提示，進入到相關的代碼查看。錯誤代碼在如下位置inline int Binlog_sender::send_packet(){ DBUG_ENTER("Binlog_sender::send_packet"); DBUG_PRINT("info", ("Sending event of type %s", Log_event::get_type_str( (Log_event_type)m_packet.ptr()[1 + EVENT_TYPE_OFFSET]))); // We should always use the same buffer to guarantee that the reallocation // logic is not broken. if (DBUG_EVALUATE_IF("simulate_send_error", true, my_net_write( m_thd->get_protocol_classic()->get_net(), (uchar*) m_packet.ptr(), m_packet.length()))) { set_unknow_error("Failed on my_net_write()"); DBUG_RETURN(1); }
調用關系
(gdb) bt#0 Binlog_sender::send_packet (this=0x7fea741655d0) at /data/mysql-server-explain_ddl/sql/rpl_binlog_sender.cc:1158#1 0x000000000190f74e in Binlog_sender::send_packet_and_flush (this=0x7fea741655d0) at /data/mysql-server-explain_ddl/sql/rpl_binlog_sender.cc:1182#2 0x000000000190e181 in Binlog_sender::send_heartbeat_event (this=0x7fea741655d0, log_pos=504) at /data/mysql-server-explain_ddl/sql/rpl_binlog_sender.cc:1143#3 0x000000000190ee01 in Binlog_sender::wait_with_heartbeat (this=0x7fea741655d0, log_pos=504) at /data/mysql-server-explain_ddl/sql/rpl_binlog_sender.cc:633#4 0x000000000190ecd7 in Binlog_sender::wait_new_events (this=0x7fea741655d0, log_pos=504) at /data/mysql-server-explain_ddl/sql/rpl_binlog_sender.cc:599#5 0x000000000190e938 in Binlog_sender::get_binlog_end_pos (this=0x7fea741655d0, log_cache=0x7fea74165020) at /data/mysql-server-explain_ddl/sql/rpl_binlog_sender.cc:365#6 0x000000000190c5e0 in Binlog_sender::send_binlog (this=0x7fea741655d0, log_cache=0x7fea74165020, start_pos=123) at /data/mysql-server-explain_ddl/sql/rpl_binlog_sender.cc:313#7 0x000000000190c1b4 in Binlog_sender::run (this=0x7fea741655d0) at /data/mysql-server-explain_ddl/sql/rpl_binlog_sender.cc:225結果層層返回到Binlog_sender::run
大致看下Binlog_sender::run的邏輯
void Binlog_sender::run(){ while (!has_error() && !m_thd->killed) { if (send_binlog(&log_cache, start_pos)) break; }}
解釋到這里，大概就清楚了吧。
以上就是關于pos機刷卡慢,分析慢查詢導致主從宕機的知識，后面我們會繼續為大家整理關于pos機刷卡慢的知識，希望能夠幫助到大家！
