MySQL8集群搭建

主从集群

基于binlog

优点:

1. 成熟稳定：Binlog复制是MySQL早期版本中引入的，经过长时间的使用和测试，非常成熟和稳定。
2. 灵活性：管理员可以选择复制特定的数据库或表，提供更细粒度的复制控制。
3. 简单的故障转移和恢复：在故障转移和数据恢复方面，通过手动指定binlog位置可以轻松进行。

缺点:

1. 复制延迟问题：在高负载情况下，从服务器可能会与主服务器出现显著的延迟。
2. 故障恢复复杂：在出现问题时，需要人工介入来查找正确的binlog位置，特别是在复杂的复制拓扑结构中。
3. 不保证数据一致性：在复杂的主从设置中，保证所有从库与主库完全同步需要额外的工作。

1.编辑主服务器my.cnf

#默认开启了binlog，添加如下配置
[mysqld]
#设置主服务器ID
server-id=1
binlog_format=row
max-binlog-cache_size = 64M       #binlog 最大能够使用cache的内存大小
max-binlog-size = 1G              #binlog 日志每达到设定大小后，会使用新的 binlog 日志
expire_logs_days = 15             #只保留最近15天的日志
innodb_flush_log_at_trx_commit = 2 #和 sync_binlog 控制MySQL磁盘写入策略以及数据安全性
sync-binlog = 500 
#重启mysql
systemctl restart mysqld

2.主服务器创建用户

create user 'sync'@'%' identified by 'Xxy#2023';
grant replication slave on *.* to 'sync'@'%';

3.编辑从服务器my.cnf

[mysqld]
#设置从服务器ID
server-id=2
binlog_format=row
max-binlog-cache_size = 64M       #binlog 最大能够使用cache的内存大小
max-binlog-size = 1G              #binlog 日志每达到设定大小后，会使用新的 binlog 日志
expire_logs_days = 15             #只保留最近15天的日志
innodb_flush_log_at_trx_commit = 2 #和 sync_binlog 控制MySQL磁盘写入策略以及数据安全性
sync-binlog = 500 
#重启mysql
systemctl restart mysqld

4.从服务器连接到主服务器

change master to master_host='172.16.22.160', master_user='sync', master_password='Xxy#2023', master_log_file='binlog.000001', master_log_pos=2126;
start slave;

主服务器查看从服务器信息

show slave hosts;

源库存在数据

#导出源库数据导入到备库
# source-data = 2注释change master内容，1不注释
mysqldump --set-gtid-purged=on --triggers --routines --events --all-databases --master-data=2>all.sql

修改个别参数

#修改密码，可携带对应参数进行修改
CHANGE MASTER TO MASTER_PASSWORD='newpass';

基于GTID

GTID：全局事务标识符 优点:

1. 事务一致性：GTID为每个事务提供了唯一标识，确保了事务的一致性，每个事务只在从库上执行一次。
2. 自动化故障恢复：GTID简化了主从切换和故障恢复的过程，从库可以自动找到正确的位置继续复制，而不需要手动干预。
3. 简化复制拓扑管理：GTID使得管理复杂的复制拓扑（如多源复制）变得更加容易，因为每个事务都有一个全局唯一的标识符。

缺点:

1. 版本限制：GTID从MySQL 5.6开始引入，对于旧版本的MySQL，不支持GTID。
2. 更高的资源消耗：GTID复制可能会导致更高的资源消耗（如内存），因为它需要存储和管理所有的GTID状态。
3. 初始配置复杂：GTID复制的初始配置比传统的binlog复制更复杂，尤其是在现有的复制环境中引入GTID时。

主从开启GTID

从服务器修改server_id=2

#编辑my.cnf添加
server_id=1
gtid_mode = on
enforce_gtid_consistency = 1
log_slave_updates = 1
binlog_format=row
#重启mysql

从节点连接主节点

change master to master_host='172.16.22.160',master_user='sync',master_password='Xxy#2023',master_port=3306,master_auto_position=1;
start slave;

主节点上状态查看

show slave hosts;
show processlist;

从节点查看状态

show slave status\G;

维护操作

...

主主集群

部署Master-Master Replication（双主复制）涉及对两台MySQL服务器进行配置，以便它们可以互相复制对方的数据。以下是一个基本步骤指南，以帮助你开始：

安装 keepalived

在Master-Master Replication方案中加入keepalived可以进一步提高数据库的高可用性。keepalived主要利用虚拟IP（VIP）和心跳检测来实现自动故障转移，它可以监控MySQL服务的状态，一旦检测到主节点故障，就会将VIP从故障节点切换到健康节点上，实现高可用。

以下是在Master-Master Replication方案中增加keepalived实现高可用的基本步骤：

1. 安装 keepalived

在两台MySQL服务器上安装keepalived。你可以使用包管理器来安装，例如，在基于Debian的系统上，可以使用：

yum -y install keepalived

2. 配置 keepalived

在两台服务器上配置keepalived。配置文件通常位于/etc/keepalived/keepalived.conf。

服务器1（假设为Master1）配置示例:

vrrp_script chk_mysql {
    script "/path/to/check_mysql.sh"    # 指向你的健康检查脚本
    interval 10                          # 检查脚本执行的间隔（秒）
    weight 2                            # 如果脚本检查成功，增加的优先级
}
vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 101
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        192.168.1.10
    }
    track_script {
        chk_mysql
    }
}

服务器2（假设为Master2）配置示例:

vrrp_script chk_mysql {
    script "/path/to/check_mysql.sh"    # 指向你的健康检查脚本
    interval 10                          # 检查脚本执行的间隔（秒）
    weight 2                            # 如果脚本检查成功，增加的优先级
}
vrrp_instance VI_1 {
    state BACKUP
    interface eth0
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        192.168.1.10
    }
    track_script {
        chk_mysql
    }
}

新建MySQL服务检查脚本

#!/bin/bash

# 检查MySQL服务状态
# 如果服务运行正常，则返回0；如果服务运行异常，则返回非0值。

if systemctl is-active --quiet mysql
then
    exit 0
else
    exit 1
fi

chmod +x /path/to/check_mysql.sh 在这个配置中，virtual_router_id 必须在两台服务器上相同，而priority 则决定了哪台服务器作为默认的主服务器。virtual_ipaddress 是两台服务器共享的虚拟IP。

3. 启动keepalived服务

在两台服务器上启动keepalived服务。

sudo systemctl start keepalived
sudo systemctl enable keepalived

4. 测试故障转移

一旦keepalived配置并启动，它将开始监控MySQL服务的状态。你可以通过关闭当前的主服务器上的MySQL服务或接口来测试故障转移。

sudo systemctl stop mysql

或者

sudo ifdown eth0

然后检查VIP是否已经成功切换到另一台服务器上。

注意事项

• 确保在生产环境中使用之前，在测试环境中彻底测试keepalived配置。
• 对于复杂的网络配置，可能需要调整keepalived的配置，比如使用unicast替代multicast，确保心跳包能在服务器间正确传递。
• 确保你的网络安全设置允许keepalived的通信（例如，VRRP协议通常使用IP协议号112）。

通过结合keepalived和MySQL的Master-Master Replication，你可以建立一个高可用的数据库环境，以确保数据的稳定性和可靠性。

基于 binlog

1. 准备工作

确保两台服务器的MySQL版本相同，网络之间可以相互通信，并且具有固定的公网或内网IP地址。此外，确保MySQL的二进制日志（Binary Log）功能已启用，因为它对复制是必需的。

2. 配置MySQL服务器

对两台服务器都进行以下配置：

服务器1（假设IP为192.168.1.1）:

1. 编辑MySQL配置文件。
2. 在[mysqld]部分中设置参数，参考上方基于binlog主从配置主服务器配置内容。
3. 重启MySQL服务。

服务器2（假设IP为192.168.1.2）:

1. 同样编辑MySQL配置文件。
2. 在[mysqld]部分设置参数，参考上方基于binlog主从配置从服务器配置内容内容。
3. 重启MySQL服务。

3. 创建复制用户

在两台服务器上分别创建一个用于复制的用户，并授权。

在服务器1上:

CREATE USER 'replicator'@'192.168.1.2' IDENTIFIED BY 'password';
GRANT REPLICATION SLAVE ON *.* TO 'replicator'@'192.168.1.2';
FLUSH PRIVILEGES;

在服务器2上:

CREATE USER 'replicator'@'192.168.1.1' IDENTIFIED BY 'password';
GRANT REPLICATION SLAVE ON *.* TO 'replicator'@'192.168.1.1';
FLUSH PRIVILEGES;

4. 设置Master-Master复制

在每台服务器上分别配置另一台服务器为其Master。

在服务器1上:

CHANGE MASTER TO
MASTER_HOST='192.168.1.2',
MASTER_USER='replicator',
MASTER_PASSWORD='password',
MASTER_LOG_FILE='mysql-bin.000001',
MASTER_LOG_POS=  107;
START SLAVE;

在服务器2上:

CHANGE MASTER TO
MASTER_HOST='192.168.1.1',
MASTER_USER='replicator',
MASTER_PASSWORD='password',
MASTER_LOG_FILE='mysql-bin.000001',
MASTER_LOG_POS=  107;
START SLAVE;

5. 验证配置

检查复制状态确保一切正常。

在两台服务器上运行：

SHOW SLAVE STATUS\G

查看Slave_IO_Running 和 Slave_SQL_Running 两个状态，它们都应该是“Yes”。

这些步骤提供了一个基础的Master-Master复制部署流程。在生产环境中，你还需要考虑数据的一致性、冲突解决、故障转移策略、监控和备份等问题。此外，强烈推荐在实际部署前在测试环境中进行彻底测试。

基于 GTID

使用GTID（全局事务标识符）进行MySQL主主复制可以使复制过程更加简单和可靠。GTID确保每个事务在复制集群中具有唯一标识，从而简化了故障恢复和复制管理。以下是切换到使用GTID的步骤：

1. 确保前提条件

• MySQL的版本至少是5.6，因为GTID是从这个版本开始引入的。
• 确保所有已经存在的数据在两台服务器上是同步的。

2. 配置MySQL服务器

对两台服务器都进行以下配置：

在服务器1上:

1. 编辑MySQL配置文件。
2. 在[mysqld]部分设置参数，参考上方基于GTID主从配置主服务器配置内容内容
3. 重启MySQL服务。

在服务器2上:

1. 同样编辑MySQL配置文件。
2. 在[mysqld]部分设置参数，参考上方基于GTID主从配置从服务器配置内容内容
3. 重启MySQL服务。

3. 创建复制用户

在两台服务器上分别创建一个用于复制的用户，并授权。确保在两台服务器上都执行以下操作。

在服务器1上:

CREATE USER 'replicator'@'%' IDENTIFIED BY 'password';
GRANT REPLICATION SLAVE ON *.* TO 'replicator'@'%';
FLUSH PRIVILEGES;

在服务器2上:

CREATE USER 'replicator'@'%' IDENTIFIED BY 'password';
GRANT REPLICATION SLAVE ON *.* TO 'replicator'@'%';
FLUSH PRIVILEGES;

4. 配置Master-Master复制

在每台服务器上分别配置另一台服务器为其Master。

在服务器1上:

CHANGE MASTER TO
MASTER_HOST='192.168.1.2',
MASTER_USER='replicator',
MASTER_PASSWORD='password',
MASTER_AUTO_POSITION = 1;
START SLAVE;

在服务器2上:

CHANGE MASTER TO
MASTER_HOST='192.168.1.1',
MASTER_USER='replicator',
MASTER_PASSWORD='password',
MASTER_AUTO_POSITION = 1;
START SLAVE;

5. 验证配置

检查复制状态确保一切正常。

在两台服务器上运行：

SHOW SLAVE STATUS\G

查看 Slave_IO_Running 和 Slave_SQL_Running 两个状态，它们都应该是“Yes”。 同时，Retrieved_Gtid_Set 和 Executed_Gtid_Set 应该显示GTID。 使用GTID进行复制提供了更好的一致性和自动故障恢复能力。在部署此方案之前，请确保彻底理解GTID的工作原理和配置要求，同时在测试环境中进行充分的测试。