关于跨地域且主节点为私有IP的MariaDB Replication配置咨询
跨地域MariaDB主从复制(主服务器用私有IP)的解决方案
我来给你梳理几个实际生产环境中常用的可行方案,针对主服务器用私有IP且和从服务器不在同一地域的场景:
方案1:通过VPN/跨地域专线打通私有网络
这是最常规的安全方案,核心是让两地的服务器处于同一个私有网络环境中,这样从服务器就能直接访问主服务器的私有IP:
- 可以搭建IPsec VPN或者OpenVPN,在主、从服务器所在的网络边界部署VPN网关,建立加密隧道;如果是云服务器,很多云厂商也提供现成的VPN服务,配置起来更省心。
- 预算充足的话,也可以申请云厂商的跨地域专线(比如AWS Direct Connect、阿里云专线),这种方式延迟更低、稳定性更强,但成本也更高。
- 优点:数据在私有网络中传输,安全性高;不需要修改主服务器的网络配置;复制延迟主要取决于地域间的物理距离。
- 注意:要确保VPN/专线的带宽能支撑binlog传输的需求,同时配置好两端的防火墙规则,只允许从服务器访问主服务器的3306端口。
方案2:部署公网中转节点做TCP转发
如果不想打通整个私有网络,可以在主服务器所在地域部署一个带公网IP的中转节点,把主服务器的3306端口通过中转节点暴露给从服务器:
- 用Nginx(Stream模块)或者HAProxy来做TCP转发,以Nginx为例,配置大概是这样的:
stream { server { listen 3306; # 只允许从服务器的公网IP访问,提升安全性 allow 从服务器公网IP; deny all; proxy_pass 主服务器私有IP:3306; } } - 从服务器配置主从复制时,把主服务器地址填成中转节点的公网IP即可。
- 优点:不需要修改主服务器的网络,成本低(用一台低配云服务器就行);跨厂商、跨地域都能支持。
- 注意:一定要通过防火墙或者Nginx的
allow/deny限制访问来源,避免公网端口被恶意扫描;中转节点的带宽和稳定性要达标,避免成为复制瓶颈。
方案3:利用云厂商的私有网络互联服务
如果主、从服务器都在同一个云厂商的不同地域,直接用云厂商提供的私有网络互联服务是最便捷的:
- 比如AWS的VPC Peering、阿里云的云企业网(CEN)、腾讯云的对等连接,这些服务可以直接打通两个地域的VPC,让从服务器像在同一个VPC里一样访问主服务器的私有IP。
- 优点:云厂商原生支持,配置简单,稳定性和安全性都有保障;不需要额外维护中转节点或者VPN。
- 缺点:仅支持同厂商的服务器,跨厂商的话没法用;部分厂商可能对互联的地域有限制。
方案4:基于对象存储的异步binlog中转(适合低延迟要求场景)
如果你的业务对复制延迟要求不高(比如允许几分钟甚至几小时的延迟),可以通过对象存储来中转binlog:
- 主服务器这边用脚本或者工具(比如
mysqlbinlog)定期把生成的binlog上传到云对象存储(比如S3、OSS、COS)。 - 从服务器那边定时从对象存储下载binlog,然后通过
mysqlbinlog工具导入到本地数据库,实现异步同步。 - 优点:不需要打通任何网络,跨地域、跨厂商都能用;成本极低,对象存储的费用非常便宜。
- 缺点:是异步同步,无法做到实时复制;需要自己编写脚本维护binlog的上传、下载和导入逻辑,还要处理重复导入、断点续传等问题,数据一致性风险相对较高。
通用注意事项
不管用哪个方案,这些细节都不能忽略:
- 主服务器必须开启binlog,配置唯一的
server-id,并创建专门的复制用户,授予REPLICATION SLAVE权限:CREATE USER 'repl'@'%' IDENTIFIED BY 'your_password'; GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%'; FLUSH PRIVILEGES; - 优先使用半同步复制(Semi-synchronous Replication),在主服务器上开启半同步插件,确保至少有一个从服务器收到binlog后,主服务器才会提交事务,降低数据丢失风险。
- 严格限制访问权限:不管是主服务器还是中转节点,都要通过防火墙(iptables、云安全组)只允许从服务器的IP访问3306端口。
- 监控复制状态:定期用
SHOW SLAVE STATUS\G查看复制状态,确保Slave_IO_Running和Slave_SQL_Running都是Yes,同时监控Seconds_Behind_Master指标,及时发现延迟问题。
内容的提问来源于stack exchange,提问作者Kelvin Tan
相关产品推荐
相关产品推荐

