MySQL- 技术专题 - 主从复制

前提概要

随着应用业务数据不断的增大，应用的响应速度不断下降，在检测过程中我们不难发现大多数的请求都是查询操作，此时，我们可以将数据库扩展成主从复制模式（COW），将读操作和写操作分离开来，多台数据库分摊请求，从而减少单台主库的访问压力，进而应用得到优化。MySQL 支持一台主库同时向多台从库进行复制。

同步方案

如果使用纯手动的方式来备份数据，不但繁琐，而且容易出现错误。因此需要一种自动方式来对数据库操作进行自动备份还原。对主从服务器数据库进行同步复制，可以在 MySQL 数据库实现 Cluster。

MySQLCluster 是由 MySQL 官方提供的集群部署方案，主要提供以下几种方案：

• （1）高可用性：主服务器故障后可以实现自动切换到后备服务器，尽管部分硬件和软件不可预知地会发生故障，但整个系统的服务必须保证每天 24 小时每星期 7 天可用，从而保证数据不丢失和系统不停机。

• （2）可伸缩性：可方便通过脚本增加 DB 服务器，当数据库服务的负载增长时，系统能被扩展来满足需求，且不降低服务质量。

• （3）负载均衡：支持手动将公司的数据请求自由切换或指定配置到其它服务器，相互之间可以负载均衡，显著提升数据库的性能，提高设备利用率。MySQLCluster 支持通过自动分片支持读写扩展，通过实时备份冗余数据来实现可用性最高的方案的有力保证。通过数据库实现 Cluster，不但提高了 MySQL 的安全性，而且还减轻了 DBA 大量的工作。

主从复制

同步操作通过 3 个线程实现，其基本步骤如下：

• 主服务器将数据的更新记录到二进制日志(binlog)中（记录被称作二进制日志事件）-- 主库线程(Dump thread)；

• 从库将主库的二进制日志复制到本地的中继日志（relay log）-- 从库 I/O 线程；

• 从库读取中继日志中的事件，将其重放（重新执行）到数据中 -- 从库 SQL 线程。

Master 库 Dump 线程

Master 主库在事务提交时，会把数据变更作为事件 Event 记录在二进制日志文件 Binlog 中。复制是指将主数据库的 DDL 和 DML 操作通过二进制日志推送传到从库服务器中。

Slave 库 Relay 线程

Slave 从库接收到了主库的推送二进制日志文件后，启动 Relay 线程，对这些二进制文件生成对应的中

继 RelayLog 日志

Slave 库 SQL 线程

SQL 线程执行启动后，会读取 RelayLog 中的二进制数据内容，进行重新执行（也叫重做或重放）, 从而使得从库和主库的数据保持同步。

复制优势

MySQL 复制的有点主要包含以下三个方面：

• 主库出现问题，可以快速切换到从库提供服务。

• 可以在从库上执行查询操作，从主库中更新，实现读写分离，降低主库的访问压力。

• 可以在从库中执行备份，以避免备份期间影响主库的服务。

环境搭建

创建主库

master 的配置文件（/XX/my.cnf）中，配置如下内容：

#mysql 服务ID,保证整个集群环境中唯一server-id=1#mysql binlog日志的存储路径和文件名log-bin=/var/lib/mysql/mysqlbinlog-bin-index=mysql-bin.indexbinlog_format=mixed#错误日志,默认已经开启#log-err#mysql的安装目录#basedir#mysql的临时目录#tmpdir#mysql的数据存放目录#datadir#是否只读,1 代表只读, 0 代表读写read-only=0#忽略的数据, 指不需要同步的数据库binlog-ignore-db=mysql#指定同步的数据库#binlog-do-db=db01sync-binlog=1character-set-server=utf8

执行完毕之后，需要重启 Mysql：

service mysql restart;重启主服务器

创建用户

为了安全起见，准备创建一个新用户用于从库连接主库。

# 创建用户create user 'username'@'%' identified by 'password';# 授权，只授予复制和客户端访问权限grant replication slave, replication client on *.* to 'username'@'%' identified by 'password';# 刷新，权限控制flush privileges;

创建从库

• mysql 下面来配置从服务器，修改从服务器 my.cnf 文件增加如下配置：

server-id=2这里注意不要和主服务器相同master-host=192.168.1.1主服务器IPmaster-user=rep前面配置数据库用户master-password=password用户密码master-port=3306同步端口master-connect-retry=0重连时间replicate-do-db=db需要同步的数据库replicate-igonre-db=mysql需要忽略的数据库

• 配置完成后登录 mysql，启动从数据库读取进程

slave start

• 然后查看 slave 状态

show_slave_status\G

• 注意显示结果中

Slave_IO_Running,Slave_SQL_Running，如果都为yes则表示启动成功，如果为no

• 则在主服务器(192.168.1.1)中输入命令:

show master status;

得到结果

注意查看其中 file 和 position 是否和 show slave status 中的 master_log_file 和 master_log_pos 匹配。

如果不一致则在从数据库(192.168.1.2)中执行，以下语句，以重置设定读取的日志和位置

slave stop；change master to master_log_file='log.000031',master_log_pos=XXXslave start;

执行完毕后，再次查看

show slave status;Slave_IO_Running=yes,Slave_SQL_Running=yes

则表示启动成功。

测试一下

然后在主数据库服务器插入一条数据，如果从数据库也增加了，则证明配置成功。

延伸一下

MySQL 的 Replication 复制机制的案例里面，阿里巴巴的 Canal 主要用途是对 MySQL 数据库增量日志进行解析，提供增量数据的订阅和消费，简单说就是可以对 MySQL 的增量数据进行实时同步，支持同步到 MySQL、Elasticsearch、HBase 等数据存储中去。也是属于该原理机制。