这是一个创建于 1490 天前的主题，其中的信息可能已经有所发展或是发生改变。
线上有几个旧项目,当时开发没考虑过数据库并发问题
现在为了保证业务可靠,准备了备机(记为 B1),当服务器(记为 A1)出现故障,需要启动 B1 的服务,
同时要保证 A1 无法连接数据库(A1 故障可能只是短时间网络波动)
现在的问题是如何避免 B1 正常服务时,A1 故障自动恢复后对数据库连接操作
各位大佬有什么好的解决方案? 小弟先谢谢了
现在为了保证业务可靠,准备了备机(记为 B1),当服务器(记为 A1)出现故障,需要启动 B1 的服务,
同时要保证 A1 无法连接数据库(A1 故障可能只是短时间网络波动)
现在的问题是如何避免 B1 正常服务时,A1 故障自动恢复后对数据库连接操作
各位大佬有什么好的解决方案? 小弟先谢谢了
 |
1
xxxy 2020-12-01 13:59:07 +08:00
数据库主主同步
|
 |
2
opengps 2020-12-01 14:08:38 +08:00 via Android
数据库作为内网服务，网络波动因素很小，反倒是需要重点关注下是不是峰值超过了数据库承载力
如果真的只是担心主节点挂掉，那么数据库主从热备确实需要 |
 |
3
nikandaoleshenme 2020-12-01 14:17:33 +08:00
换个稳定的主机，比如这台 uptime 14:12:31 up 398 days, 3:59，近 400 天，没停机，上面的服务也没有宕机
服务器没有你想的那么重要，当然也没有你想的那么弱不禁风，说故障就故障了 |
 |
4
Bazingal 2020-12-01 14:29:11 +08:00 via Android  1
nginx 反代设置 B 为 backup
|
 |
5
DoctorCat 2020-12-01 14:40:24 +08:00
一楼正解，双主同步最简单。具体可参考 keepalived 方案
|
 |
6
xuanbg 2020-12-01 15:12:15 +08:00
假设数据库只有一个，那你要确定服务有没有定时任务什么的会访问数据库，如果没有的话，4 楼的方案最简单实用，基本上就是无缝切换。如果有的话，就只能在服务挂掉后在开机了，你想要无缝切换主备是不可能的。
任何事情都是有代价的，我认为最好的办法就是改成双实例，搞个分布式锁，需要锁的地方锁上就行了。一般来说需要加锁的地方不是很多。 |
 |
7
yeqizhang 2020-12-01 15:16:58 +08:00
只考虑数据主主同步我觉得不太符合楼主的应用场景，不知道楼上有说的 nginx backup 那个是否符合楼主的
|
 |
8
mhycy 2020-12-01 15:32:12 +08:00
数据库代理
|
 |
9
lc1450 OP |
Select Language