10.3 复制您的第一个数据库
这个小小的介绍之后，我们可以继续前进并复制我们的第一个数据库。要做到这一点，我们可以在一个数据库实例上创建两个数据库。我们想简单地在这两个数据库之间进行复制。
[ 您在一个实例上复制或在两个实例上复制，这是没有区别的—它的工作原理完全一样。]
一旦您的实例启动并运行了，创建这两个数据库应该是一件容易的事：
hs@hs-VirtualBox:~$ createdb db1
hs@hs-VirtualBox:~$ createdb db2
现在我们可以创建一个表，它应该被从数据库db1复制到数据库db2:
db1=# CREATE TABLE t_test (id serial, name text,
PRIMARY KEY (id));
NOTICE: CREATE TABLE will create implicit sequence "t_test_id_seq" for
serial column "t_test.id"
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "t_test_
pkey" for table "t_test"
CREATE TABLE
在两个数据库上，以相同的方式创建这个表；因为表结构不会自动复制。
一旦这项工作完成，我们可以写一个slonik脚本告诉关于我们的两个节点的集群。slonik是一个我们可以用来和Slony进行直接对话的命令行接口。您也可以用它交互工作，但，这不是太方便。
注册这些节点的脚本将如下所示：
#!/bin/sh
MASTERDB=db1
SLAVEDB=db2
HOST1=localhost
HOST2=localhost
DBUSER=hs
slonik<<_EOF_
cluster name = first_cluster;
# define nodes
node 1 admin conninfo = 'dbname=$MASTERDB host=$HOST1 user=$DBUSER';
node 2 admin conninfo = 'dbname=$SLAVEDB host=$HOST2 user=$DBUSER';
# init cluster
init cluster ( id=1, comment = 'Master Node');
# group tables into sets
create set (id=1, origin=1, comment='Our tables');
set add table (set id=1, origin=1, id=1,
fully qualified name = 'public.t_test',
comment='sample table');
store node (id=2, comment = 'Slave node',
event node=1);
store path (server = 1, client = 2, conninfo='dbname=$MASTERDB
host=$HOST1 user=$DBUSER');
store path (server = 2, client = 1, conninfo='dbname=$SLAVEDB
host=$HOST2 user=$DBUSER');
_EOF_
首先，我们定义了几个环境变量。这不是必须的，但是确保万一有变化，没有任何事情被遗忘是很方便的。然后，我们的slonik脚本启动了。
我们要做的第一件事是定义一个集群名。这一点很重要：使用Slony，集群是一个更加虚拟的东西—它并不需要和物理硬件相关。稍后，我们将会发现故障转移是什么意思。
在接下来的步骤中，我们必须定义我们这个集群中的节点。这里的思想是，每个节点将有一个和连接字符串相关的数字。一旦这些工作完成了，我们可以调用init cluster。在此步骤中，Slony将部署所有的基础设施进行复制。在这里，我们不必手动安装任何东西。
既然集群已经被初始化，我们可以把我们的表组织成复制集合，其实只是一组表。在Slony中，我们将始终与复制集合工作。表被分组为集合，并复制到一起。这个抽象层允许我们迅速移动表。在许多情况下，这比一个一个地移动单个表要容易的多。
最后，我们必须定义路径。什么是路径？路径基本上就是从A移动到B的连接字符串。这里驻澳的问题是，为什么需要路径。我们已经在前面定义了节点，为什么要定义路径？问题的关键是：从A到B的路径不一定要和从B到A的路径一样。如果这些服务器中的一台服务器在某个DMZ(隔离区)，而另外一台服务器不在，这显得尤其重要。换句话说，通过定义路径，您可以很容易地在两个不同的专用网络之间复制和跨防火墙，如果有必要做些NAT。
由于脚本是一个简单的shell脚本，我们可以很容易地执行它：
hs@hs-VirtualBox:~/slony$ sh slony_first.sh
Slony在后台已经做了一些工作。当看我们的测试表是，我们可以看到发生了什么：
db1=# \d t_test
Table
"public.t_test"
Column | Type |
Modifiers
--------+---------+-----------------------------------------------------
id | integer |
not null default nextval('t_test_id_seq'::regclass)
name | text |
Indexes:
"t_test_pkey"
PRIMARY KEY, btree (id)
Triggers:
_first_cluster_logtrigger
AFTER INSERT OR DELETE
OR UPDATE ON
t_test
FOR EACH ROW EXECUTE PROCEDURE _first_cluster.logtrigger('_first_cluster',
'1', 'k')
_first_cluster_truncatetrigger
BEFORE TRUNCATE ON t_test FOR EACH
STATEMENT EXECUTE
PROCEDURE _first_cluster.log_truncate('1')
Disabled triggers:
_first_cluster_denyaccess
BEFORE INSERT OR DELETE OR UPDATE ON t_test FOR EACH ROW EXECUTE PROCEDURE
_first_cluster.denyaccess('_first_cluster')
_first_cluster_truncatedeny
BEFORE TRUNCATE ON t_test FOR EACH
STATEMENT EXECUTE
PROCEDURE _first_cluster.deny_truncate()
已经自动部署了一些触发器来跟踪这些变化。每个事件都被触发器覆盖。
既然这个表由Slony控制，我们就可以开始复制它了。要做到这一点，我们必须再次写一个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';
subscribe set (
id = 1, provider = 1, receiver = 2, forward = no);
_EOF_
在声明了集群名称和在列表中列出节点之后，我们就可以调用subscirbe set了。这里的关键是，在我们的例子中，设置1数字1是从节点1复制到节点2(接收者)。在这里提到的关键词是重要的。此关键字表示，在复制期间，新的用户是否应该存储日志信息，以使其有可能成为未来的提供者角色的候补节点。任何计划成为一个故障转移的候选节点必须设置 forward =yes。除此之外，要做级联复制(意味着，A复制到B，B复制到C)此关键字是必不可少的。
如果您执行这个脚本，Slony将清空slave上的表，并重新加载所有的数据，以确保事情是同步的。在很多情况下，您已经知道您是同步的，您想避免一次又一次地复制GB的数据。要做到这一点，我们可以添加OMIT COPY = yes。这将告诉Slony，我们有足够的信息，数据已经在同步。
在定义了我们要复制的东西之后，我们就可以用我们最喜欢的UNIX shell启动那两个slon守护进程了。
$ slon first_cluster
'host=localhostdbname=db1'
$ slon first_cluster
'host=localhostdbname=db2'
这也可以在我们定义这个复制过程之前做—所以，在这里顺序不是主要需要关注的。
现在我们可以继续前进，并检查复制是否顺利地工作：
db1=# INSERT INTO t_test (name) VALUES ('anna');
INSERT 0 1
db1=# SELECT * FROM t_test;
id | name
----+------
1 | anna
(1 row)
db1=# \q
hs@hs-VirtualBox:~/slony$ psql db2
psql (9.2.4)
Type "help" for help.
db2=# SELECT * FROM t_test;
id | name
---+------
(0 rows)
db2=# SELECT * FROM t_test;
id | name
--- +------
1 | anna
(1 row)
我们往master中添加了一行数据，迅速断开，并查询数据是否已经存在。如果您碰巧速度够快，您将看到数据出现会有一个小的延迟。在我们的例子中，我们设法得到一个空表只是为了说明异步复制的真正含义。
[让我们假设您正在运行一个书店。您的应用程序连接到服务器A并创建一个新用户。然后，用户将被重定向到一个新的页面，其中查询一些关于新用户的信息—做好那个数据还没有在服务器B上的可能性。在许多web应用负载均衡处理中，这是一中常见的错误。使用异步流复制也会发生同样的延迟。]