Slony-I is a "master to multiple slaves" replication system supporting cascading (e.g. - a node can feed another node which feeds another node...) and failover.
The big picture for the development of Slony-I is that it is a master-slave replication system that includes all features and capabilities needed to replicate large databases to a reasonably limited number of slave systems.
Slony-I is a system designed for use at data centers and backup sites, where the normal mode of operation is that all nodes are available.
A fairly extensive "admin guide" comprising material in the CVS tree may be found here. There is also a local copy.
The original design document is available here.
See the "news" area for more details, including a copy of the release notes. This version fixes quite a number of issues found in early use of version 2.0.
See the "news" area for more details, including a copy of the release notes. This version fixes issues relating to FAILOVER.
See the "news" area for more details, including a copy of the release notes. This version fixes quite a number of issues found in early use of version 2.0.0.
See the "news" area for more details, including a copy of the release notes.
This is a major new release of Slony-I; it makes use of some features introduced in PostgreSQL 8.3, and hence is not compatible with versions older than 8.3.
This is considered a pretty good tradeoff, as various functionality would not be possible with earlier versions of PostgreSQL.
Unfortunately, it needs to be noted that there is not, as of yet, an upgrade procedure to upgrade an installation of Slony-I 1.2.x to 2.0. At present, upgrading to 2.0 will essentially require dropping out replication and recreating it.
We hope to have an answer as to how to deal with this in the new year.
Follow Bug #69 for more details on this.
Version 1.2.15 is now available. See the "news" area for more details, including a copy of the release notes.
Changes since 2.0.1 are as follows:
This would cause REPAIR CONFIG to fail.
Put in a query that updates the oids in sl_table and sl_sequence to randomly selected values from pg_class that couldn't match (since the values selected are from non-table/non-sequence objects)
This would cause REPAIR CONFIG to fail.
Put in a query that updates the oids in sl_table and sl_sequence to randomly selected values from pg_class that couldn't match (since the values selected are from non-table/non-sequence objects)
Licence: BSD
Principle:
Once replication nodes and relations between nodes have been defined, one can easily administrate the replication by calling one of the scripts, without need to write slonik scripts anymore. Features:
This release addresses a number of issues found in 2.0.0
This would cause UPGRADE FUNCTIONS to fail.
If you had multiple clusters where one cluster name was a substring of the other, slon-tools.pm could find both when looking for slon processes relevant to the shorter cluster name. Added a space to the relevant bit of slon-tools.pm
Unfortunately, it needs to be noted that there is not, as of yet, an upgrade procedure to upgrade an installation of Slony-I 1.2.x to 2.0. At present, upgrading to 2.0 will essentially require dropping out replication and recreating it.
We hope to have an answer as to how to deal with this in the new year.
This is required because we now make use of new functionality in Postgres, namely the trigger and rule support for session replication role. As of now, every node (origin/subscriber/mixed) can be dumped with pg_dump and result in a consistent snapshot of the database.
This fairly massively simplifies the C code.
Bill Moran ran into some problems with such dates; varying PostgreSQL versions returned somewhat varying results. This wasn't a Slony-I problem; the data was indeed being replicated correctly.
Warn upon creating a long cluster name.
Give a useful exception that explains the cause rather than merely watching index creation fail.
The problem is that some/most/sometimes all triggers and rules are likely to need to be dropped from the log shipping node lest they interfere with replication.
PostgreSQL 8.3 introduces a set of "txid" functions and a "txid_snapshot" type, which eliminates the need for Slony-I to have its own C functions for doing XID comparisons.
Note that this affects the structure of sl_event, and leads to some changes in the coding of the regression tests.
This eliminates the src/xxid directory and contents
Interesting side-effect: You can now induce a cleanup manually, which will be useful for testing.
interval - cleanup_interval (default '10 minutes')
This controls how quickly old events are trimmed out. It used to be a hard-coded value.
Old events are trimmed out once the confirmations are aged by (cleanup_interval).
This then controls when the data in sl_log_1/sl_log_2 can be dropped.
Data in *those* tables is deleted when it is older than the earliest XID still captured in sl_event.
boolean - cleanup_deletelogs (default 'false')
This controls whether or not we DELETE data from sl_log_1/sl_log_2
By default, we now NEVER delete data from the log tables; we instead use TRUNCATE.
If the call to logswitch_finish() indicates that there was no log switch in progress, we initiate one.
This means that log switches will be initiated almost as often as possible. That's a policy well worth debating :-).
It uses the same logic as in cleanupEvent() to determine if there are any *relevant* tuples left in sl_log_[whatever], rather than (potentially) scanning the table to see if there are any undeleted tuples left.
Slonik scripts may need to be changed to indicate an EVENT NODE (or similar) after migration to v2.0 as a result.
The slonik commands involved:
Add a test to "test1" to make sure this logic gets exercised.
Integrated this into the regression tests, replacing previous logic for starting/stopping slons, so that this script can be considered carefully tested
We will eventually be replacing these with a more proper "test suite" so we're not remedying all the ducttape tests.
- store trigger was running against all nodes upon subscription