MySQL基于gtid同步,新增slave节点

环境说明:当前MySQL集群为一主一从, 新增加 Slave 节点,将架构变更为一主两从,集群已经运行了很长时间,主节点得binlog早就被purged,启动slave得时候会报错,1236、1062等

操作步骤:备份master数据,从节点reset master,导入数据

1.备份主节点数据:在进行任何操作之前,首先需要对主节点的数据进行备份,以确保数据的安全性。这可以通过使用mysqldump工具或其他备份方法来完成。

2.从节点重置:在新增的Slave节点上执行reset master命令,这将清除该节点上现有的复制信息,包括已经purged的binlog日志。这一步是必要的,因为旧的复制信息可能导致复制过程中的错误。

3.导入数据:将备份的数据导入到新增的Slave节点中。这一步骤确保Slave节点拥有主节点的完整数据副本。

master确认用户信息:

master> select user,host,plugin from mysql.user;

master> show grants for 'root'@'localhost';

备份master数据

mysqldump -uroot -p --all-databases --single-transaction --triggers --routines --events >full.sql

新增slave节点操作:

slave> stop slave;
slave> reset master;
slave> reset slave;
slave> source full.sql;

配置change master
slave> change master to master_host='主节点IP',master_port=3306,master_user='repl',master_password='密码',master_auto_position=1;

启动slave
slave> start slave;
slave> show slave status\G;

主从数据同步测试:

1.主节点随便创建一个数据库,查看从节点是否同步

master> create database test111;

从节点查看:

slave> show databases;

2.账号密码登录验证:

在从库节点上使用master的账号密码登录

使用原先slave节点root账号密码登录成功

slave> alter user root@'%' identified by '密码';

slave> flush privileges;

退出重新使用新密码登录OK

过程遇到得问题处理:

1.主库执行alter user后从库报错1396

master> alter user sys@'%' identified by '密码';

从节点查看主从同步情况:

slave> show slave status\G;

1396报错处理:

slave> select * from performance_schema.replication_applier_status_by_worker where LAST_ERROR_NUMBER=1396\G;
*************************** 1. row ***************************
         CHANNEL_NAME:
            WORKER_ID: 1
            THREAD_ID: NULL
        SERVICE_STATE: OFF
LAST_SEEN_TRANSACTION: f94464fc-3e89-11ef-bb05-fa163e40e770:10092821
    LAST_ERROR_NUMBER: 1396
   LAST_ERROR_MESSAGE: Worker 1 failed executing transaction 'f94464fc-3e89-11ef-bb05-fa163e40e770:10092821' at master log mysql-bin.000031, end_log_pos 358006489; Error 'Operation ALTER USER failed for 'sys'@'%'' on query. Default database: ''. Query: 'ALTER USER 'sys'@'%' IDENTIFIED WITH 'mysql_native_password' AS '*83B9BAAFABA1C2C8E47E266271D05FFB8F30CEF8''
 LAST_ERROR_TIMESTAMP: 2024-10-21 17:11:49
1 row in set (0.00 sec)

ERROR:
No query specified

slave> stop slave
slave> set @@session.gtid_next='f94464fc-3e89-11ef-bb05-fa163e40e770:10092821';
slave> begin;
Query OK, 0 rows affected (0.00 sec)
slave> commit;
Query OK, 0 rows affected (0.00 sec)
slave> set @@session.gtid_next=automatic;
Query OK, 0 rows affected (0.00 sec)
slave> start slave;
Query OK, 0 rows affected (0.22 sec)

重新查看slave同步状态恢复正常

slave> show slave status\G;

删除sys用户重新创建

slave> drop user sys@'%';

slave> create user 'sys'@'%' identified by '密码';

授权

slave重新登录提示成功

2. grant授权得时候1045错误(之前得root@localhost用户被删除了,重新创建了一个root@localhost用户并授权)

检查MySQL服务器上各个用户的权限设置

select user,host,Grant_priv,Super_priv from mysql.user;

Grant_priv列用于指示用户是否具有授权权限

update mysql.user set Grant_priv='Y' where User='root';

查看root@localhost用户权限

show grants for root@localhost;

授权root@localhost用户权限

grant all on *.* to 'root'@'localhost';

查询root@localhost用户的权限和配置

select * from mysql.user where user='root' and host='localhost'\G;

当前登录用户为'root'@'%',修改'root'@'%'用户密码再授权

alter user 'root'@'%' identified by '密码';

flush privileges;

退出重新登录'root'@'%'用户为root@localhost用户授权成功

### 基于 GTIDMySQL 高可用架构设计与实施方法 #### 1. 启动 GTID 模式 为了启用 GTID 模式,在启动 MySQL 实例时需添加 `gtid_mode=on` 和 `enforce_gtid_consistency=on` 参数[^1]。这些参数确保事务的唯一性和一致性。 #### 2. GTID 结构及其优势 GTID 是一种全局事务 ID,由服务器 ID 和事务 ID 组成[^2]。相比传统基于二进制日志位置的方式,GTID 提供了更简单的主从切换机制(failover),无需手动定位日志文件和偏移量。此外,它还简化了主从复制的配置过程,并增强了数据安全性,保证数据一致性和零丢失。 #### 3. 主从同步状态监测 在高可用环境中,主从同步可能会因多种原因而失败。可以通过执行命令 `show slave status \G` 来检查从库的状态。如果发现 `Slave_SQL_Running=no`,则表明同步已中断。可能的原因包括从库上的写操作引发冲突或者由于服务重启导致某些事务被回滚[^3]。 #### 4. 复制环境健康检查 通过 MasterHA 工具可以定期对整个复制环境进行健康检查。例如,运行以下命令可验证 MySQL 复制链路是否正常: ```bash [root@server6 masterha]# masterha_check_repl --conf=/etc/masterha/app1.cnf ``` 当返回消息显示 “MySQL Replication Health is OK.” 则说明当前复制环境处于良好状态[^4]。 #### 5. MMM 架构支持 对于更高层次的需求,可以考虑采用 MMM (Multi-Master Replication Manager for MySQL) 架构来管理多主复制集群。该方案会在每个节点上安装监控组件以实时跟踪各实例的工作情况;同时将非活跃主机设为只读模式以防意外修改破坏整体稳定性[^5]。 #### 总结 综上所述,利用 GTID 可构建更为稳定可靠的 MySQL 高可用体系。不仅能够有效减少人为干预成本,还能极大提升系统的容错能力和服务质量。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值