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:
创建用户
为了安全起见,准备创建一个新用户用于从库连接主库。
创建从库
mysql 下面来配置从服务器,修改从服务器 my.cnf 文件增加如下配置:
配置完成后登录 mysql,启动从数据库读取进程
然后查看 slave 状态
注意显示结果中
则在主服务器(192.168.1.1)中输入命令:
得到结果
注意查看其中 file 和 position 是否和 show slave status 中的 master_log_file 和 master_log_pos 匹配。
如果不一致则在从数据库(192.168.1.2)中执行,以下语句,以重置设定读取的日志和位置
执行完毕后,再次查看
则表示启动成功。
测试一下
然后在主数据库服务器插入一条数据,如果从数据库也增加了,则证明配置成功。
延伸一下
MySQL 的 Replication 复制机制的案例里面,阿里巴巴的 Canal 主要用途是对 MySQL 数据库增量日志进行解析,提供增量数据的订阅和消费,简单说就是可以对 MySQL 的增量数据进行实时同步,支持同步到 MySQL、Elasticsearch、HBase 等数据存储中去。也是属于该原理机制。
评论