mysql从库同步慢,[数据库同步慢]mysql数据库从库同步延迟的问题

在从属服务器上执行show slave状态；您可以查看许多同步参数。我们需要特别注意的参数如下。希望本文对您有所帮助。

在从服务器上执行show slave状态；您可以查看许多同步参数，我们需要特别注意的参数如下:

Master_Log_File:我在SLAVE中/O线程当前正在读取的主服务器二进制日志文件的名称

Read_Master_Log_Pos:在当前的主服务器二进制日志中，我在SLAVE中/O线程已读取该位置

Relay_Log_File:当前正在由SQL线程读取和执行的中继日志文件的名称

Relay_Log_Pos:在当前中继日志中，SQL线程已读取并执行的位置

Relay_Master_Log_File:由包含最新事件的SQL线程执行的主服务器的二进制日志文件的名称

Slave_IO_Running:我/O线程已启动并成功连接到主服务器

Slave_SQL_Running:是否启动SQL线程

Seconds_Behind_Master:从服务器SQL线程和从服务器I之间的时间间隔/O线程，以秒为单位。

从库的同步延迟 1 ，显示从站状态显示参数Seconds_Behind_Master不为0，此值可能非常大 2，显示从属状态显示参数Relay_Master_Log_File和Master_Log_File显示bin-log编号有很大不同，表明bin-log不太及时从库同步，所以最近执行的bin-log与bin-当前IO线程读取的日志有很大不同 3，大量的mysql-relay-日志日志存在于mysql从属数据中目录，日志同步完成后，系统会自动将其删除。有大量日志，指示主从同步非常延迟。

一个。 MySQL数据库主从同步延迟原理

mysql主从同步的原理:

主库为写操作顺序写入binlog，然后从单线程库到主库顺序读取写操作的binlog。库中的binlog在本地执行(随机写入)，以确保主从数据在逻辑上是一致的。

MySQL的主从复制是一个单线程操作。主库为所有DDL和DML生成binlog。 Binlog是顺序写入的，因此效率非常高。从属服务器的Slave_IO_Running线程将日志获取到主库。效率比较高。下一步，问题来了从属服务器的Slave_SQL_Running线程实现了从属服务器中主库的DDL和DML操作。 DML和DDL的IO操作是随机的，不是顺序的，并且成本要高得多。它还可能导致从属服务器上其他查询的锁争用。由于Slave_SQL_Running也是单线程的，因此DDL卡主设备需要执行10分钟。然后，所有后续DDL将在继续执行之前等待此DDL完成执行，这将导致延迟。

一些朋友会问:"主库上的相同DDL也需要执行10分，为什么从属设备会延迟？"答案是master可以是并发的，而Slave_SQL_Running线程则不能。

b。 MySQL数据库主从同步延迟如何发生？

当主库的TPS并发性很高时，生成的DDL的数量超出了从属sql线程可以承受的范围，那么就会生成延迟，并且当然，在从属的大型查询语句中可能会发生锁定等待。

主要原因:数据库对业务的读写压力太大，CPU计算负荷大，网卡负荷大，硬盘随机IO太高

次要原因:由于读写binlog造成的性能影响，网络传输延迟。

C。 MySQL数据库主从同步延迟解决方案。

建筑 1 。业务持久层的实现使用子数据库架构，并且mysql服务可以并行扩展和分散压力。 2 。单个库读写分开，一个主控和多个从属，主控写从属读，分散压力。这样，二级存储器的压力高于一级存储器的压力，从而保护了一级存储器。 3 。服务基础架构在业务和mysql Floor之间添加了memcache或redis缓存。降低mysql的读取压力。 4 。不同企业的MySQL在物理上放置在不同的计算机上以分散压力。 5 。使用比主库更好的硬件设备作为从属设备

总之，mysql的压力较小，延迟自然会变小。

硬件 1 。使用良好的服务器，例如4u的性能明显优于2u，2u的性能优于1u。 2 。使用存储SSD或磁盘阵列或san来提高随机写入的性能。 3 。保证主机和从机在同一交换机上且处于10 Gb环境中。

总之，硬件很强大，延迟自然会变小。简而言之，减少延迟的解决方案是花费金钱和时间。

MySQL主从同步 1 ，在从属端将sync_binlog设置为0 2，\ ndash; logs-slave-更新从服务器从主服务器接收的更新不要登录其二进制日志。 3 ，直接在从属端禁用binlog 4，从属端，如果使用的存储引擎是innodb，则innodb_flush_log_at_trx_commit = 2 从文件系统本身的角度进行优化

主人方

修改Linux和Unix文件系统中文件的etime属性。由于操作系统每次读取文件都会将读取操作的时间写回磁盘，因此对于具有频繁读取操作的数据库文件而言，这不是必需的，只是增加磁盘系统的负担会影响I/O性能。您可以通过设置文件系统的mount属性来组织操作系统以写入时间信息。 Linux上的操作是:

打开/etc/fstab，添加noatime参数/dev/sdb1/data reiserfs noatime 1 2 然后重新挂载文件系统

#mount-oremount/数据

PS:

主库已编写并且具有很高的数据安全性，例如sync_binlog = 1，innodb_flush_log_at_trx_commit = 1 需要这样的设置

Slave不需要如此高的数据安全性，可以说将sync_binlog设置为0或关闭binlog，也可以将innodb_flushlog设置为0以提高SQL执行效率 1，sync_binlog = 1 o

MySQL提供了一个sync_binlog参数来控制数据库binlog闪存到磁盘。

默认情况下，sync_binlog = 0 ，这意味着MySQL不控制binlog的刷新，以及文件系统本身控制其缓存的刷新。此时的性能是最好的，但是风险也是最大的。一旦系统崩溃，binlog_cache中的所有binlog信息都将丢失。

如果sync_binlog \ gt; 0，这意味着每个sync_binlog事务都会提交，MySQL会调用文件系统刷新操作来刷新缓存。最安全的是sync_binlog = 1，这意味着MySQL每次提交事务时都会清除binlog，这是最安全的，但性能损失设置最大。在这种情况下，仅当数据库所在主机的操作系统损坏或突然断电时，系统才可能丢失一个事务的数据。

尽管binlog是顺序IO，但设置sync_binlog = 1 ，会同时提交多个事务，这也极大地影响了MySQL和IO的性能。

尽管可以通过组提交补丁来缓解，但是刷新频率过高对IO的影响也很大。对于具有高并发事务的系统，

\\ u00ldquo; sync_binlog \\"设置为0并设置为1，系统写性能差距可能高达5倍或更多。

因此，许多MySQL DBA设置的sync_binlog不是最安全的，而是2或0。这牺牲了一定的一致性以实现更高的并发性和性能。

默认情况下，binlog不会在每次写入时都与硬盘同步。因此，如果操作系统或计算机(不仅仅是MySQL服务器)崩溃，则二进制日志中的最后一条语句可能会丢失。为防止这种情况，可以在每写入N个binlog后使用sync_binlog全局变量(1是最安全的值，但也是最慢的值)将binlog与硬盘同步。即使将sync_binlog设置为1，当发生崩溃时，表的内容与binlog的内容之间也可能存在不一致。 2 ，innodb_flush_log_at_trx_commit(效果很好)

抱怨Innodb比MyISAM慢100倍？然后，您可能忘了调整此值。默认值1表示每个事务提交或事务结束指令都需要将日志刷新到硬盘，这非常耗时。特别是在使用电池备份缓存时。对于许多应用程序，将其设置为2，尤其是可以从MyISAM表进行传输，这意味着不写入硬盘，而是写入系统缓存。

日志仍然会每秒刷新到硬盘上，因此您通常不会损失超过1-2秒的更新时间。设置为0会更快，但是安全性相对较差，即使MySQL挂起，它也可能会丢失事务数据。值2只能在整个操作系统关闭时丢失数据。 3，ls(1 )命令可用于列出文件的atime，ctime和mtime。

atime读取或执行文件时，文件的访问时间会更改

写入文件，更改所有者，权限或链接设置时，ctime文件的创建时间随inode的内容而变化

当mtime文件写入文件时，其修改时间随文件内容而变化

ls-lc filename列出文件的ctime

ls-lu filename列出了文件的时间

ls-l filename列出了文件的mtime

stat文件名列出了atime，mtime，ctime

访问文件后不一定修改atime

因为:在使用ext3文件系统时，如果在挂载期间使用了noatime参数，则不会更新atime信息。

这三个时间戳都放置在索引节点中。如果修改了mtime和atime，则索引节点将被更改。由于索引节点已更改，因此ctime也将相应更改。

在mount选项中使用noatime的原因是，我不想对文件系统进行太多更改并提高读取性能