MySQL主从复制解决了什么问题？出现同步延迟如何解决？

2401_85354545

于 2024-07-24 23:13:58 发布

阅读量714

点赞数 7

文章标签： mysql 数据库

本文链接：https://blog.csdn.net/2401_85354545/article/details/140675564

版权

传输效率高，减少延迟。
在从库更新不存在的记录时，语句赋值不会失败。而行复制会导致失败，从而更早发现主从之间的不一致。
设表里有一百万条数据，一条sql更新了所有表，基于语句的复制仅需要发送一条sql，而基于行的复制需要发送一百万条更新记录
行复制：
不需要执行查询计划。
不知道执行的到底是什么语句。
例如一条更新用户总积分的语句，需要统计用户的所有积分再写入用户表。如果是基于语句复制的话，从库需要再一次统计用户的积分，而基于行复制就直接更新记录，无需再统计用户积分。

# 如果在双主复制结构中没有设置ID的话就会导致循环同步问题

server_id=1

# 即日志中记录的是语句还是行更新或者是混合

binlog_format=mixed

# 在进行n次事务提交以后，Mysql将执行一次fsync的磁盘同步指令。将缓冲区数据刷新到磁盘。

# 为0的话由Mysql自己控制频率。

sync_binlog=n

# 为0的话，log buffer将每秒一次地写入log file中并且刷新到磁盘。

mysqld进程崩溃会丢失一秒内的所有事务。

# 为1的话，每次事务log buffer会写入log file并刷新到磁盘。（较为安全）

# 在崩溃的时候,仅会丢失一个事务。

# 为2的话，每次事务log buffer会写入log file，但一秒一次刷新到磁盘

innodb_flush_logs_at_trx_commit=0

# 阻止从库崩溃后自动启动复制，给一些时间来修复可能的问题，

# 崩溃后再自动复制可能会导致更多的问题。并且本身就是不一致的

skip_slave_start=1

# 是否将从库同步的事件也记录到从库自身的bin-log中

# 允许备库将重放的事件也记录到自身的二进制日志中去，可以将备库当做另外一台主库的从库

log_slave_update

# 日志过期删除时间，延迟严重的话会导致日志文件占用磁盘

expire_logs_days=7

innodb_flush_logs_at_trx_commit的三个参数很容易弄混。以下是详细的解析：

mysql先将日志写到log buffer缓冲区当中，再将log buffer缓冲区的数据写到log file日志文件中，此时写入的是内存中的log file，最终仍需操作系统将内存中的数据刷写到磁盘上。

参数0：mysql每秒都会将log buffer的数据写入到log file中并且刷新到磁盘。意味着mysql崩溃的时候将会丢失一秒内的所有事务。
参数1：每次事务提交都会将log buffer写入到log file并刷新到磁盘。意味着在mysql崩溃的时候,仅会丢失一个事务。
参数2：每次事务提交都会将log buffer写入到log file但不同时写入到磁盘，由mysql自行控制每秒将log file刷写到磁盘上，当mysql崩溃的时候操作系统没崩溃的时候，log_file中仅会丢失一个事务，操作系统仍会将log file刷写到磁盘，而如果操作系统也崩溃或断电的话，则会丢失一秒内的事务。

推荐使用：innodb_flush_logs_at_trx_commit=2以及sync_binlog=500性能会较快。innodb_flush_logs_at_trx_commit以及sync_binlog都为1的话，较为安全。