Mysql高可用性架构由浅入深

Mysql的三种(二进制日志)

记录了所有对Mysql数据库的修改事件,包括了增删改查事件对表结构的修改事件

  • 基于段的格式 binlog_format=STATEMENT

  • 优点

    • 日志记录量相对教小,节约磁盘以及网络I/O只对一条记录修改或插入

    • row格式所产生的日志量校与段产生的日志量

  • 缺点

    • 必须记录上下文的信息,保证语句在从服务器上执行结果和在主服务器上相同

    • 对于特定的函数UUID(),user(),这样非确定性函数还是无法复制的,有可能造成复制中断导致无法使用主从同步

mysqlbinlog binlog日志名就可以查看相关日志信息
  • 基于行的日志格式 binlog_format=ROW(可以避免Mysql复制中出现的主从不一致的问题)

例子:同一SQL语句修改了10000条数据的情况下基于段的日志格式只会记录这个SQL语句,基于行的日志会有10000条记录分别记录每一行的数据修改

  • 优点
    • 让Mysql主从复制更加的安全
    • 对每一行的数据的修改比基于段的复制更高效

由于ROW模式中记录了每一行日志的更改,所以当日志传输到备用服务器上的时候,只需要应用对他的更改就行了,而不用从新去执行sql语句,这个让主从同步数据完全一致。无论是主数据库中使用了确定性函数还是非确定性函数,都可以实现完全的一致。这样就避免了主从数据库的不一致所造成的复制链路的中断或是对业务逻辑造成的影响。同时ROW记录的是每一行数据的更改,在从服务器上的效率大于对段的修改性能更加的好,降低主从同步的时间。
极端的条件下:误操作而修改了数据库中的数据,同时又没有备份可以去恢复时候,我们就可通过分析二进制日志,对日志记录中的数据修改操作做反向处理的方式来达到恢复数据的目的。

  • 缺点
    • 记录日志量比较大(binlog_row_image=[FULL|MINIMAL|NOBLOG])

以上选项的解释:
FULL -> 代表只要我们修改一个表中的所有数据我们就对表中的所有的数据进行记录,无论其他的有没有修改过。
MINIMAL -> 代表修改了表中某一列,只记录被修改的这一列
NOBLOG -> 代表没有对BLOG和TEXT列修改就不会记录值

  • 混合日志格式 binlog_format=MIXED
    • 特点:基于SQL语句由于系统决定在基于段和基于行日志格式中进行选择

    • 数据量的大小由于所执行的SQL语句决定

建议使用

  • MIXED or ROW 格式

二进制日志复制对Mysql造成的影响

Mysql复制工作方式

  • 基于日志方式的复制

  • 基于GTID的复制


什么是GTID?

GTID也就是全局事务ID,其中保证为一个在主上提交的事务在复制集群中可以生成一个意味的ID值

  • GITD=source_id:transaction_id

source_id执行主库的事务主要UUID,在数据库启动的时候自动生成的保存在aut.conf文件中,算法保证生成的UUID值都是不同的,而事务ID从一开始执行一个序列,表示在库中执行的是第几个事务,Mysql保持事务之间是1:1的映射关系

  • 部署方式
第一步在主服务器上建立复制账号
CREATE USER '用户名'@'ip段' identified by 'password';
CREATE REPLICATION SLAVE ON *.* TO '用户名'@'ip段';

第二步配置主数据库服务器
vim /etc/my.cnf
bin_log=/usr/local/mysql/log/mysql-bin  #指定日志的存放位置
server_id=100  #指定服务的ID号
gtid_mode=on  #开启GTID复制
enforce-gtid-consiste  #启动强制同步,保证事务安全
log-slave-updates=on  #5.7版本一下必须开启这个参数

第三步配置数据库从服务器
server_id=101
relay_log=地址
gtid_mode=on
enforce-gtid-consistency
log-slave-updates=on
read_only=on  #建议开启
master_info_repository=TABLE 
relay_log_info_repository=TABLE 

第四步初始化从服务器数据
mysqldump --master-date=2-single-transaction
xtarbackup --slave-info
【记录备份时候最后的事务的GTID值】
启动基于GTID的复制:
CHANGE MASTER TO MASTER_HOST='master_host_ip' MASTER_USER='用户名',MASTER_PASSWORD='密码',MASTER_AUTO_POSITION=1
  • 优点
    • 可以方便的进行故障转移

    • 从库不会丢失主库上的任何修改

  • 缺点

    • 故障处理比较复杂
    • 对执行的SQL有一定的限制
  • 选择使用复制模式要考虑的问题
    • 使用大于5.6后的Mysql版本

    • 复制架构及其主从切换的方式

    • 所使用的高可用管理组件

    • 对应使用的支持程度

Mysql复制拓扑

  • 一主多从

    • 配置简单

    • 可以用多个从库分担读负载

  • 用途

    • 为不同业务使用不同的从库

    • 将一台从库放到远程IDC,用作灾备恢复

主-主模式下的复制

  • 主-主复制的配置注意事项
    • 产生数据冲突而造成复制链路的中断

    • 耗费大量时间修复

    • 造成数据的丢失

  • 解决的方案

    • 两个主中所操作的表最好能够分开

    • 使用下面两个参数控制自增ID的生成

      • auto_incrment_increment=2
      • auto_incrment_offset=1|2

主-备模式下的复制

主备模式下的主-主复制的配置注意事项
只有一台服务器处于只读状态并且只作为热备使用在对外提供服务的主库出现故障或是计划性的维护时候才会进行切换,使得原来的备库成为主库出现故障或是计划性的维护时候才会进行切换,使得原来的备库成为主库,而原来的主库会成为新的备库并且处理制度或者是下线状态,等待维护完成后重新上线。

  • 确保两台服务器上的初始数据相同

  • 确保两台服务器上已经启动binlog并且有不同的server_id

  • 在两台服务器上启用log_slave_updates参数

  • 在初始的备库上启用read_only

级联复制

影响主从延迟的因素

  • 主库执行事务到二进制日志的时间
    • 控制主库的事务大小,分割大事务
  • 二进制日志传输的时间
    • 使用MIXED日志或设置set binlog_row_image=minimal;
  • 默认情况下从库只有一个SQL线程,主上并发的修改在从上变成了串行
    • 使用多线程复制5.6版本开始

    • 在Mysql5.7中可以按照逻辑时钟的方式来分配SQL线程

如何配置多线程复制
stop slave;
set gloab slave_parallel_type='logical_clock';  #设置逻辑时钟
set global slave_parallel_workers=4 #设置并发线程
start slave;
mysql> show processlist;    #查看当前mysql的运行线程

Mysql复制常见的问题处理

由于数据损坏或丢失所引起的主从复制错误

  • 主库或从库意外宕机引起的错误

当我们主库的sync_binlog没有设置成1的时候,主库发生意外宕机,有可能会没有将宕机前的几个数据刷新到磁盘存储,当主库重新启动后从库会重新连接到主库读取二进制日志事件,但是主库会告诉从库在主观的二进制日志中没有二进制编译量所代表的事件,因为宕机前没有刷新到日志中,所以主从同步会失败

  • 解决方案
    • 使用跳过二进制日志事件

    • 注入空事务的方式先恢复中断的复制链路

    • 再使用其他方式来对比主从服务器上的数据

  • 主库上的二进制日志损坏

  • 备库上的中继日志损坏

  • 在从库上进行数据修改造成的主从复制错误

  • 不唯一的server_id或server_uuid

    • server_uuid是记录在数据目录中的auto.cnf文件中

    • 造成多个从服务器使用一个server_uuid的问题(隐蔽错误)

  • max_allow_packet设置引起的主从复制错误

Mysql复制无法解决的问题

  • 不分担主数据库的写负载
    • 通过分库分表
  • 自动进行故障转移及其主从切换

  • 不提供读写分离

Mysql高可用性架构由浅入深》有4个想法

发表评论