PostgreSQL集群管理与维护：Patroni实战指南

### PostgreSQL集群管理与维护：Patroni实战指南 #### 1. 临时暂停集群管理 Patroni将自己视为所管理的PostgreSQL系统的真正仲裁者。若要避免一些意外情况，可临时推迟集群管理。使用`patronictl`命令的`pause`参数来实现，示例命令如下： ```bash patronictl pause -d pg1:2379 stampede ``` 暂停期间，Patroni不会检测故障、触发自动故障转移或执行其他高可用性操作。若要将集群恢复到标准管理状态，使用`resume`参数，命令如下： ```bash patronictl resume -d pg1:2379 stampede ``` #### 2. 利用故障测试可用性 高可用性集群必须具备检测和绕过服务器故障的能力。硬件故障、虚拟实例崩溃、输入错误的命令等潜在灾难无处不在。测试集群真正弹性的最佳方法是制造故障。 ##### 2.1 准备工作 确保整个堆栈已存在，完成安装和配置HAProxy之前的所有步骤。 ##### 2.2 操作步骤 假设已有三个PostgreSQL服务器，分别命名为pg1、pg2和pg3。若pg2是当前主节点，按以下步骤模拟服务器故障： 1. 在pg2上以postgres用户身份执行以下命令： ```bash pkill -f patroni ``` 2. 在pg1或pg3上使用以下命令跟踪Patroni日志： ```bash tail -f /var/log/postgresql/patroni.log ``` ##### 2.3 工作原理 此方法避免了重启服务器的繁琐过程。Patroni守护进程认为自己是PostgreSQL服务的唯一协调者。`pkill`命令可在不知道进程ID的情况下停止服务，使用`-f`标志可匹配启动Patroni守护进程的完整命令文本，从而停止所有名为`patroni`的正在运行的进程。 当主节点上的Patroni停止运行时，键值层中主节点指针的锁将过期。在下一次内部状态迭代时，pg1和pg3会发现没有注册的领导者，并尝试争夺该位置。只有一个节点能赢得竞争。通过在pg1或pg3上使用`tail -f`命令，可观察到接管过程。 ##### 2.4 其他方法 使用`tail`命令查看日志是常用方法，但需知道哪个服务器赢得了领导者竞争才能确定查看哪个日志。可使用`patronictl`的`list`参数，还可使用`-w`标志以可配置的间隔运行命令来“监视”，示例命令如下： ```bash patronictl list -w 5 -d pg1:2379 stampede ``` 大多数Linux系统都安装了`watch`命令，也可实现相同功能，命令如下： ```bash watch -n 5 patronictl list -d pg1:2379 stampede ``` #### 3. 将节点重新添加到集群 系统在重大崩溃或故障后恢复并非易事，需重启或恢复服务器、进行故障排查并修复或替换损坏的二进制文件。使用Patroni作为高可用性解决方案的系统也是如此，但Patroni可自动处理恢复受损PostgreSQL数据库中一些繁琐的部分。 ##### 3.1 准备工作 确保整个堆栈已存在，完成本章之前的所有步骤。还需要一个损坏的服务器，可通过以下命令模拟不可恢复的服务器崩溃： ```bash pkill -9 patroni pkill -9 postgres find /db/pgdata -name '*r*' -o -name '*0*' -delete ``` ##### 3.2 操作步骤 假设已有三个PostgreSQL服务器，分别命名为pg1、pg2和pg3。按以下步骤修复损坏的系统： 1. 在损坏的系统上以postgres用户身份运行以下命令，删除损坏集群的内容： ```bash rm -Rf /db/pgdata ``` 2. 以postgres用户身份使用以下命令启动新的Patroni守护进程： ```bash patroni /etc/patroni/stampede.yml \ &> /var/log/postgresql/patroni.log & ``` 3. 使用以下命令跟踪Patroni日志： ```bash tail -f /var/log/postgresql/patroni.log ``` ##### 3.3 工作原理 当系统故障严重时，可能无法确定系统文件的损坏程度。若数据库未使用文件校验和初始化，可能数周后才会发现损坏。若崩溃的服务器在这之前成为主节点，这些损坏可能会复制到其他系统。因此，更安全的做法是从头开始。第一步是删除`/db/pgdata`目录，这样Patroni就不会被旧文件误导，它将通过调用`pg_basebackup`重建数据，并根据`/etc/patroni/stampede.yml`中的配置配置实例。 ##### 3.4 其他方法 对于非常大的数据库安装，删除所有数据并重新同步非常耗时、耗网络和耗IO。对于这种情况，可在启动Patroni之前使用`rsync`手动同步数据文件。以下是从pg1重建pg2时可能使用的命令： ```bash psql -U rep_user -h pg1 \ -c "SELECT pg_start_backup('resync', TRUE);" postgres rsync -av --delete-after postgres@pg1:/db/pgdata /db psql -U rep_user -h pg1 postgres\ -c "SELECT pg_stop_backup();" rm /db/pgdata/postmaster* ``` #### 4. 添加额外节点 随着业务发展，可能需要扩展PostgreSQL服务器集群以处理更多流量、提高可用性或淘汰旧系统。在已建立`etcd + HAProxy + Patroni`堆栈的情况下，添加新节点的过程如下： ##### 4.1 准备工作 此步骤主要依赖于安装和配置etcd、安装和配置Patroni以及安装和配置HAProxy的步骤，但需注意不能完全按照原步骤执行，后续步骤会说明必要的偏差。 ##### 4.2 操作步骤 假设要将新的pg4服务器添加到堆栈中，已有pg1、pg2和pg3在运行。按以下步骤将pg4完全集成到集群中： 1. 按照安装和配置etcd的步骤为pg4进行操作，直到被要求启动etcd，但不要启动该服务。 2. 在pg1、pg2或pg3中的任何一个上以postgres用户身份执行以下命令： ```bash etcdctl member add pg4 http://pg4:2380 ``` 3. 修改pg4上的`/etc/etcd.conf`配置文件，确保包含以下行： ```plaintext ```