云部署(2)keepalived+postgresql主从切换

本文详细介绍了利用keepalived实现postgresql主从切换的过程,当主库故障时,备库自动接管服务。在主从切换后,主库变为从库,备库成为新的主库并可读写。同时讨论了故障恢复时,如何将原主库恢复为从库,包括数据同步和配置调整等步骤。

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

在主从部署成功后,主库写入数据会同步到备库中。

keepalived检测pgsql的状态,当主库停止时,keepalived会将自己杀死,vip移到备库中,此时备库对外提供服务,但是不能写入。

下面配置主从切换后,从变成主,可读写。主变成从,只同步数据。

此时基于云部署(1),我的两个主从服务器状态同步正常

1.主从停掉postgres库,然后主从的keepalived都会停止,最好再检查一下让它们都停止。

2.修改主从的配置文件,如下:

[root@ss keepalived]# cat keepalived.conf
! Configuration File for keepalived

global_defs {
   notification_email {
     ***@qq.com
   }
   notification_email_from ***@***.com
   smtp_server 127.0.0.1
   smtp_connect_timeout 30
   router_id ss
}

vrrp_script chk_pgsql {
   script "/etc/keepalived/pgsql_check.sh"
   interval 2
   weight -5
   fall 2
   rise 1
}
vrrp_instance VI_1 {
    state BACKUP  #主从都是BACKUP
    interface eth0
    virtual_router_id 51
    priority 100 #从改成96
    advert_int 1
    authentication {
        auth_type PASS
  &n
<think>我们正在讨论主从切换机制的设计。用户的问题是如何设计主从切换机制以确保机和从机可以正确切换角色。我们需要参考之前提供的引用内容,并结合分布式系统设计的通用原则来回答。引用[1]提到Redis哨兵实现主从切换:当服务器失效时,哨兵会将一个从服务器升级为服务器,并让其他从服务器复制新的服务器。客户端连接失效服务器时,会被告知新的服务器地址。引用[2]提到MySQL主从切换:当库宕机时,需要提升从库为库。原库恢复后,需要将其设置为新库的从库,并指定新的库的日志文件和位置。引用[3]提到PostgreSQL主从切换:原库重新启动前需要修改配置文件,否则会脱离主从环境成为独立库。结合这些引用,我们可以总结主从切换机制的关键设计点:1.**故障检测**:需要有一个机制持续监控节点的健康状态(如心跳检测)。2.**故障决策**:当检测到节点故障时,需要选举新的节点(通常基于优先级、数据完整性等)。3.**角色切换**:将选定的从节点提升为节点,并重新配置其他从节点指向新的节点。4.**故障恢复**:当原节点恢复后,需要将其重新加入集群作为从节点,并同步新节点的数据。5.**配置持久化**:避免原节点重新启动后成为独立节点(如PostgreSQL中修改配置文件)。设计一个主从切换机制应包括以下步骤:**1.故障检测机制**-使用心跳检测(如哨兵、keepalived)定期检查节点状态。-设置超时阈值,超过阈值则认为节点失效。**2.选举新节点**-从从节点中选择一个作为新的节点。选择依据可能包括:-数据同步的完整性(如复制位置最接近原节点)-节点的优先级(预先配置)-节点的负载情况**3.切换流程**-提升选定的从节点为节点:修改其配置,使其成为节点(如停止复制,重置复制关系,设置可写)。-重新配置其他从节点:让它们复制新的节点(修改复制源)。-更新服务发现机制(如DNS、配置中心)或通知客户端新的节点地址。**4.原节点恢复处理**-当原节点恢复后,应将其设置为新节点的从节点:-清除其旧的节点数据(如重置复制日志)-配置其复制新的节点(指定新节点的地址、日志文件和位置)-确保配置持久化,避免重启后脱离集群(如修改配置文件)。**5.防止脑裂**-在切换过程中,需要确保只有一个节点(通过选举机制、多数投票等)。-当原节点恢复时,要确保它不会尝试重新成为节点(通过配置或仲裁机制)。下面是一个通用的主从切换流程示意图:```mermaidgraphTDA[节点故障]-->B[故障检测]B-->C{选举新节点}C-->D[提升从节点为新节点]D-->E[重新配置其他从节点]E-->F[通知客户端]F-->G[原节点恢复]G-->H[配置原节点为从节点]H-->I[同步新节点数据]```以MySQL为例,具体操作步骤如引用[2]所述:-从库变库:-确保从库数据同步完成(`Slavehasreadallrelaylog`)-停止复制(`STOPSLAVE`)-重置复制关系(`RESETMASTER`,`RESETSLAVEALL`)-记录新的库状态(`SHOWMASTERSTATUS`,获取日志文件和位置)-原库变从库:-重置复制关系(`RESETMASTER`,`RESETSLAVE`)-配置复制到新的库(`CHANGEMASTERTO...`)-启动复制(`STARTSLAVE`)在Redis中,哨兵系统自动完成这些步骤。设计主从切换机制时还需要考虑:-**自动化程度**:手动切换(人工干预)还是自动切换(如哨兵)。-**数据一致性**:确保切换过程中数据不丢失(如使用半同步复制)。-**切换时间**:故障检测时间+切换时间,影响系统可用性。因此,一个健壮的主从切换机制需要包括故障检测、选举、切换、恢复和防止脑裂等关键步骤,并且需要根据具体数据库系统进行实现细节的调整。</think>### 主从切换机制设计方法 主从切换的核心在于**状态监控、决策机制和角色切换**三个关键环节。以下是确保机和从机正确切换角色的设计方法: --- #### 一、故障检测机制(状态监控) 1. **心跳检测** - 机定期向从机/哨兵发送心跳包(如Redis Sentinel[^1]) - 超时阈值设计: $$ T_{timeout} = 3 \times T_{heartbeat} + \Delta T_{network} $$ - 连续失败次数阈值(通常3次) 2. **健康检查** - 数据库连接性验证(如MySQL `SHOW SLAVE STATUS`[^2]) - 数据一致性校验(如PostgreSQL WAL日志比对[^3]) - 资源监控(CPU/内存/磁盘) --- #### 二、决策机制(故障判定) 1. **仲裁模式选择** | 模式 | 适用场景 | 优点 | |---------------|--------------------------|--------------------| | 单点决策 | 简单系统(如单哨兵) | 响应快 | | 多数投票 | 分布式系统(≥3节点) | 防误判 | | 分层仲裁 | 跨机房部署 | 容灾性强 | 2. **切换条件** - 库连续心跳超时 - 库服务不可用(端口无响应) - 数据同步延迟超过阈值(如MySQL `Seconds_Behind_Master > 30s`) --- #### 三、角色切换流程 ```mermaid graph TD A[故障检测] --> B{库失效?} B -->|是| C[选举新库] C --> D[提升从库为库] D --> E[重配其他从库] E --> F[原库降级] B -->|否| G[维持现状] ``` 1. **新库选举** - 优先级策略:选择数据最新的从库(比较复制位置) - 负载均衡策略:选择资源最充足的节点 - 手动干预标记(维护模式) 2. **从库提升操作** **Redis示例**: ```shell REPLICAOF NO ONE # 解除从属关系 CONFIG REWRITE # 持久化配置 ``` **MySQL示例**[^2]: ```sql STOP SLAVE; RESET MASTER; # 清除原库信息 RESET SLAVE ALL; ``` 3. **其他从库重配** ```sql CHANGE MASTER TO MASTER_HOST='new_master_ip', MASTER_LOG_FILE='mysql-bin.000002', MASTER_LOG_POS=107; START SLAVE; ``` 4. **原库降级** - 数据回滚:清除未同步数据 - 重配为从库(PostgreSQL需修改`postgresql.auto.conf`[^3]) - 加入集群后自动同步差异数据 --- #### 四、防脑裂设计 1. **隔离机制** - 故障库自动隔离(网络层面阻断) - STONITH(Shoot The Other Node In The Head):强制关闭原2. **数据一致性保障** - 半同步复制(至少一个从库确认才提交) - 切换前检查GTID/WAL位置 - 客户端重定向机制(如Redis返回新库地址[^1]) --- #### 五、设计验证要点 1. **切换时间测试** - 90%场景切换时间 < 10秒 - 最大容忍中断时间 < 30秒 2. **异常场景覆盖** - 库假死(进程存活但无响应) - 网络分区(裂脑场景) - 多节点同时故障 > **关键原则**:切换后必须满足 $$ \text{新库数据完整性} \geq \text{故障前最后提交数据} $$ --- ### 典型实现对比 | 系统 | 切换工具 | 特点 | |-------------|---------------|-------------------------------| | Redis | Sentinel | 自动选举+客户端重定向 [^1] | | MySQL | MHA/Orchestrator | 基于GTID的位置精确恢复 [^2] | | PostgreSQL | Patroni | 基于DCS的分布式决策 [^3] | 通过分层检测、多数仲裁、精确位置同步和客户端重定向四重保障,可实现机从机角色的安全切换
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值