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

10.4 部署DDLs

对于生产性的应用程序来说，仅仅复制一个表明显是不够的。此外，通过没有办法保证数据从来不会发生改变。在某些时候，部署变化的数据结构(所谓的DDLs)是必要的。

现在的问题是，Slony严重依赖于触发器。当表中的一行数据发生变化时，触发器触发。这对所有的表都适用—但是，它不适用于系统表。所以，如果您部署一个新表，或者您碰巧改变了一列，Slony是没有办法检查到的。所以，您必须运行一个脚本来部署在集群内部的变化来使它工作。

[PostgreSQL 9.3 已经有一些基本的触发 DDLs 的功能，但是，对于 Slony 来说，这是不够的。然而，未来的 PostgreSQL 版本很可能是能够处理DDLs内部的触发器的。]

我们需要一个slonik脚本：

#!/bin/sh

MASTERDB=db1

SLAVEDB=db2

HOST1=localhost

HOST2=localhost

DBUSER=hs

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';

execute script (

filename = '/tmp/deploy_ddl.sql',

event node = 1

);

_EOF_

成功的关键是 execute script. 我们简单地传递一个SQL文件来调用并告诉它咨询节点1。SQL文件的内容可以说是相当的简单—它应该简单地列出我们要执行的DDLs：

CREATE TABLE t_second (id int4, name text);

可以像以前一样运行该文件：

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

该表将被部署到两个节点上。下面的列表显示，该表也部署到了第二个节点上，这足以证明事情已经按预期工作了：

db2=# \d t_second

Table "public.t_second"

Column | Type | Modifiers

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

id | integer |

name | text |

当然，您也可以不使用Slony创建新表，但是，不推荐这样做。给一个表添加一列肯定会以灾难告终。