转载

保证复制高可用的一些重要参数

保证复制高可用的一些重要参数保证复制高可用的一些重要参数
expire_logs_days ,binlog清理的时间。
从库上relay-log-recovery = 1和relay-log-info-repository = TABLE; 保证了主从数据的一致性,不论从机怎么出错都能保证,主从一致。

为什么呢?

首先说SQL线程,SQL线程apply应用二进制日志,并且将binlog应用到的位置记录到relay-info.log中。
保证复制高可用的一些重要参数
并且并不是relay log应用一次就刷盘写relay-log.info一次,而是一个参数指定,如下,意思是说回放events 10000次写一次盘。这个就是为什么从库crash了,出现1062错误。因为从库已经插入了数据,但是文件relay-log.info并没有记录文件,当重启后文件告诉数据库还要执行一次操作,就会出现这个主键重复插入的错误。所以这个参数设置为table的,就满足了一致性,避免了数据库和文件的不同步问题。
保证复制高可用的一些重要参数
IO线程:
和relay_log_info_repository不同的是,单单把master_info_repository设置成table是不能解决,备库crash了,从IO线程接收日志的一致性问题,因为IO线程接收日志写的文件是relay log文件,而数据库接收到主库的日志到哪里写的是master-info.log文件,这是两个不同的文件,比如当relay接收到了日志,为event2,但是此时master-info.log记录的是1,此时crash了,当重新启动从库时,master-info.log告诉数据库我才接收到1,又重新接收了一次2,这样就重复了,即便是master_info_repository设置成table一样不解决问题。但是报错时,show slave status。最终作用到的都是SQL线程报错。
保证复制高可用的一些重要参数
保证复制高可用的一些重要参数

最后一个非常重要的参数:
保证复制高可用的一些重要参数
把当前接收到的relay log清理掉。然后从SQL Thread应用到的位置,重新拉取relay log。但是要保证主库binlog要保留,有的公司主从延迟一个月... ... 。。。 。。。 ,,, ,,,


还有read-only的设置,5.7有个新的权限super_read_only参数,设置为on,大家都没有权限,dba也没有。
正文到此结束
Loading...