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

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应用负载均衡处理中，这是一中常见的错误。使用异步流复制也会发生同样的延迟。]