PolarDB for PostgreSQL 只读节点在线提升为读写节点实战指南

PolarDB for PostgreSQL 只读节点在线提升为读写节点实战指南

PolarDB-for-PostgreSQL 项目地址: https://gitcode.com/gh_mirrors/pol/PolarDB-for-PostgreSQL

引言

PolarDB for PostgreSQL 作为一款云原生数据库，采用了存储与计算分离的架构设计。在这种架构中，所有计算节点共享同一份存储数据，但为了保证数据一致性，系统采用了"一写多读"的访问模式：即同一时间只能有一个计算节点执行写入操作，其他节点只能进行读取操作。

这种设计虽然保证了数据一致性，但也带来了一个潜在问题：当唯一的读写节点发生故障时，整个系统将失去写入能力。本文将详细介绍如何在这种情况下，将一个只读节点在线提升为读写节点，从而恢复系统的完整功能。

核心概念解析

计算节点角色

在 PolarDB for PostgreSQL 集群中，计算节点分为两种角色：

1. 读写节点(RW Node)：唯一拥有写入权限的节点，可以执行所有SQL操作
2. 只读节点(RO Node)：只能执行查询操作，通过物理复制与读写节点保持同步

节点提升(Promote)机制

节点提升是指将一个只读节点转变为读写节点的过程。这个过程需要严格控制在原读写节点确实不可用的情况下进行，否则可能导致"双主"问题，即两个节点同时尝试写入同一存储，造成数据不一致。

环境准备

为了演示节点提升过程，我们可以使用本地测试环境：

1. 启动一个包含HTAP实例的容器环境
2. 该环境预配置了：
   • 1个读写节点（端口5432）
   • 2个只读节点（端口5433和5434）
3. 所有节点共享同一份存储数据

实际操作演示

步骤1：验证初始状态

首先我们验证集群的初始工作状态：

1. 连接到读写节点(5432)创建测试表并插入数据：

   CREATE TABLE t (id int);
   INSERT INTO t SELECT generate_series(1,10);
   

2. 尝试在只读节点(5433)执行写入操作：

   INSERT INTO t SELECT generate_series(1,10);
   

   此时会收到错误："cannot execute INSERT in a read-only transaction"，验证了只读节点的限制。

步骤2：模拟故障场景

我们手动停止读写节点来模拟真实故障场景：

pg_ctl -D ~/tmp_master_dir_polardb_pg_1100_bld/ stop

此时集群中不再有可写入的节点，所有DML和DDL操作都将失败。

步骤3：执行节点提升

选择其中一个只读节点(5433)进行提升操作：

pg_ctl -D ~/tmp_replica_dir_polardb_pg_1100_bld1/ promote

这个命令会：

1. 终止只读节点的复制流程
2. 赋予该节点写入权限
3. 使其开始接受写入请求

步骤4：验证提升结果

连接到新提升的节点(5433)并尝试写入操作：

INSERT INTO t SELECT generate_series(1,10);

此时操作应该成功执行，表明节点已具备写入能力。

技术原理深入

节点提升过程实际上触发了以下内部操作：

1. 复制终止：停止从原主节点接收WAL日志
2. 恢复模式切换：从"恢复模式"切换到"正常模式"
3. 时间线推进：创建新的时间线标识新主节点
4. 写入权限获取：获取对共享存储的写入锁

注意事项

1. 严格单主原则：确保任何时候集群中只有一个可写入节点
2. 故障确认：提升前必须确认原主节点确实不可用
3. 客户端重连：应用需要重新连接到新的主节点
4. 监控设置：建议配置监控及时发现主节点故障

总结

通过本文的实践演示，我们了解了PolarDB for PostgreSQL中只读节点在线提升为读写节点的完整流程。这一功能是保证数据库高可用的关键机制，能够在主节点故障时快速恢复系统写入能力，确保业务连续性。掌握这一技术对于数据库管理员维护PolarDB集群的稳定性至关重要。

PolarDB-for-PostgreSQL 项目地址: https://gitcode.com/gh_mirrors/pol/PolarDB-for-PostgreSQL