主页 / dba / 问题 / 14201
Accepted
wingedrhino
Asked: 2012-03-02 05:47:08 +0800 CST

PostgreSQL 故障转移 - 我应该使用哪些工具？

  • 772

这是场景：

有两台机器运行 CentOS 6.2 - machine0 和 machine1

两者都安装了 PostgreSQL 9.1。

其中一个应该是活动的，作为主系统并通过异步流复制另一台机器，备用应该从主系统复制更改到数据库。

假设一开始machine0是master，machine1是standby。

如果主服务器（比如 machine0）发生故障（这里的故障意味着 postgresql 服务器崩溃），备用服务器应该从主服务器接管并成为新的主服务器。

machine1，新的 master 处理所有数据库操作，当 machine0 中的 postgresql 服务器重新上线时，它应该成为备用，从它与 machine1 失去联系的点开始同步并将所有更改复制到数据库并保持备用模式。

当 machine1 发生故障时，整个循环重复。

当备用数据库失败并重新上线时，它应该开始从主数据库读取并同步数据。

我很困惑我需要使用哪些工具来设置它，因为我了解 PostgreSQL 默认情况下不附带故障转移。

如果有人可以将我链接到描述如何做我正在尝试的线程/页面，我将非常感激。

postgresql replication

1 个回答

  1. Best Answer

    如果您对同步数据库复制和故障转移感兴趣，我有一个建议。您可以考虑使用两种工具：

    • DRBD（磁盘复制块设备）在两个不同服务器上的磁盘之间提供磁盘级复制（同步）。磁盘更改通过网络复制。对于使用 192.168.xx 网络块的 NIC，最好在 eth2 上使用交叉电缆。

    • ucarp允许在两个不同的服务器之间进行 DBVIP 管理和故障转移。

    您可以将它们结合使用，如下所示：

    • DBServer1 的 IP 为 10.1.2.30
    • DBServer2 的 IP 为 10.1.2.40
    • DB VIP 为 10.1.2.70

    在两个不同的服务器上设置 ucarp，使每个 ucarp 实例通过一个虚拟路由器 ID 与另一个实例通信

    DBServer1 将有

    /usr/local/sbin/ucarp -v 200 -p sometagname --interface=eth2 -a 10.1.2.70 -s 10.1.2.30 -b 3 -r 5 --upscript=/usr/local/sbin/vip-up.sh --downscript=/usr/local/sbin/vip-down.sh --neutral -z -B

    DBServer2 将有

    /usr/local/sbin/ucarp -v 200 -p sometagname --interface=eth2 -a 10.1.2.70 -s 10.1.2.40 -b 4 -r 5 --upscript=/usr/local/sbin/vip-up.sh --downscript=/usr/local/sbin/vip-down.sh --neutral -z -B

    -b（广播）在一台服务器上是 3 而在另一台服务器上是 4 的原因是什么？如果两个服务器都重新启动，具有最低 -b 的服务器将首先带上 ucarp。至于-r，就是死比。因此，DBServer1 将在 15 秒内启动 (3X5)，而 DBServer2 在 20 秒内启动 (4X5)。

    假设 DBServer1 崩溃。DBServer2 上的 ucarp 将在 20 秒内检查与 DBServer1 上的 ucarp 的握手。如果没有检测到，DBServer2 上的 vip-up.sh 脚本将控制 DBVIP。

    好的，所有这些都只是为了故障转移和 DBVIP 管理。PostgreSQL 数据库呢？令人惊讶的是，PostgreSQL 一次只在一台服务器上运行。拥有 DBVIP 的人应该将 DRBD 置于 Primary 状态。这与 vip-up 脚本有关。你如何编写脚本？

    这是 /usr/local/sbin/vip-down.sh 脚本（概念）

    #! /bin/sh
exec 2> /dev/null
/sbin/drbdadm disconnect drbd0
/sbin/drbdadm  primary drbd0 &&
/bin/mount postgres-data-folder /mnt/drbd0
/sbin/ip addr add 10.1.2.70/24 dev eth2
/sbin/service postgres start &&
/usr/local/sbin/vipmon.sh &
touch /tmp/vip-up

    这是 /usr/local/sbin/vip-down.sh 脚本（概念）

    #! /bin/sh
exec 2> /dev/null
/sbin/service postgres stop
/bin/umount -l  /dev/drbd0
/sbin/drbdadm secondary drbd0
/sbin/ip addr del 10.1.2.70/24 dev eth2
/bin/rm /tmp/vip-up
/usr/bin/killall -9 ucarp
/usr/local/sbin/vip-down.sh
kill `ps auxww | grep vipmon | awk '{print $2}'`

    您需要做的就是设置 pg_hba.conf 以确保所有用户都来自 10.1.2.70

    本质上，vip-up 执行这个序列

    • 让 DRBD 进入主节点
    • 在 /dev/drbd0 上挂载 postgres 数据文件夹
    • 启动 postgres
    • 启动vipmon进程

    相反，vip-down 执行此序列

    • 关闭 postgres
    • unount /dev/drbd0
    • 让 DRBD 成为次要的

    vipmon.sh 呢？您可以编写脚本以在无限循环中检查 postgres 的状态（它正在运行），检查 DRBD 设备（您仍然可以写入帖子数据文件夹吗）

    使用此设置，您在 DRBD Primary 上拥有 postgres，在另一个 DBServer（DRBD Secondary）上拥有 postgres 数据文件夹的磁盘级副本。postgres 未在 DRBD 辅助节点上运行。

    当发生故障转移时，您只需要时间让 ucarp 检测挂载 postgres 数据、启动 postgres 和激活 vipmon 脚本是否安全。

    这种设置的好处在于，在发生故障转移的情况下，成为 DRBD Primary 的 DBServer 应该拥有您故障所在服务器的 100% 磁盘级副本。因此，启动 postgres 应该使您处于一致的状态。事务日志（在 pg_xlog 中）应该是完整的（减少由于故障转移引起的间歇性）

    我希望这些建议有所帮助。虽然我是一名 MySQL DBA，但我经常在我雇主的网络托管公司使用 MySQL 和 DRBD。我以上述方式安装了 MySQL/DRBD。我为使用 PostgreSQL/DRBD 的客户做了一次。它工作得很好。它是开源的。您只需要在学习 DRBD 和 ucarp 时进行尽职调查。这将包括在故障转移后重新连接 DRBD，处理两个数据库服务器都成为主服务器的裂脑场景，以及诸如此类的事情。

    • 5

相关问题