Slony-I的限制

限制如下：

http://slony.info/documentation/limitations.html

Slony-I does not automatically replicate 

•Changes to large objects (BLOBS)

•Changes made by DDL commands

•Changes to users and roles

•Changes made by the TRUNCATE command, though this might change in a future version of Slony-I

其原因是：因为trigger自身所限

The main reason for these limitations is that Slony-I collects updates using triggers, and neither schema changes nor large object operations are captured by triggers

对于上面提到的DDL引起的变化，有另外的一种办法：

There is a capability for Slony-I to propagate notably DDL changes if you submit them as scripts via the slonik SLONIK EXECUTE SCRIPT operation. That is not handled "automatically;" you, as a database administrator, will have to construct an SQL DDL script and submit it, via SLONIK EXECUTE SCRIPT.

另外，在构建slony-I环境的时候，需要满足：

The following are recommended for running Slony-I 



•A method of keeping the clocks on your replicas reasonably in sync such as NTP

Also, it is preferable to use an consistent, stable time zone such as UTC or GMT.

Users have run into problems with slon functioning properly when their system uses a time zone that PostgreSQL was unable to recognize such as CUT0 or WST. It is necessary that you use a timezone that PostgreSQL can recognize correctly. It is furthermore preferable to use a time zone where times do not have discontinuities due to Daylight Savings Time. 

•A reliable network between nodes

slon processes should run in the same "network context" as the node that each is responsible for managing so that the connection to that node is a "local" one. Do not run such links across a WAN. Thus, if you have nodes in London and nodes in New York, the slons managing London nodes should run in London, and the slons managing New York nodes should run in New York.

A WAN outage (or flakiness of the WAN in general) can leave database connections "zombied", and typical TCP/IP behaviour will allow those connections to persist, preventing a slon restart for around two hours. 

It is not difficult to remedy this; you need only kill SIGINT the offending backend connection. But by running the slon locally, you will generally not be vulnerable to this condition. 

•All of your databases should be using the same database encoding. (ie LATIN1 or UTF8). Replicating from a database in one encoding to a database with a different encoding might lead to replication errors

另外：

Table中如果没有主key或者没有unique key，是无法进行复制的。

在主数据库和从数据库之间，如果table中使用了oid，那么也是在主table和从table之间，也是难以保持OID一致的。

此外，如果涉及到transactionID，在主库和从库之间，即便从空库开始，也很难保持最新的transactionID一直。