PostgreSQL Replication之第十章配置Slony（6）

10.6 执行故障切换

一旦您学会了如何复制表并将它们添加到集合中，是时候学习故障转移了。基本上，我们可以在两个两种类型的故障转移之间做出区分：

• 计划内故障转移

• 计划外故障转移和崩溃

在本节，我们将学习这两个场景。

10.6.1计划内的故障转移

计划内的故障转移更多的是一种奢侈的场景。在许多情况下，您不会很幸运，您必须依靠自动故障转移或者面对意外中断。

基本上，一个计划内的故障转移可以看作是移动一组表到其它节点。一旦其它节点主管那些表，您就可以相应地处理事情。

在我们的例子中，我们希望将这些表从节点1移动到节点2.除此之外，我们玩放弃第一个节点。代码在这里：

slonik<<_EOF_

cluster name = first_cluster;

node 1 admin conninfo = 'dbname=$MASTERDB host=$HOST1 user=$DBUSER';

node 2 admin conninfo = 'dbname=$SLAVEDB host=$HOST2 user=$DBUSER';

lock set (id = 1, origin = 1);

move set (id = 1, old origin = 1, new origin = 2);

wait for event (origin = 1, confirmed = 2, wait on=1);

drop node (id = 1, event node = 2);

_EOF_

在我们标准的介绍之后，我们就可以调用 move set 了。这里的线索是：我们必须创建一个锁使这工作。原因是，当故障转移执行时，我们必须确保我们自己不对系统做出更改。您千万不要忘了这个锁，否则，您可能会发现您自己正处于一个真正糟糕的情况。正如我们以前所有的例子，节点和集合使用它们的数字表示。

一旦我们把这个集合移动到新的位置，我们必须等待事情完成；最后，我们可以放弃那个节点(如果这是期望的话)。

如果该脚本百分之百地正确，它可以被干净地执行：

hs@hs-VirtualBox:~/slony$ ./slony_move_set.sh

debug: waiting for 1,5000016417 on 2

一旦我们没有转移到第二个节点，我们可以马上删除数据。Slony已经删除了触发器来阻止这个操作：

db2=# DELETE FROM t_second;

DELETE 1

相同的情况在第一个节点的表上发生了。处了表本身仍旧在原地，没有更多的触发器了。

db1=# \d t_second

Table "public.t_second"

Column | Type | Modifiers

--------+---------+-----------

id | integer | not null

name | text |

Indexes:

"t_second_pkey" PRIMARY KEY, btree (id)

现在，您可以将节点离线，并将它用于其它用途。

[当使用少的停机时间升级以数据库到一个新的PostgreSQL时，使用计划内的故障转移也是您应该使用的期望的策略。只是复制整个数据库到一个到一个运行新版本的实例，并做一个控制的故障转移。这种升级的实际停机时间将是最小的，因此，在有大量数据的情况下做到这一点是用可能的。]

10.6.2 计划外的故障转移

在计划外的故障转移的情况下，您就不会那么幸运了。一个计划外的故障转移可能是某种严重的中断，一种硬件故障或者某种网站故障。不管它是什么，没有必要害怕—您仍然可以容易地使集群回到一个合理的状态。

要做到这一点，Slony提供了故障转移命令：

• failover (id = 1, backup node = 2);

• drop node (id = 1, event node = 2);

这就是所有您需要在一个剩余的节点上执行的，从一个节点到另一个节点的故障转移，并从集群中删除那个节点。这是一个安全并且可靠的过程。

10.7 总结

Slony是一个广泛在逻辑层次上进行复制PostgreSQL数据库的工具。与事务日志传送相比，它可用于各种不同版本的PostgreSQL的复制，并且无需复制整个实例。

在下一章，我们将重点关注Skytools，一个可行的Slony的替代方案。我将包括安装，通用队列和复制。