MySQL如何查看复制信息与排查复制问题.docxVIP

UCLoud中国云三强: MySQL如何查看复制信息和排查复制问题 复制作为MySQL原生的数据同步功能，在MySQL高可用架构中起着至关重要的作用。本文梳理了在运维本公司MySQL高可用产品UDB的过程中遇到的复制问题，并总结了当复制发生异常时，排查复制异常的方法。 错误排查 01收集复制信息 在复制发生异常时，我们首先要收集复制相关的信息以及错误相关的信息，主要通过如下手段收集。 1.查看show slave status 执行命令show slave status查看复制相关信息。主要关注以下几条信息： Master_Log_File: mysql-bin.000063Read_Master_Log_Pos: 282657539 IO线程读取到的主库的binlog文件名和该binlog中的位置。这两个字段代表复制过程中binlog由主库传输到备库的进度。 Relay_Log_File: mysql-relay.000002Relay_Log_Pos: 313885 SQL线程执行到的relay log的文件名和该relay log中的位置。 Relay_Master_Log_File: mysql-bin.000002Exec_Master_Log_Pos: 316585 SQL线程执行到的relay log对应的主库中的binlog文件名和该binlog的位置。这四个字段代表复制过程中，主库的数据在备库上重放的进度。 Slave_IO_Running: YesSlave_SQL_Running: No 当前发生问题的是哪个线程，IO线程或者时SQL线程。 Retrieved_Gtid_Set: ed7c5ee4-762d-11e6-ab9e-6c92bf24c36a:14-3920163Executed_Gtid_Set: 04ffb4f5-762e-11e6-81e4-6c92bf26c5c2:1 这两个字段在开启GTID后才有意义。分别代表IO线程接收到的binlog中的事务对应的GTID和SQL线程执行过的事务对应的GTID。  这里的GTID不会因为复制而发生改变，即主库的GTID对应的事务一定是主库执行过之后，通过复制发送过来的。备库的GTID对应的事务一定是备库执行的。 Last_Errno/Last_IO_Errno/Last_SQL_ErrnoLaset_Error/Last_IO_Error/Last_SQL_Error IO/SQL线程发生的错误的相关描述。 2.查看错误日志 错误日志记录了MySQL发生的错误信息，即复制的错误信息，同时也会记录复制的开始和停止的相关信息，记录位置可以通过如下方式查看： 在error log中，主要关注如下的信息: 开始复制（start slave） 在从库启动复制时，error log中会记录复制起始位置，包括IO线程读取主库端binlog的起始位置和SQL线程执行的relay log的起始位置。同时error log中还会记录开始复制的具体时间。  2017-04-17T14:47:19.691088Z 7 [Note] Slave I/O thread for channel : connected to master repl@1:30001,replication started in log binlog001.000002 at position 1942017-04-17T14:47:19.693377Z 8 [Note] Slave SQL thread for channel initialized, starting replication in log binlog001.000002 at position 194, relay log ./relaylog002.000217 position: 407  停止复制（stop slave） 在从库停止复制时，error log会记录IO线程停止时读取到的主库的binlog的位置，以及停止复制的时间。 2017-04-18T03:05:52.920750Z 14 [Note] Error reading relay log event for channel : slave SQL thread was killed2017-04-18T03:05:52.922007Z 13 [Note] Slave I/O thread killed while reading event for channel 2017-04-18T03:05:52.922041Z 13