高性能MySQL-笔记6-关于MySQL复制的东东

最新推荐文章于 2023-06-18 23:57:17 发布

小_杭

最新推荐文章于 2023-06-18 23:57:17 发布

阅读量364

点赞数

分类专栏：高性能MySQL 数据库 MySQL 文章标签：高性能MySQL MySQL复制

本文链接：https://blog.csdn.net/xiaohangblog/article/details/106259930

版权

数据库同时被 3 个专栏收录

26 篇文章 0 订阅

订阅专栏

MySQL

18 篇文章 0 订阅

订阅专栏

高性能MySQL

10 篇文章 0 订阅

订阅专栏

高性能MySQL-笔记6-关于MySQL复制的东东

文章目录

高性能MySQL-笔记6-关于MySQL复制的东东
@[toc]
简单说明
复制原理
具体的配置
主库配置
备库的配置
其他的Binlog配置

启动主备复制
业务情景下的主备复制
主备的拓扑结构
基本的原则
常见的各种拓扑结构
一主库多备库
双主复制
奇奇怪怪的结构

一些重要的问题[重点]
InnoDB加锁读引起的锁征用
关于半同步复制
关于多线程复制-组复制
其他的复制技术
最总要的工具

简单说明

MySQL的复制，主要的用途：数据分布，负载均衡，备份，高性能可用与故障切换。

关于复制：可以基于行复制和基于语句复制。【语句复制有操作语句限制的】

方式：都是通过主库上记录二进制日志，然后在备库重放日志的方式来完成的。【不保证同一时间主备数据一致】

复制原理

三个步骤：

主库上吧数据的更改记录到二进制日志（BinLog）中，；【关于BinLog等的配置，后续细说】
备库把主库的日志，复制到自己的中继日志（Relay Log）中.
备库读取中继日志的时间，重放到备库的数据上。【相当于重做一遍的意思】

注意一下，由于主库BinLog到备库RelayLog中，属于串行化的了。备库的重做也就只能单线程处理了╮(╯_╰)╭

然而，新的版本已经有了多线程复制的了这书呀的版本太旧了

具体的配置

配置均为调整my.cnf 配置文件！

查看状态：show master status;和show slave status ；

主库配置

log_bin=mysql-bin
server_id=10    # 这个为必填配置，唯一的服务ID

主库可以创建备份使用的独立账户：

GRANT REPLICATION SLAVE,RELOAD,SUPER ON *.* TO backup@’192.168.1.102’ IDENTIFIED BY ‘123456’;
FLUSH PRIVILEGES;  生效创建的用户
建立一个帐户backup，并且只能允许从192.168.1.102这个地址上来登陆，密码是123456。

备库的配置

log_bin=mysql-bin
server_id=2    # 这个为必填配置，唯一的服务ID
relay_log=/var/lib/mysql/mysql-relay-bin    # 非必配置
log_slave_updates=1  # 表示是否将重放事件记录到自身的二进制日志中
read_only=1 # 配置为只读

其他的Binlog配置

# 以下为配置介绍，非最优配置！！！  查看状态：show variables like 'log_%'; 
#设置日志格式 MIXED：混合模式；STATEMENT：逻辑模式【默认】；ROW：行模式【建议使用】；
binlog_format = mixed
#设置日志路径，注意路经需要mysql用户有权限写
log-bin = /data/mysql/logs/mysql-bin.log
#设置binlog清理时间
expire_logs_days = 7
#binlog每个日志文件大小
max_binlog_size = 100m
#binlog缓存大小
binlog_cache_size = 4m
#最大binlog缓存大小
max_binlog_cache_size = 512m

启动主备复制

mysql> CHANGE MASTER TO MASTER_HOST='mastrt服务器地址',
    -> MASTER_USER='master服务器用户，使用刚才创建的backup',
    -> MASTER_PASSWORD='密码',
    -> MASTER_LOG_FILE='master的show master status的file，实际填写mysql-bin.000009',
	-> MASTER_LOG_POS=0;   master的show master status的Position

使用 SHOW SLAVE STATUS\G语句查看slave的设置是否正确

mysql> START SLAVE;

可以使用 SHOW PROCESSLIST 来查看主备库的线程。

至此，简单的主备复制就可了，主备都是新数据库的情况。应该就酱紫了 o(￣︶￣)o

业务情景下的主备复制

业务场景下，在进行创建备库的时候，主库不可能是已经新的数据库，而是已经有大量的数据的了。这个情况下再进行，备库的搭建，是为最常见项目场景的了。

需要的三个关键信息：

某一个时间点的主库的数据快照。
主库当前的二进制日志文件，以及获得数据快照时在该二进制日志文件中的偏移量。【使用 show master status 进行获取】
从快照时间到当前现在的二进制日志。

可行的方法：

使用冷备份：需要停机复制主库，不推荐。
使用mysqldump转储主库的数据并加载到备库。【仅支持InnoDB】
使用快照或备份进行创建。【推荐】
使用Percona Xtrabackup 工具进行热备份。推荐】

具体的方法，并不在同一章节，在之后的专门的备份恢复章节。

主备的拓扑结构

一些情况下，数据库的拓扑结构不仅仅只是两台的主备数据库，而是一主多备，双主，环形树形复制等。

基本的原则

一个MySQL备库实例只能有一个主库。【MySQL 不支持多主库的复制】
备库必须有唯一的服务器ID
一个主库可以有多个备库。
如果打开了备库的log_slave_updates选项，备库可以作为主库再传播数据到其他备库。

常见的各种拓扑结构

一主库多备库

主要用于少量写大量读的情景，远程备份防灾。

双主复制

双主复制中，双主动复制的情况，会出现很多的问题，因为两个库存在同时写入相同行数据的情况，会造成数据冲突等等。

而，一主动一被动的双主复制，设置被动主库为只读的情况。用于在故障的时候方便切换数据库。

奇奇怪怪的结构

作用的话：

作为数据归档
备库作为全文检索进行查询
作为只读备库，分流查询压力
作为数据分析使用
差不多就这些理由了 ╮(╯_╰)╭

一些重要的问题[重点]

这一些才是重要的东西，书里面研究的版本已经比较旧了【最多到5.5】。对于新的一些特性与优化，需要去查一下了。【目前使用的版本是5.7的，虽然官方有8的版本了。】

ε=(´ο｀*)))唉感觉越学，要学习的东西就变得更多了。╮(╯_╰)╭ 。。。

InnoDB加锁读引起的锁征用

正常InnoDB的读操作都是非阻塞的，但是在 insert。。。select。。。这个操作的时候会锁定源表上的所有行。

以避免操作在主备库上的不一致╮(╯_╰)╭ ？？加锁，使主库的语句串行化，以保证主备执行一致。

select 的表示InnoDB类型的情况，会对select的表的记录进行锁定。

可以使用游标循环插入避免此锁定问题

关于半同步复制

从MySQL5.5开始，MySQL以插件的形式支持半同步复制。【495】

异步复制（Asynchronous replication）【默认】
- MySQL默认的复制即是异步的，主库在执行完客户端提交的事务后会立即将结果返给给客户端，并不关心从库是否已经接收并处理，这样就会有一个问题，主如果crash掉了，此时主上已经提交的事务可能并没有传到从上，如果此时，强行将从提升为主，可能导致新主上的数据不完整。
全同步复制（Fully synchronous replication）
- 指当主库执行完一个事务，所有的从库都执行了该事务才返回给客户端。因为需要等待所有从库执行完该事务才能返回，所以全同步复制的性能必然会收到严重的影响。
半同步复制（Semisynchronous replication）
- 介于异步复制和全同步复制之间，主库在执行完客户端提交的事务后不是立刻返回给客户端，而是等待至少一个从库接收到并写到relay log中才返回给客户端。相对于异步复制，半同步复制提高了数据的安全性，同时它也造成了一定程度的延迟，这个延迟最少是一个TCP/IP往返的时间。所以，半同步复制最好在低延时的网络中使用。

关于半同步复制存在的数据丢失的潜在问题，MySQL 5.7引入了一种新的半同步方案：Loss-Less半同步复制。

MySQL 5.7.2引入了一个新的参数进行控制-rpl_semi_sync_master_wait_point

AFTER_SYNC：这个即新的半同步方案，Waiting Slave dump在Storage Commit之前。

AFTER_COMMIT：老的半同步方案

要想使用半同步复制，必须满足以下几个条件：

MySQL 5.5及以上版本
变量have_dynamic_loading为YES ：show variables like '%have_dynamic_loading%'
异步复制已经存在

然后使用半同步，是以组件的形式支持的。

组件名：rpl_semi_sync_master

查看方式：【默认是没有这个组件的】

mysql> show plugins;

mysql> SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME LIKE ‘%semi%’;

具体的操作，请在需要使用的时候查看官方组件的文档，或其他的教学文档。这里略过了。

可以查看的参考文章：
https://www.cnblogs.com/ivictor/p/5735580.html
https://www.actionsky.com/2486.html

官方半同步复制组件文档：
https://dev.mysql.com/doc/refman/5.7/en/replication-semisync-installation.html

关于多线程复制-组复制

支持的话，在MySQL5.6的版本之后就支持了，5.7.2 进行了优化，增加了参数slave_parallel_type；

对于多线程复制的一些说明：

MySQL5.5 及以前的复制：

一般主从复制有三个线程且都是单线程：
Binlog Dump（主） ‐‐> IO Thread（从） ‐‐> SQL Thread（从）。

而master 这边是通过并发线程提交，事务通过LSN 写入binlog；但是Slave 只有一个IO 线程和SQL 线程，是单线程，所以在业务大的情况下就很容易造成主从延时.

如果在MySQL 5.6 版本开启并行复制功能（slave_parallel_workers > 0），那么SQL 线程就变为了coordinator 线程，coordinator 线程主要负责以下两部分内容：

Coordinator+worker（多个）

问题在与这个时的并发是基于库的，但是通常情况用户止只有一个库，就无法进行并发了。

5.7.2版本之后的：slave_parallel_type，参数给处理优化：

slave‐parallel‐type，其可以配置的值有：

DATABASE：默认值，基于库的并行复制方式
LOGICAL_CLOCK：基于组提交的并行复制方式【需要的就是这个】

以上是大概的说明了。

关于多线程复制的具体点的配置操作：

这里只是整理了一些资料而已，没有实际操作过**。如需要进行配置，请认真查看官方说明。**

首先，主库上，好像不需要什么操作的样子。

然后，从库上的操作：【查看线程show processlist;】

停止同步状态：stop slave;
设置并发同步类型为逻辑时钟方式:
1. show variables like ‘slave_parallel_type’;
2. set global slave_parallel_type=‘logical_clock’;
设置复制线程的数量:
1. show variables like ‘slave_parallel_workers’;
2. set global slave_parallel_workers=4;
还需要调整的配置:
1. 设置 master_info_repository=TABLE 和 relay_log_info_repository=TABLE。
2. slave_preserve_commit_order=1
3. 具体要求查看官方文档：https://dev.mysql.com/doc/refman/5.7/en/group-replication-requirements.html
启动复制 :start slave;

参看文章：

https://www.jianshu.com/p/d97a5643d090
https://blog.51cto.com/11899934/1832201
mysql主从之多线程复制【有完整推荐的配置文件信息，很详细的】

官方配置：https://dev.mysql.com/doc/refman/5.7/en/replication-options-slave.html
官方要求文档：<https://dev.mysql.com/doc/refman/5.7/en/group-replication-requirements.html