Christopher B. Browne's Home Page
cbbrowne@acm.org

Chapter 4. Advanced Topics

Table of Contents
4.1. Events & Confirmations
4.2. Slony-I Listen Paths
4.3. Monitoring
4.4. Log Shipping - Slony-I with Files
4.5. Partitioning Support
4.6. Slony-I Upgrade
4.7. Log Analysis
4.8. Performance Considerations
4.9. Slony-I Trigger Handling
4.10. Locking Issues
4.11. Security Considerations

4.1. Events & Confirmations

Slony-I transfers configuration changes and application data through events. Events in Slony-I have an origin, a type and some parameters. When an event is created it is inserted into the event queue (the sl_event table) on the node the event originates on. The remoteListener threads of slon processes then pick up that event (by quering the sl_event table) and passing the event to the slons remoteWorker thread for processing.

An event is uniquely identified by taking both the node id of the node the event originates on and the event sequence number for that node. For example (1,5000001) identifies event 5000001 originating from node 1. While (3,5000001) identifies a different event that originated on a different node.

4.1.1. SYNC Events

SYNC events are used to transfer application data for one node to the next. When data in a replicated table changes a trigger fires that records information about the change in the sl_log_1 or sl_log_2 tables. The localListener thread in the slon processes will then periodically generate a SYNC event. When the SYNC event is created Slony-I will find the heighest log_seqid assigned so far along with a list of log_seqid's that were assigned to transactions that have not yet been committed. This information is stored as part of the SYNC event.

When a slon processes remoteWorker processes a SYNC it will query the rows from sl_log_1 and sl_log2 that are covered by the SYNC (log_seqid rows that had been committed at the time the SYNC was generated). The modifications described by these rows are then made on the subscriber.

4.1.2. Event Confirmations

When an event is processed by the slon for a remote node a CONFIRM message is generated by inserting a row into the sl_confirm table. This row indicates that a particular event was confirmed by a particular receiver node. Confirmation messages are the transfered back to all other nodes in the cluster.

4.1.3. Event cleanup

The slon cleanupThread will periodically run the cleanupevent(p_interval interval) database function that will delete all but the most recently confirmed event for each origin/receiver pair (because if an event has been confirmed by a receiver then all older events from that origin have also been confirmed by the receiver). Then the function will delete any SYNC events that are older than the oldest row left in sl_confirm (for each origin). The data for these deleted events will also be removed from the sl_log_1 and sl_log_2 tables.

When Slony-I is first enabled it will log the data to replicate to the sl_log_1 table. After a while it will stop logging to sl_log_1 and switch to logging on sl_log_2. When all of rows in in sl_log_1 have been replicated Slony-I will TRUNCATE the sl_log_1 table (to clear out the dead tuples), stop logging to sl_log_2 and switch back to logging to the newly truncated sl_log_1 table. This process will be periodically repeated as Slony-I runs.

Google

If this was useful, let others know by an Affero rating

Contact me at cbbrowne@acm.org