10.2 理解 Slony如何工作
在我们开始复制我们的第一个数据库之前，我们想深入Slony的架构。理解这是如何工作的是非常重要的，否则，将不可能以一种有用的和合理的方法使用这个软件。与事务日志流不同，Slony使用逻辑复制。这意味着它不使用内部二进制数据(比如XLOG),但逻辑数据(在Slony的情况下，这是文本)代替。使用文本数据代替内置的事务日志有一定的优势，但也有些缺点，这将在本章中详细讨论。
10.2.1 处理逻辑复制
首先，我们要讨论的是，逻辑复制的真正含义：每个Slony设置的基础是所谓的更改日志触发器。这意味着只要Slony复制一个表的内容，它将创建一个触发器。然后，这个触发器将存储对表的所有改变到一个日志中。一个被称为slon的进程将检查此更改日志，并把这些更改复制到消费者。让我们可以下基本的算法：
INSERT INTO table (name, tstamp) VALUES ('hans', now());
trigger fires
('hans', '2013-05-08 13:26:02') as well as some bookkeeping
information will be stored in the log table
COMMIT
一段时间以后：
• slon 守护进程将会到来并读取自从上一次提交以后的所有改变。
• 所有的改变都将在slave上重放。
• 一旦做到这一点，日志就可以被删除了。
下图显示了Slony的整体架构：
请记住，传输协议是纯文本。这里主要的优点是，没有必要在集群中所有的节点上运行相同版本的PostgreSQL，因为Slony将抽象版本号。通过事务日志传送，我们不能做到这一点；因为在基于XLOG 复制的集群中的所有节点必须使用相同主版本号的PostgreSQL。
[更改日志是为特定的表而写的—这也意味着我们不必同时复制所有这些表；复制一个节点上那些表的一个子集是可能的。]
因为Slony是独立于PostgreSQL的版本，它可以很好地用于升级的目的。
10.2.2 slon 守护进程
正如我们已经指出的那样，slon守护进程将负责制成的特殊表的改变或者一组表并传送这些变化到所需的目的地。
为了使这工作，我们必须在我们的集群中的每个数据库都运行一个slon守护进程。
[请注意，我们所讨论的每个数据库一个slon守护进程—不是每个实例。当实际设置时，这是要考虑的重要事情。]
由于每个数据库都会有自己的slon守护进程，这些进程将相互通信以交换和调度数据。独立的slon守护进程也可以有中继功能和简单的数据传送功能。如果您想通过B数据库从A数据库复制数据到C数据库，这是很重要的。这个思想和您可以用流复制和级联复制实现的功能相似。
关于Slony的一件重要的事情是，没有必要复制整个实例或者整个数据库—复制总是和一个表或 一组表相关。尽可能多的数据库期望作为slave为这组特定的表提供服务时，一个数据库将作为master服务为每个表(或对于每一组表)。
可能会发生这种情况：一个数据库是表A与表B的master，另一个数据库将是表C与表D的数据库。换句话说，Slony允许数据来回复制。哪个数据从哪里流向何处将由slon守护进程管理。
slon 守护进程本身由多个服务于不同目的的线程组成，例如清理，时间监听，或者服务器上的应用改变。除此之外，它将会执行同步相关的任务。
要与slon守护进程进行交互，您可以使用一个叫做slonik的命令行工具。它将能够解释脚本并与直接与Slony进行对话。