Mysql Group Replication 主从(单主)中间件ProxySQL安装配置

本文详细介绍如何使用ProxySQL管理MySQL Group Replication集群,包括安装配置ProxySQL、创建MGR集群用户、配置读写分离、设置监控脚本等步骤。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

注意:第4、第5两步的操作可以在mysql group replication主节点上先行执行。

 

1、下载安装ProxySQL

wget https://github.com/sysown/proxysql/releases/download/v1.3.3/proxysql-1.3.3-1-centos67.x86_64.rpm
rpm –ivh proxysql-1.3.3-1-centos67.x86_64.rpm

 

2、启动ProxySQL

service proxysql start

 

3、登录ProxySQL

mysql -h127.0.0.1 -P6032 -uadmin -padmin

 

4、MGR集群创建相关用户并授权

#在集群的主节点执行如下脚本
#添加监控用户并授权
grant all privileges on *.* to 'proxysql'@'172.16.90.%' identified by 'proxysql';
#添加代理业务用户并授权
CREATE USER 'proxyuser'@'%' IDENTIFIED BY 'proxypass'; 
GRANT INSERT,UPDATE,DELETE,SELECT ON * . * TO 'proxyuser'@'%';
flush privileges;

 

5、创建检查MGR节点状态的函数和视图

参照前面的博客,在MGR主节点上执行下面链接中的SQL 

https://github.com/lefred/mysql_gr_routing_check/blob/master/addition_to_sys.sql

source /root/addition_to_sys.sql

 

6、配置proxysql

    添加MGR成员节点到proxysql mysql_servers表

insert into mysql_servers (hostgroup_id, hostname, port) values(1, '172.16.90.39', 3306);
insert into mysql_servers (hostgroup_id, hostname, port) values(2, '172.16.90.39', 3306);
insert into mysql_servers (hostgroup_id, hostname, port) values(2, '172.16.90.40', 3306);
insert into mysql_servers (hostgroup_id, hostname, port) values(2, '172.16.90.41', 3306);

    hostgroup_id = 1代表write group,针对我们提出的限制,这个地方只配置了一个节点;hostgroup_id = 2代表read group,包含了MGR的所有节点。

proxysql还可以配置读写分离,本文不考虑这个特性的配置。对于上面的hostgroup配置,所有的读写操作,默认会发送到hostgroup_id1hostgroup,也就是发送到写节点上。

修改proxysql监控的用户及密码

UPDATE global_variables SET variable_value='proxysql' WHERE variable_name='mysql-monitor_username';
UPDATE global_variables SET variable_value='proxysql' WHERE variable_name='mysql-monitor_password';

 添加应用通过proxyuser访问后端MGR节点的用户

INSERT INTO MySQL_users(username,password,default_hostgroup) VALUES ('proxyuser','proxypass',1);

 global_variablesmysql_serversmysql_users表的信息加载到RUNTIME,更进一步加载到DISK

LOAD MYSQL VARIABLES TO RUNTIME;
SAVE MYSQL VARIABLES TO DISK;
LOAD MYSQL SERVERS TO RUNTIME;
SAVE MYSQL SERVERS TO DISK;
LOAD MYSQL USERS TO RUNTIME;
SAVE MYSQL USERS TO DISK;

 

 

7、配置scheduler

Github地址https://github.com/ZzzCrazyPig/proxysql_groupreplication_checker下载gr_sw_mode_checker.sh

将脚本gr_sw_mode_cheker.sh放到目录/var/lib/proxysql/下 

proxysqlscheduler表里面加载如下记录,然后加载到RUNTIME使其生效,同时还可以持久化到磁盘

 

insert into scheduler(id, active, interval_ms, filename, arg1, arg2, arg3, arg4)
  values(1, 1, 3000, '/var/lib/proxysql/gr_sw_mode_checker.sh', 1, 2, 1, '/var/lib/proxysql/checker.log');
LOAD SCHEDULER TO RUNTIME;
SAVE SCHEDULER TO DISK;

 

8、java连接proxysql配置

 

jdbc.url=jdbc:mysql://172.16.90.39:6033/ifaes_test?useUnicode=true&characterEncoding=utf-8&allowMultiQueries=true
jdbc.username=proxyuser
jdbc.password=proxypass

 

 

<think>嗯,用户这次问的是MySQL主从同步假死的问题,结合之前提供的几个引用来看,确实都是围绕MySQL运维中的典型故障场景展开的。用户能明确提出“假死”这个现象,说明至少具备基础的数据库运维经验,可能是个中级DBA或者开发负责人。从引用来分析线索:引用1提到线上疑难杂症但没直接说内存问题;引用2详细描述了ProxySQL踢出假死主库的操作流程,这个非常关键;引用3指出MySQL读写分离的必要性问题;引用4则给出了MHA的故障处理流程。用户可能真正需要的是实战级的故障恢复方案,而非理论解释。主从假死确实是个棘手问题,常见诱因得拆开说。网络问题方面,云环境尤其容易出现瞬时丢包导致复制中断;MySQL内部原因要重点看三个点:内存不足导致复制线程崩溃、大事务阻塞复制线程、或者主从server_id冲突这种低级错误。另外用户没提版本信息,但5.6和8.0版本的复制机制差异较大需要针对性处理。解决方案需要分层设计:诊断层面最重要的是实时监控Seconds_Behind_Master状态和IO/SQL线程错误码;修复层面分为紧急操作(比如引用2里ProxySQL的HARD_OFFLINE操作)和根治措施。用户引用的MHA方案其实给出了完整的高可用架构思路,不过考虑到实施复杂度,应该先给即时可用的命令级解决方案。特别要注意的是,回复里必须警告数据一致性风险——直接resetslave虽然快,但可能造成数据错乱,这个坑很多新人会踩。最后补充的读写分离建议其实来自引用3的逻辑延伸,既解决根本问题又贴合用户提供的参考资料。关于后续问题设计,用户明显更关注实战而不是理论,所以重点延伸了状态诊断和工具集,比如pt工具链的使用场景。另外特意加了连接池配置的优化点,因为很多假死其实是应用端连接池耗尽导致的误判。</think> MySQL主从同步假死(即主从复制中断但进程未崩溃)是常见的高可用隐患。以下是常见原因及针对性解决方案,结合运维实践整理: --- ### **一、常见原因** 1. **网络问题** - 瞬时网络抖动(丢包率 > 1%) - 防火墙阻断了复制端口(默认3306) - DNS解析不稳定 2. **主库资源瓶颈** - 磁盘I/O满载(`iostat -xm 1` 显示 `%util > 90%`) - CPU持续高负载(`sysbench cpu run` 测试单核 > 80%) - 二进制日志(binlog)写入阻塞 3. **从库处理延迟** - 大事务未拆分(如单个事务更新100万行) - 长查询阻塞SQL线程(`SHOW PROCESSLIST` 观察 `State: Waiting for table metadata lock`) - 从库配置低于主库(如 `innodb_buffer_pool_size` 过小) 4. **数据一致性破坏** - 人为在从库写入数据(违反只读原则) - 主从不一致的 `server_id` 配置 - 非幂等操作(如 `INSERT IGNORE`)导致复制冲突 --- ### **二、诊断步骤** 1. **检查复制状态** ```sql SHOW SLAVE STATUS\G ``` **关键字段**: - `Slave_IO_Running`:网络/IO线程状态 - `Slave_SQL_Running`:SQL执行线程状态 - `Seconds_Behind_Master`:延迟时间(>60秒需告警) - `Last_IO_Error` / `Last_SQL_Error`:具体错误信息 2. **分析错误日志** ```bash grep "replication" /var/log/mysql/error.log ``` 常见错误类型: - `ER_MASTER_FATAL_ERROR_READING_BINLOG`(主库binlog异常) - `ER_KEY_NOT_FOUND`(从库数据缺失) --- ### **三、解决方案** #### **A. 网络问题** - **临时恢复**:重启复制线程 ```sql STOP SLAVE; START SLAVE; ``` - **根治方案**: - 主从间部署专线(延迟 < 1ms) - 启用TCP Keepalive(`net.ipv4.tcp_keepalive_time=60`) #### **B. 主库性能瓶颈** 1. **优化binlog写入** ```ini [mysqld] sync_binlog = 0 # 牺牲部分安全性提升IO性能 binlog_group_commit_sync_delay = 1000 # 组提交延迟(毫秒) ``` 2. **拆分大事务** - 将 `UPDATE large_table SET ...` 改为分批更新(每批1000行) #### **C. 从库延迟** 1. **并行复制加速** ```ini [mysqld] slave_parallel_workers = 4 # 并行线程数=CPU核心数 slave_preserve_commit_order = 1 # 保持事务顺序 ``` 2. **禁用非必要约束** ```sql SET GLOBAL foreign_key_checks=OFF; -- 需评估数据风险 ``` #### **D. 数据不一致** 1. **自动修复工具** ```bash pt-table-checksum # 校验主从数据差异 pt-table-sync --execute # 自动修复差异(生产环境先模拟) ``` 2. **重建复制链路**(终极方案) ```bash mysqldump --single-transaction -uroot db | mysql -uSlave db ``` --- ### **四、预防措施** 1. **架构层面** - 部署MHA或Orchestrator实现主库故障自动切换(引用4)[^4] - 读写分离中间件(如ProxySQL)自动摘除异常节点(引用2)[^2] ```sql UPDATE mysql_servers SET status='HARD_OFFLINE' WHERE host='down_host'; LOAD MYSQL SERVERS TO RUNTIME; ``` 2. **监控体系** - 实时告警 `Seconds_Behind_Master > 30` - 定期检查 `SHOW SLAVE STATUS` 输出 > **关键建议**:当出现 `Last_SQL_Error: Could not execute Write_rows event` 等冲突时,**切勿直接跳过错误**(`SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1`),优先使用 `pt-table-sync` 修复数据。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值