Mysql主从复制详解和实战
一、主从复制原理
1.1 基本介绍
MySQL 内建的复制功能是构建大型,高性能应用程序的基础。将 MySQL 的 数亿分布到到多个系统上去,这种分步的机制,是通过将 MySQL 的某一台主机的数据复制到其它主机( Slave )上,并重新执行一遍来实现的。复制过程中一个服务器充当主服务器,而一个或多个其它服务器充当从服务器。主服务器将更新写入本地二进制日志文件中,并维护文件的一个索引以跟踪日志循环。这些日志可以记录发送到从服务器的更新。当一个从服务器连接主服务器时,它通知主服务器从服务器在日志中读取的最后一次成功更新的位置,从服务器接收从那时起发生的任何更新,然后等待主服务器通知新的更新。
注意:当你配置主从复制后,所有对数据的更新必须在主服务器上进行。否则,你必须要小心,以避免用户对主服务器上的表进行的更新与对从服务器上的表所进行的更新之间的冲突。
1.2 Mysql支持的复制类型
基于语句的复制。在主服务器执行什么sql语句,在从服务器会重新自动执行一遍。否否则,你必须要小心,以避免用户对主服务器上的表进行的更新与对从服务器上的表所进行的更新之间的冲突。,配置:binlog_format = ‘STATEMENT’
基于行的复制。把改变的内容复制过去,而不是把命令在从服务器上执行一遍,从 MySQL 5.0开始支持,配置:binlog_format = ‘ROW’
混合类型的复制。默认采用基于语句的复制,一旦发现基于语句的无法精确的复制时,就会采用基于行的复制,配置:binlog_format = ‘MIXED’
1.3 主从复制可以解决的问题
主数据库出现问题,可以切换到从数据库(高可用性和容错性)
可以进行数据库层面的读写分离(负载均衡,减轻主节点压力)
从库可以作为备份数据库
1.4 主从复制常用实现形式
一主多从复制架构
应用场景:
在主库读取请求压力非常大的场景下,可以通过配置一主多从复制架构实现读写分离,把大量对实时性要求不是特别高的读请求通过负载均衡调度到多个从库上,降低主库的读取压力。在主库出现异常宕机的情况下,可以把一个从库切换为主库继续提供服务
注意事项:
当 Slave 增加到一定数量时,Slave 对 Master 的负载以及网络带宽都会成为一个严重的问题。
不同的 Slave 扮演不同的作用(例如使用不同的索引,或者不同的存储引擎)
用一个 Slave 作为备用 Master,只进行复制
用一个远程的 Slave,用于灾难恢复。
多级复制架构
应用场景:
一主多从的架构能够解决大部分读请求压力特别大的场景需求,但主库的I/O压力和网络压力会随着从库的增加而增长,而使用多级复制架构就可以解决一主多从场景下,主库额外的I/O和网络压力。 但要注意的是,多级复制场景下主库的数据是经历两次才到达读取的从库,期间的延时比一主多从复制场景下只经历一次复制的要大
注意事项:
可能存在延时较长的风险
这种方案可以与第三方软件结合使用,例如Slave+LVS+Keepalived 实现高可用。
双主复制架构
应用场景:
双主/Dual Master架构适用于写压力比较大的场景,或者DBA做维护需要主从切换的场景,通过双主/Dual master架构避免了重复搭建从库的麻烦
注意事项:
最大问题就是更新冲突。
可以采用MySQL Cluster,以及将Cluster和Replication结合起来,可以建立强大的高性能的数据库平台
1.5 主从复制工作原理
MySQL之间数据复制的基础是二进制日志文件(binary log file)。一台MySQL数据库一旦启用二进制日志后,其作为master,它对数据库中的所有操作都会以“事件”的方式记录在二进制日志(bin log)文件中,其他数据库作为slave通过一个I/O线程与主服务器bin log dump保持通信,并监控master的二进制日志文件的变化,如果发现master二进制日志文件发生变化,则会把变化的数据复制到自己的中继日志中,然后slave的SQL线程会读取中继日志,并按顺序将该日志中的sql事件重新执行一遍,从而保证数据与主服务器一致
大致可以简单分为以下三步:
第一步:master在每个事务更新数据完成之前,将该操作记录串行地写入到binlog文件中。
第二步:salve开启一个I/O Thread,该线程在master打开一个普通连接,主要工作是binlog dump process。如果读取的进度已经跟上了master,就进入睡眠状态并等待master产生新的事件。I/O线程最终的目的是将这些事件写入到中继日志中。
第三步:SQL Thread会读取中继日志,并顺序执行该日志中的SQL事件,从而与主数据库中的数据保持一致。
细节说明:
Master 记录二进制的日志。在每个事务更新数据之前,Master 在二进制日志记录这些改变。 MySQL 将事务日志的写入二进制日志,及时事务中的语句都市交叉执行的。在事件写入二进制日志完成后,Master 通知存储引擎提交事务。
Slave 将 Master 的 Binary log 拷贝到它自己的中继日志。首先 Slave 开始一个工作线程–I/O线程。I/O 线程在 Master 上打开一个连接,然后开始从二进制日志中读取事件,如果已经连上 Master,它会并等待master产生新的事件。I/O线程就这些事件写入中继日志。
SQL Slave Thread ( SQL从线程)处理该过程的最后一步。SQL纯种从中继日志读取事件,并重放其中的事件而更新 Slave 的数据。使其它与 Master 中的数据保持一致。只要该线程与 I/O 线程保持一致,中继日志通常会位于 OS 的缓存中,所以中继日志的开销很小。
此处,在 Master 中也有一个工作线程,和其他 MySQL 的连接一样,Slave 在 Master 中打开一个连接也会使得 Master 开始一个线程。复制过程有一个很重要的限制—复制在 Slave 上是串行化的,也就是说 Master 上的并行更新操作不能在 Slave 上并行操作。
二、mysql主从配置实战
2.1 配置简易实现步骤
主服务器:
- 开启二进制日志 功能
- 配置唯一的server-id
- 获得master二进制日志文件名及位置
- 创建一个用于slave和master通信的用户账号
从服务器:
- 配置唯一的server-id
- 使用master分配的用户账号读取master二进制日志
- 启用slave服务
2.2 配置注意事项
每个 Slave 只能有一个 Master;
每个 Slave 只能有一个唯一的服务器ID;
每个 Master 可以有很多 Slave;
如果你设置了 log_slave_updates,Slave 可以是其他 Slave 的 Master,从而扩散 Master 的更新
MySQL 不支持多主服务器复制—即一个 Slave 可以有多个 Master,但是,通过一些简单的组合,我们却可以建立灵活而强大的复制体系结构。
2.3 主从环境介绍
数据库角色 | IP | 应用和系统 | 有无数据 |
Master数据库 | 192.168.2.221 | Centos7.3+mariadb5.5.56 | 有 |
Slave数据库 | 192.168.2.222 | Centos7.3+mariadb5.5.56 | 无 |
我这里mariadb使用yum直接安装了
主服务器操作:
①使用yum安装mariadb-server软件包,关闭防火墙和selinux
[root@master /]# systemctl stop pfirewalld [root@master /]# setenforce 0 [root@master /]# yum install -y mariadb-server
②修改mariadb配置文件,开启二进制日志功能,配置一个server-id并启动mariadb服务
[root@master /]# vim /etc/my.cnf -----------------------------修改添加以下内容------------------------- [mysqld] .....省略 log-bin=bin-log ##开启二进制日志功能 server-id=11 ##设置server-id所有主从服务器要唯一 innodb-file-per-table=ON skip-name-resolve=ON [root@master /]# systemctl restart mariadb
③创建slave通信用户,创建ceshi数据库并将mysql库的数据备份后导入到ceshi数据库
[root@master /]# mysql MariaDB [(none)]> grant replication slave on *.* to 'repl'@'192.168.2.222' identified by 'replication'; Query OK, 0 rows affected (0.00 sec) MariaDB [(none)]> flush privileges; Query OK, 0 rows affected (0.00 sec) MariaDB [(none)]> create database ceshi; Query OK, 1 row affected (0.00 sec) [root@master /]# mysqldump -uroot -p mysql > /mysql.sql [root@master /]# cat /mysql.sql | mysql -uroot -p ceshi
④登录myslq数据库,查看master的binlog日志文件名和pos-id
[root@master /]# mysql MariaDB [ceshi]> show master status; +----------------+----------+--------------+------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | +----------------+----------+--------------+------------------+ | bin-log.000003 | 514412 | | | +----------------+----------+--------------+------------------+ 1 row in set (0.00 sec)
从服务器操作:
①使用yum安装mariadb-server软件包,关闭防火墙和selinux
[root@slave /]# systemctl stop pfirewalld [root@slave /]# setenforce 0 [root@slave /]# yum install -y mariadb-server
②修改mariadb配置文件,开启中继日志功能,配置一个server-id并启动mariadb服务
[root@slave /]# vim /etc/my.cnf -----------------------------修改添加以下内容------------------------- [mysqld] .....省略 relay-log=relay-log ##开启中继日志功能 server-id=22 ##设置slave的serverid innodb-file-per-table=ON skip-name-resolve=ON [root@slave /]# systemctl restart mariadb
- 详解MySQL主从复制实战 - 基于GTID的复制
- 详解MySQL主从复制实战 - 基于GTID的复制
- 详解MySQL主从复制实战 - 基于日志点的复制
- mysql之主从复制详解
- MySQL 5.5 主从复制异步、半同步以及注意事项详解
- MySQL 系列教程(四)【秒杀七年经验 LowB工程师】 主从复制、备份恢复方案生产环境实战
- MySQL数据的主从复制、半同步复制和主主复制详解
- 详解如何利用docker快速构建MySQL主从复制环境
- [Mysql] 主从复制环境搭建步骤详解
- MySQL系列之E-2------MySQL主从复制实战
- mysql主从复制实战
- MySQL 系列(四)主从复制、备份恢复方案生产环境实战
- MySQL数据的主从复制、半同步复制和主主复制详解
- 图文详解mysql 主从复制原理
- mysql 主从、主主复制原理详解
- MySQL 主从复制详解(详细)
- 实战mysql集群搭建(二)-- 实现mysql数据库主从复制
- MySQL主从复制实战 - 基于GTID的复制
- mysql 主从复制(一)之实战篇(超简单)
- MariaDB/Mysql之主从架构的复制原理及主从/双主配置详解(一)