24、mysql复制相关

半同步复制

MySQL复制是一种基于日志的异步复制机制，其中，一个MySQL实例充当主服务器，将其更改记录在二进制日志中，并通过网络发送到一个或多个从服务器，从服务器从主服务器上复制日志，并应用它以在从服务器上重放主服务器上的更改。这个过程是异步的，因为主服务器将写操作记录到二进制日志中后，就会立即通知客户端进行提交，而不会等待从服务器应用操作。

MySQL还支持半同步复制。与异步复制不同，半同步复制在主服务器将更改记录到二进制日志之后，会等待至少一个从服务器将更改记录应用到其本地数据库中，然后才通知客户端进行提交。这样，主服务器和从服务器的数据可以更加一致，但是由于需要等待从服务器的响应，因此会带来一定的性能损失。

实现半同步复制

主库的mysqld配置文件添加

plugin-load-add = semisync_master 或者通过set global参数进行设置
rpl_semi_sync_master_enabled=ON
rpl_semi_sync_master_timeout=3000 #设置3s内无法同步，也将返回成功信息给客户端

从库mysqld配置文件添加

plugin_load_add = semisync_slave
rpl_semi_sync_slave_enabled=ON

#mariadb-10.3版以后
#主服务器配置:
[mysqld]
plugin_load_add = semisync_master
#从服务器配置:
[mysqld]
plugin_load_add = semisync_slave

复制过滤器

MySQL复制过滤器是指在复制过程中对被复制的数据进行过滤或转换的一种机制。通过配置复制过滤器，可以对指定的表或库进行过滤，以达到控制复制数据的目的。MySQL自带的复制过滤器有binlog-do-db和binlog-ignore-db，分别用于指定需要复制或忽略的库名。此外，MySQL还支持自定义复制过滤器，可以在MySQL复制过程中执行Lua脚本或插件进行过滤和转换。

vim /etc/my.cnf
binlog-do-db = #数据库白名单列表，不支持同时指定多个值，如果想实现多个数据库需多行
实现
binlog-ignore-db = #数据库黑名单列表

从服务器SQL_THREAD在relay log中的事件时，仅读取与特定数据库(特定表)相关的事件并应用于本地
此方法存在的问题：会造成网络及磁盘IO浪费
#从服务器上的复制过滤器相关变量
replicate_do_db=db1,db2,db3 #指定复制库的白名单，变量可以指定逗号分隔的多个值，选项不
支持多值,只能分别写多行实现
replicate_ignore_db= #指定复制库黑名单
replicate_do_table= #指定复制表的白名单
replicate_ignore_table= #指定复制表的黑名单
replicate_wild_do_table= foo%.bar% #支持通配符
replicate_wild_ignore_table

主从复制加密

MySQL主从复制中，有可能会出现数据在传输过程中被截获或者篡改的安全问题。因此，MySQL提供了多种加密传输的方式来保证数据传输的安全性。

其中比较常用的方式是使用SSL/TLS加密协议来保证数据传输的机密性和完整性。在MySQL 5.7.10及以上的版本中，MySQL官方提供了SSL/TLS加密传输的支持。可以通过以下几个步骤来开启主从复制的SSL/TLS加密传输：

1、在主库和从库上生成SSL/TLS证书和密钥。可以使用OpenSSL等工具来生成证书和密钥。

openssl genrsa 2048 > cakey.pem
openssl req -new -x509 -key cakey.pem --out cacert.pem -days 3650
openssl req -newkey rsa:2048 -nodes -keyout master.key >master.csr
openssl x509 -req -in master.csr -CA cacert.pem -CAkey cakey.pem --set_serial 01 > master.crt
openssl req -newkey rsa:2048 -nodes -keyout slave.key >slave.csr
openssl x509 -req -in slave.csr -CA cacert.pem -CAkey cakey.pem --set_serial 02 > slave.crt

2、在主库和从库的配置文件中，配置SSL/TLS参数，如ssl-ca、ssl-cert、ssl-key等参数。

[mysqld]
log-bin
server_id=1
ssl
ssl-ca=/etc/my.cnf.d/ssl/cacert.pem
ssl-cert=/etc/my.cnf.d/ssl/master.crt
ssl-key=/etc/my.cnf.d/ssl/master.key

3、在主库上创建一个复制账号，并为该账号授权复制权限，并将该账号的认证方式设置为SSL/TLS。

GRANT REPLICATION SLAVE ON *.* TO 'repluser'@'192.168.100.%' IDENTIFIED BY'123456' REQUIRE SSL;

4、在从库上启用SSL/TLS，并在从库上创建一个复制账号，并为该账号授权复制权限，并将该账号的认证方式设置为SSL/TLS。

5、在主库上启用SSL/TLS加密传输，可以通过设置参数master_ssl=1来开启SSL/TLS加密传输。

6、在从库上启用SSL/TLS加密传输，可以通过设置参数slave_ssl=1来开启SSL/TLS加密传输。

7、在主库上启用SSL/TLS加密验证，可以通过设置参数master_verify_ssl=1来开启SSL/TLS加密验证。

8、在从库上启用SSL/TLS加密验证，可以通过设置参数slave_verify_ssl=1来开启SSL/TLS加密验证。

通过以上步骤，就可以实现MySQL主从复制的SSL/TLS加密传输，保障数据传输的机密性和完整性。

GTID复制

GTID(全局事务标识符)复制是一种MySQL主从复制的方式，它使用唯一的全局事务标识符来标识复制过程中的事务，而不再依赖于二进制日志文件名和偏移量。GTID复制引入了许多优点，包括更容易地重建从服务器、避免重复数据以及方便的故障转移等。

在GTID复制中，主服务器为每个事务分配一个全局唯一的标识符，称为GTID，这个标识符由三部分组成：源ID、事务ID和区段ID。在从服务器上，GTID状态会被存储在一个专用的GTID状态表中，以跟踪复制进度。从服务器还会将自己已经处理的GTID反馈回主服务器，这样主服务器就能知道从服务器复制的进度，从而可以控制复制的流程。

在MySQL 5.6中，GTID复制是一个可选的复制模式，需要手动启用。在MySQL 5.7及更高版本中，GTID复制是默认的复制模式，并且不能禁用。

GTID复制可以通过以下步骤实现：

1. 确认主服务器和从服务器的MySQL版本是否支持GTID复制，并启用GTID选项。
2. 在主服务器上为每个连接设置唯一的服务器ID。
3. 在主服务器上创建一个可读的账户，以用于从服务器复制数据。
4. 在从服务器上使用CHANGE MASTER TO语句，将其配置为复制主服务器上的数据。
5. 启动从服务器的复制进程，并使用SHOW SLAVE STATUS命令检查复制进程的状态。

GTID复制的主要优点包括：

1. 可以简化复制拓扑结构，并且更容易管理。
2. 可以避免由于错误的二进制日志名称或偏移量导致的复制问题。
3. 可以避免重复数据，提高复制效率。
4. 可以支持故障转移，从而提高系统的可用性。

GTID服务器相关选项

gtid_mode #gtid模式
enforce_gtid_consistency #保证GTID安全的参数

实现GTID复制

1、配置主服务器的GTID模式

2、创建复制账户

3、从服务器配置GTID模式

4、从服务器配置连接主服务器，启动slave线程

错误：UUID一直导致问题发送

解决：vim /data/mysql/auto.cnf 更改UUID

复制监控和维护

清理日志

PURGE { BINARY | MASTER } LOGS { TO 'log_name' | BEFORE datetime_expr }
RESET MASTER TO # #mysql 不支持
RESET SLAVE [ALL]

复制监控

SHOW MASTER STATUS
SHOW BINARY LOGS
SHOW BINLOG EVENTS
SHOW SLAVE STATUS
SHOW PROCESSLIST

(4) 如何确定主从节点数据是否一致

percona-toolkit

(5) 数据不一致如何修复

删除从数据库，重新复制

复制问题和解决方案

1、数据损坏或丢失

Master：MHA + semisync replication
Slave： 重新复制

2、复制延迟

一从多主、多线程复制(对多个数据库复制)

常见问题：

造成主从不一致的原因

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

修复方法

1、重新建立从库
2、手动创建不一致的表
3、借助percona-toolkit工具复制检测不一致就修复数据不一致情况