首页 Mysql教程Mysql主从复制

Mysql备份恢复

Mysql高可用

运维派是国内成立最早的IT运维技术社区,欢迎关注公众号:yunweipai

MySQL主从复制

6.1.1 主从复制架构和原理
6.1.1.1 服务性能扩展方式
  • Scale Up,向上扩展,垂直扩展
  • Scale Out,向外扩展,横向扩展
6.1.1.2 MySQL的扩展
  • 读写分离
  • 复制:每个节点都有相同的数据集,向外扩展,基于二进制日志的单向复制
6.1.1.3 复制的功用
  • 数据分布
  • 负载均衡读
  • 备份
  • 高可用和故障切换
  • MySQL升级测试
6.1.1.4 复制架构

一主一从复制架构

Mysql主从复制插图

一主多从复制架构

Mysql主从复制插图(1)

6.1.1.5 主从复制原理

Mysql主从复制插图(2)

主从复制相关线程

主节点: dump Thread:为每个Slave的I/O Thread启动一个dump线程,用于向其发送binary log events 从节点: I/O Thread:向Master请求二进制日志事件,并保存于中继日志中 SQL Thread:从中继日志中读取日志事件,在本地完成重放

跟复制功能相关的文件:

  • master.info:用于保存slave连接至master时的相关信息,例如账号、密码、服务器地址等
  • relay-log.info:保存在当前slave节点上已经复制的当前二进制日志和本地relay log日志的对应关系
6.1.1.6 主从复制特点
  • 异步复制
  • 主从数据不一致比较常见
6.1.1.7 各种复制架构

Mysql主从复制插图(3)

  • 一Master/一Slave
  • 一主多从
  • 从服务器还可以再有从服务器
  • Master/Master
  • 一从多主:适用于多个不同数据库
  • 环状复制

复制需要考虑二进制日志事件记录格式

  • STATEMENT(5.0之前)
  • ROW(5.1之后,推荐)
  • MIXED
6.1.2 实现主从复制配置

参考官网 https://mariadb.com/kb/en/library/setting-up-replication/ https://dev.mysql.com/doc/refman/5.5/en/replication-configuration.html

主节点配置: (1) 启用二进制日志

(2) 为当前节点设置一个全局惟一的ID号

说明:

server-id的取值范围

1 to 4294967295 (>= MariaDB 10.2.2),默认值为1

0 to 4294967295 (<= MariaDB 10.2.1),默认值为0,如果从节点为0,所有master都将拒绝此slave的连接

(3) 创建有复制权限的用户账号

从节点配置: (1) 启动中继日志

(2) 使用有复制权限的用户账号连接至主服务器,并启动复制线程

范例:新建主从复制

主服务器非新建时

如果主节点已经运行了一段时间,且有大量数据时,如何配置并启动slave节点

  • 通过备份恢复数据至从服务器
  • 复制起始位置为备份时,二进制日志文件及其POS

范例:主服务器运行一段时间后,新增从节点服务器

6.1.3 主从复制相关
  1. 限制从服务器为只读

注意:以下命令会阻止所有用户, 包括主服务器复制的更新

  1. 在从节点清除信息

    注意:以下都需要先 STOP SLAVE

  1. 复制错误解决方法

  2. START SLAVE 语句,指定执到特定的点

范例:复制冲突的解决

  1. 保证主从复制的事务安全 参看https://mariadb.com/kb/en/library/server-system-variables/ 在master节点启用参数:

    在slave节点启用服务器选项:

    在slave节点启用参数:

范例:当master服务器宕机,提升一个slave成为新的master

6.1.4 实现级联复制

需要在中间的从服务器启用以下配置 ,实现中间slave节点能将master的二进制日志在本机进行数据库更新,并且也同时更新本机的二进制,从而实现级联复制

案例:三台主机实现级联复制

6.1.5 主主复制

主主复制:两个节点,都可以更新数据,并且互为主从 容易产生的问题:数据不一致;因此慎用 考虑要点:自动增长id

配置一个节点使用奇数id

另一个节点使用偶数id

主主复制的配置步骤: (1) 各节点使用一个惟一server_id (2) 都启动binary log和relay log (3) 创建拥有复制权限的用户账号 (4) 定义自动增长id字段的数值范围各为奇偶 (5) 均把对方指定为主节点,并启动复制线程

范例:实现两个节点的主主复制模型

6.1.6 半同步复制

默认情况下,MySQL的复制功能是异步的,异步复制可以提供最佳的性能,主库把binlog日志发送给从库即结束,并不验证从库是否接收完毕。这意味着当主服务器或从服务器端发生故障时,有可能从服务器没有接收到主服务器发送过来的binlog日志,这就会造成主服务器和从服务器的数据不一致,甚至在恢复时造成数据的丢失

Mysql主从复制插图(4)

半同步复制实现:

官方文档: https://mariadb.com/kb/en/library/semisynchronous-replication/

范例:CentOS 7 实现半同步复制

范例:CentOS 8 在Mariadb-10.3.11上实现 实现半同步复制

6.1.7 复制过滤器

让从节点仅复制指定的数据库,或指定数据库的指定表 复制过滤器两种实现方式: (1) 服务器选项:主服务器仅向二进制日志中记录与特定数据库相关的事件

此方法存在的问题:基于二进制还原将无法实现;不建议使用

注意:此项和binlog_format相关 参看:https://mariadb.com/kb/en/library/mysqld-options/#-binlog-ignore-db

注意:

(2) 从服务器SQL_THREAD在relay log中的事件时,仅读取与特定数据库(特定表)相关的事件并应用于本地 此方法存在的问题:会造成网络及磁盘IO浪费

从服务器上的复制过滤器相关变量

注意:跨库的更新将无法同步

6.1.8 主从复制加密

Mysql主从复制插图(5)

Mysql主从复制插图(6)

基于SSL复制:在默认的主从复制过程或远程连接到MySQL/MariaDB所有的链接通信中的数据都是明文的,外网里访问数据或则复制,存在安全隐患。通过SSL/TLS加密的方式进行复制的方法,来进一步提高数据的安全性 官网文档:https://mariadb.com/kb/en/library/replication-with-secure-connections/

实现MySQL复制加密

  1. 生成 CA 及 master 和 slave 的证书

  1. 主服务器开启 SSL,配置证书和私钥路径

  1. 创建一个要求必须使用 SSL 连接的复制账号

  1. 从服务器slave上使用CHANGER MASTER TO 命令时指明ssl相关选项

6.1.9 GTID复制

GTID复制:(Global Transaction ID 全局事务标识符) MySQL 5.6 版本开始支持,GTID复制不像传统的复制方式(异步复制、半同步复制)需要找到binlog文件名和POS点,只需知道master的IP、端口、账号、密码即可。开启GTID后,执行change master to master_auto_postion=1即可,它会自动寻找到相应的位置开始同步

GTID 架构

Mysql主从复制插图(7)

GTID = server_uuid:transaction_id,在一组复制中,全局唯一 server_uuid 来源于 /var/lib/mysql/auto.cnf

GTID服务器相关选项

GTID配置范例

  1. 主服务器

  1. 从服务器

6.1.10 复制的监控和维护

(1) 清理日志

(2) 复制监控

(3) 从服务器是否落后于主服务

(4) 如何确定主从节点数据是否一致 percona-toolkit (5) 数据不一致如何修复 删除从数据库,重新复制

6.1.11 复制的问题和解决方案
6.1.11.1 数据损坏或丢失
  • Master:MHA + semisync replication
  • Slave: 重新复制
6.1.11.2 不惟一的server id

重新复制

6.1.11.3 复制延迟
  • 需要额外的监控工具的辅助
  • 一从多主:mariadb10 版后支持
  • 多线程复制:对多个数据库复制
6.1.11.4 MySQL主从数据不一致
  1. 造成主从不一致的原因

  • 主库binlog格式为Statement,同步到从库执行后可能造成主从不一致。
  • 主库执行更改前有执行set sql_log_bin=0,会使主库不记录binlog,从库也无法变更这部分数据。
  • 从节点未设置只读,误操作写入数据
  • 主库或从库意外宕机,宕机可能会造成binlog或者relaylog文件出现损坏,导致主从不一致
  • 主从实例版本不一致,特别是高版本是主,低版本为从的情况下,主数据库上面支持的功能,从数据库上面可能不支持该功能
  • MySQL自身bug导致
  1. 主从不一致修复方法

  • 将从库重新实现

虽然这也是一种解决方法,但是这个方案恢复时间比较慢,而且有时候从库也是承担一部分的查询操作的,不能贸然重建。

  • 使用percona-toolkit工具辅助

PT工具包中包含pt-table-checksum和pt-table-sync两个工具,主要用于检测主从是否一致以及修复数据不一致情况。这种方案优点是修复速度快,不需要停止主从辅助,缺点是需要知识积累,需要时间去学习,去测试,特别是在生产环境,还是要小心使用

关于使用方法,可以参考下面链接:https://www.cnblogs.com/feiren/p/7777218.html

  • 手动重建不一致的表

在从库发现某几张表与主库数据不一致,而这几张表数据量也比较大,手工比对数据不现实,并且重做整个库也比较慢,这个时候可以只重做这几张表来修复主从不一致

这种方案缺点是在执行导入期间需要暂时停止从库复制,不过也是可以接受的

范例:A,B,C这三张表主从数据不一致

  1. 如何避免主从不一致

  • 主库binlog采用ROW格式
  • 主从实例数据库版本保持一致
  • 主库做好账号权限把控,不可以执行set sql_log_bin=0
  • 从库开启只读,不允许人为写入
  • 定期进行主从一致性检验

本文链接:http://www.yunweipai.com/34252.html

Mysql备份恢复

Mysql高可用

网友评论comments

发表评论

电子邮件地址不会被公开。 必填项已用*标注

暂无评论

Copyright © 2012-2020 YUNWEIPAI.COM - 运维派
扫二维码
扫二维码
返回顶部