| Slony-I 2.0.8 Documentation | ||||
|---|---|---|---|---|
| Prev | Fast Backward | Fast Forward | Next | |
Chapter 4. Advanced Topics
- Table of Contents
- 4.1. Events & Confirmations
- 4.1.1. SYNC Events
- 4.1.2. Event Confirmations
- 4.1.3. Event cleanup
- 4.2. Slony-I Listen Paths
- 4.3. Monitoring
- 4.3.1. test_slony_state
- 4.3.2. Nagios Replication Checks
- 4.3.3. Monitoring Slony-I using MRTG
- 4.3.4. Bucardo-related Monitoring
- 4.3.5. search-logs.sh
- 4.3.6. Building MediaWiki Cluster Summary
- 4.3.7. Analysis of a SYNC
- 4.4. Log Shipping - Slony-I with Files
- 4.4.1. Usage Hints
- 4.4.2. find-triggers-to-deactivate.sh
- 4.4.3. slony_logshipper Tool
- 4.5. Partitioning Support
- 4.6. Slony-I Upgrade
- 4.7. Log Analysis
- 4.7.1. CONFIG notices
- 4.7.2. INFO notices
- 4.7.3. DEBUG Notices
- 4.7.4. Thread name
- 4.7.5. How to read Slony-I logs
- 4.7.6. Log Messages and Implications
- 4.8. Performance Considerations
- 4.8.1. Vacuum Concerns
- 4.8.2. Log Switching
- 4.8.3. Long Running Transactions
- 4.9. Slony-I Trigger Handling
- 4.10. Locking Issues
- 4.11. Security Considerations
- 4.11.1. Minimum Privileges
- 4.11.2. Lowering Authority Usage from Superuser
- 4.11.3. Other Good Security Practices
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 querying 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 schemadoccleanupevent(interval, boolean) 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 of rotating between the two log tables is periodically repeated as Slony-I runs.