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创建新表，但是，不推荐这样做。给一个表添加一列肯定会以灾难告终。