无锡网站建设 微信,品牌设计公司深圳,网站建设合同应注意,微信开发者社区一、从库复制延迟问题 1、可能的原因如下#xff08;1#xff09;主从服务器处于不同的网络之中#xff0c;由于网络延迟导致#xff1b;#xff08;2#xff09;主从服务器的硬件配置不同#xff0c;从服务器的硬件配置#xff08;包括内存#xff0c;CPU#xff0c…一、从库复制延迟问题 1、可能的原因如下1主从服务器处于不同的网络之中由于网络延迟导致2主从服务器的硬件配置不同从服务器的硬件配置包括内存CPU网卡等远低于主服务器3主库上有大量的写入操作导致从库无法实时重放主库上的binlog4主库上存在着大事务操作或者慢SQL导致从库在应用主库binlog的过程过慢形成延迟5数据库实例的参数配置问题导致如从库开启了binlog或者配置了每次事务都去做刷盘操作 2、主从同步延迟问题判断1根据从库上的状态参数判断 mysql-server-3307 SHOW SLAVE STATUS \G 在输出结果中找到Seconds_Behind_Master参数这个参数表示的是从库上的IO线程和SQL线程相差的时间然后根据该参数值判断这个值只是初步判断不能由这个值来下结论有如下几种情况a、0表示无延迟理想状态b、NULL表示从库上的IO线程和SQL线程中有某一个线程出现问题可以再次查看Slave_IO_Running和Slave_SQL_Running的值是否都为Yesc、大于0表示主从已经出现延迟这个值越大表示从库和主库之间的延迟越严重d、小于0这个值在官方文档中没有说明通常不会出现。如果出现那恭喜你中奖了撞见MySQL的bug了 2根据主从库上面当前应用的二进制日志文件名称或者重放日志的位置来判断① 同时打开两个MySQL的命令行窗口分别打开主库和从库在第一个窗口上执行查看主库当前状态的命令 mysql-server-3306 SHOW MASTER STATUS \G
*************************** 1. row ***************************File: mysql-bin.000017Position: 120Binlog_Do_DB: Binlog_Ignore_DB:
Executed_Gtid_Set:
1 row in set (0.00 sec) ② 在第二个从库的命令行窗口执行如下命令 mysql-server-3307 SHOW SLAVE STATUS \G
*************************** 1. row ***************************Slave_IO_State: Waiting for master to send event...Connect_Retry: 60Master_Log_File: mysql-bin.000017Read_Master_Log_Pos: 120Relay_Log_File: relay-log.000016Relay_Log_Pos: 283Relay_Master_Log_File: mysql-bin.000017Slave_IO_Running: YesSlave_SQL_Running: Yes...Last_Errno: 0Last_Error: Skip_Counter: 0Exec_Master_Log_Pos: 120Relay_Log_Space: 613Until_Condition: NoneUntil_Log_File: Until_Log_Pos: 0...Seconds_Behind_Master: 0...Replicate_Ignore_Server_Ids: Master_Server_Id: 3Master_UUID: 2dbbf79b-5d9f-11e8-8004-000c29e28409Master_Info_File: /mysql_data/3307/data/master.infoSQL_Delay: 0SQL_Remaining_Delay: NULL ③ 比较从库上的Master_Log_File和Relay_Master_Log_File文件之间是否有差异a、如果有差异则说明主从延迟很严重b、如果没有差异则比较Read_Master_Log_Pos和Exec_Master_Log_Pos的差异这俩参数分别表示从库当前读取到的主库的二进制日志文件位置点和已经执行到的位置点c、如果上述输出都没有差异可以通过主库上show master status和从库上show slave status的结果作比较。主要比较主库的File和从库的Master_Log_File主库上的Position和从库上的Read_Master_Log_Pos 3、主从延迟解决办法1判断是否由于网络导致方法测试主从库之间的网络延迟比如测试ping延迟。同时可以检查主从同步的时候是否使用了主库的域名来同步而域名解析速度可能会特别慢。或者使用其他测试工具2判断是否由于硬件环境导致方法确认主从库的硬件配置是否相差较大如果配置参数相差较大可以排查从库上的CPU内存IO使用率来判断是否因为硬件配置导致3判断是否在主库上有大量的DML操作方法可以再主库上通过show full processlist命令查看当前正在执行的sql查看是否有大量正在执行的SQL或者观察主库的CPU和内存使用率判断是否有高并发操作4判断是否有慢SQl可以再主库上临时打开慢SQL记录临时打开方法如下 #开启慢SQL功能并查看是否生效
mysql-server-3306 SET GLOBAL.slow_query_log ON;
mysql-server-3306 SHOW VARIABLES LIKE slow_query_log;
#设置慢SQL的时间并查看是否生效单位为s表示大于多少秒的SQL会被记录
mysql-server-3306 SET GLOBAL.long_query_time 5;
mysql-server-3306 SHOW VARIABLES LIKE long_query_time;
#设置慢SQL记录日志路径并查看是否生效。注意这个目录必须对MySQL用户有读写权限
mysql-server-3306 SET GLOBAL.slow_query_log_file /mysql_data/mysql-slow.log;
mysql-server-3306 SHOW VARIABLES LIKE slow_query_log_file; 5检查从服务器参数配置是否合理① 查看从库是否开启了binlog日志从库上执行如下命令查看 mysql-server-3307 SHOW VARIABLES LIKE log_bin; 如果开启了binlog日志而且从库未充当其他库的主库时可以将从库上的binlog关闭否则会增加从库负担每次重放完成主库的binlog还要记录到自身的binlog ② 查看从库上的sync_binlog参数的值这个参数表示的是事务提交多少次之后由MySQL来将binlog_cache中的数据刷新到磁盘有以下几种值0表示事务提交之后MySQL不做刷新binlog_cache到磁盘的操作而是由操作系统来定时自动完成刷盘操作这种操作对性能损耗最少但是也最不安全n表示提交n次事务之后由MySQL将binlog_cache中的数据刷新到磁盘如果开启会对性能有一定程度的损耗。所以从库上如果延迟很严重可以考虑将该参数的值设为0 mysql-server-3307 SET GLOBAL.sync_binlog 0;
mysql-server-3307 SHOW VARIABLES LIKE sync_binlog;
----------------------
| Variable_name | Value |
----------------------
| sync_binlog | 0 |
----------------------
1 row in set (0.00 sec) ③ 如果从库中要同步的数据库使用的是InnoDB存储引擎可以查看innodb_flush_log_at_trx_commit参数。这个参数表示事务执行完成之后多久的频率刷新一次日志到磁盘上可用的值有如下几种0表示MySQL会将日志缓冲区中的数据每秒一次地写入日志文件中并且日志文件的刷盘操作同时进行。该模式下在事务提交的时候不会主动触发写入磁盘的操作效率最搞但是安全性也比较低可能会丢失数据1每一次事务提交都需要把日志写入磁盘这个过程是特别耗时的操作2每一次事务提交之后不会自动触发日志刷盘的操作而是由操作系统来决定什么时候来做刷新日志的操作在操作系统挂了的情况下才会丢失数据如果在主从延迟非常严重的情况下可以将从库的该参数设置为0以提高从库上重放主库二进制日志的效率。 mysql-server-3307 SET GLOBAL.innodb_flush_log_at_trx_commit 0;
mysql-server-3307 SHOW VARIABLES LIKE innodb_flush_log_at_trx_commit;
---------------------------------------
| Variable_name | Value |
---------------------------------------
| innodb_flush_log_at_trx_commit | 0 |
---------------------------------------
1 row in set (0.00 sec)注意上述设计到修改MySQL数据库实例的操作中修改之后会立刻生效但是重启实例之后会失效如果要永久修改则需要编辑mysql配置文件然后重启。
