| Slony-I 2.2.10 Documentation | ||||
|---|---|---|---|---|
| Prev | Fast Backward | Chapter 5. Deployment Considerations | Fast Forward | Next |
Minor Slony-I versions can be upgraded using the slonik SLONIK UPDATE FUNCTIONS command. This includes upgrades from 2.2.x to a newer version 2.2.y version or from 2.0.x to 2.1.y.
When upgrading Slony-I, the installation on all nodes in a cluster must be upgraded at once, using the slonik command SLONIK UPDATE FUNCTIONS.
While this requires temporarily stopping replication, it does not forcibly require an outage for applications that submit updates.
The proper upgrade procedure is thus:
Stop the slon processes on all nodes. (e.g. - old version of slon)
Install the new version of slon software on all nodes.
Execute a slonik script containing the command update functions (id = [whatever]); for each node in the cluster.
Note: Remember that your slonik upgrade script like all other slonik scripts must contain the proper preamble commands to function.
Start all slons.
The overall operation is relatively safe: If there is any mismatch between component versions, the slon will refuse to start up, which provides protection against corruption.
You need to be sure that the C library containing SPI trigger functions and the slony SQL files that get installed into the share directory are installed on your database server. The slony version number will be part of these files so they can be installed on your database server before the upgrade and co-exist with the old version of Slony-I
In Slony-I 2.2, we change the layout of tables sl_log_1 and sl_log_2. This does not prevent an in-place upgrade from version 2.1, however it does require that there be no unreplicated data lingering in sl_log_1 and sl_log_2.
If any data remains unconfirmed, then SLONIK UPDATE FUNCTIONS will fail with the message:
cannot upgrade to new sl_log_N format due to existing unreplicated data
A suggested approach is as follows:
Use SLONIK LOCK SET to lock all sets, so that no new changes are being injected into the log tables
Set slon parameter slon_config_cleanup_interval to a very low value (a few seconds) so that the slon cleanup thread will trim data out of sl_log_1 and sl_log_2 immediately
Restart slon for each node and let it run through a cleanup cycle to empty out sl_log_1 and sl_log_2 on all nodes.
Verify that sl_log_1 and sl_log_2 are empty on all nodes in the cluster.
Use SLONIK UPDATE FUNCTIONS against each node to upgrade to version 2.2
Use SLONIK UNLOCK SET to unlock all sets
The format of the slony log tables sl_log_1 and sl_log_2 has changed. The data to be replicated is now stored in an array of of column names and values. It was previously stored as the text that would make up the SQL command.
The syntax of the SLONIK FAILOVER command has changed. If multiple nodes in the cluster have failed, including subscriber-only nodes, then all failed nodes must be passed to the failover command. The rules concerning which nodes can be a failover node have also changed.
Prior to slony 2.2.0 you could use the SLONIK SUBSCRIBE SET command to change a subscribers provider to a different provider for a set. As of Slony-I 2.2.0 the SLONIK SUBSCRIBE SET command can only be used to establish an initial subscription. The SLONIK RESUBSCRIBE NODE command has been introduced to change the provider node.
The SLONIK EXECUTE SCRIPT command no longer accepts SET ID as a valid option.
The format of the .SQL files generated for log shipping has changed. Prior to Slony-I 2.2.0 these files contained SQL INSERT/UPDATE/DELETE statements. They now contain a COPY statement that inserts these changes into a sl_log_archive table. A trigger will then apply these changes on the log shipping target.
The files that get installed on database servers in the $libdir and $sharedir now have the Slony-I version number as part of the file name. For example slony1_funcs.so is now slony1_funcs.2.2.0.so and slony1_funcs.sql is now slony1_funcs.2.2.0.sql
Slonik will now sometimes wait for previously submitted events to be confirmed before submittng additional events. This is described in Section 4.1
In version 2.0 Slony-I could be built with SNMP support. This allowed Slony-I to send SNMP messages. This has been removed in version 2.1
The TABLE ADD KEY slonik command has been removed in version 2.0. This means that all tables must have a set of columns that form a unique key for the table. If you are upgrading from a previous Slony-I version and are using a Slony-I created primary key then you will need to modify your table to have its own primary key before installing Slony-I version 2.0
One of the major changes to Slony-I is that enabling/disabling of triggers and rules now takes place as plain SQL, supported by PostgreSQL 8.3+, rather than via "hacking" on the system catalog.
As a result, Slony-I users should be aware of the PostgreSQL syntax for ALTER TABLE, as that is how they can accomplish what was formerly accomplished via SLONIK STORE TRIGGER and SLONIK DROP TRIGGER.
New in 2.0.5 (but not older versions of 2.0.x) is that SLONIK SUBSCRIBE SET commands are submitted by slonik to the set origin not the provider. This means that you only need to issue SLONIK WAIT FOR EVENT on the set origin to wait for the subscription process to complete.
With version 2.0 the WAIT FOR EVENT slonik command requires that the WAIT ON parameter be specified. Any slonik scripts that were assuming a default value will need to be modified
Slony-I version 2.0 can be upgraded to version 2.1 using the slonik command SLONIK UPDATE FUNCTIONS.
While this requires temporarily stopping replication, it does not forcibly require an outage for applications that submit updates.
The proper upgrade procedure is thus:
Stop the slon processes on all nodes. (e.g. - old version of slon)
Install the new version of Slony-I; software on all nodes (including new versions of the shared functions and libraries) .
Execute a slonik script containing the command update functions (id = [whatever]); for each node in the cluster. This will alter the structure of some of the Slony-I configuration tables.
Note: Remember that your slonik upgrade script like all other slonik scripts must contain the proper preamble commands to function.
Start all slons.
The version 2 branch is substantially different from earlier releases, dropping support for versions of PostgreSQL prior to 8.3, as in version 8.3, support for a "session replication role" was added, thereby eliminating the need for system catalog hacks as well as the not-entirely-well-supported xxid data type.
As a result of the replacement of the xxid type with a (native-to-8.3) PostgreSQL transaction XID type, the slonik command SLONIK UPDATE FUNCTIONS is quite inadequate to the process of upgrading earlier versions of Slony-I to version 2.
In version 2.0.2, we have added a new option to SLONIK SUBSCRIBE SET, OMIT COPY, which allows taking an alternative approach to upgrade which amounts to:
Uninstall old version of Slony-I
When Slony-I uninstalls itself, catalog corruptions are fixed back up.
Install Slony-I version 2
Resubscribe, with OMIT COPY
| Warning |
There is a large "foot gun" here: during part of the process, Slony-I is not installed in any form, and if an application updates one or another of the databases, the resubscription, omitting copying data, will be left with data out of sync. The administrator must take care; Slony-I has no way to help ensure the integrity of the data during this process. |
The following process is suggested to help make the upgrade process as safe as possible, given the above risks.
Use Section 6.1.11 to generate a slonik script to recreate the replication cluster.
Be sure to verify the SLONIK ADMIN CONNINFO statements, as the values are pulled are drawn from the PATH configuration, which may not necessarily be suitable for running slonik.
This step may be done before the application outage.
Determine what triggers have SLONIK STORE TRIGGER configuration on subscriber nodes.
Trigger handling has fundamentally changed between Slony-I 1.2 and 2.0.
Generally speaking, what needs to happen is to query sl_table on each node, and, for any triggers found in sl_table, it is likely to be appropriate to set up a script indicating either ENABLE REPLICA TRIGGER or ENABLE ALWAYS TRIGGER for these triggers.
This step may be done before the application outage.
Begin an application outage during which updates should no longer be applied to the database.
To ensure that applications cease to make changes, it would be appropriate to lock them out via modifications to pg_hba.conf
Ensure replication is entirely caught up, via examination of the sl_status view, and any application data that may seem appropriate.
Shut down slon processes.
Uninstall the old version of Slony-I from the database.
This involves running a slonik script that runs SLONIK UNINSTALL NODE against each node in the cluster.
Ensure new Slony-I binaries are in place.
A convenient way to handle this is to have old and new in different directories alongside two PostgreSQL builds, stop the postmaster, repoint to the new directory, and restart the postmaster.
Run the script that reconfigures replication as generated earlier.
This script should probably be split into two portions to be run separately:
Firstly, set up nodes, paths, sets, and such
At this point, start up slon processes
Then, run the portion which runs SLONIK SUBSCRIBE SET
Splitting the Section 6.1.11 script as described above is left as an exercise for the reader.
If there were triggers that needed to be activated on subscriber nodes, this is the time to activate them.
At this point, the cluster should be back up and running, ready to be reconfigured so that applications may access it again.