• Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
3,700
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
95
Comments
0
Likes
3

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Replicating PostgreSQL Databases Using Slony-I Christopher Browne Afilias Canada An introduction to the use of Slony-I, an asynchronous single-master to multiple slaves replication system for use with PostgreSQL
  • 2. What is Slony-I? Slony-I is an asynchronous single master to multiple slave replication system for PostgreSQL supporting multiple database releases, cascaded replication, and slave promotion.
  • 3. What is Slony-I? Slony-I is a replication system for PostgreSQL Replication: Updates applied to one database are applied to another database INSERT, DELETE, UPDATE Some replication systems intercept transaction logs; Slony-I uses triggers on tables to collect changes
  • 4. Why Replicate? ● Redundancy – allowing rapid recovery from some hardware failures ● Separate reporting from on-line activity: Performance ● Separate reporting from on-line system: Security
  • 5. What is Slony-I? Slony-I is an asynchronous replication system Asynchronous: Updates are COMMITted to one database, and are applied to others later (possibly much later) Contrast with synchronous, where updates must commit on multiple hosts at the same time
  • 6. What is Slony-I? Slony-I is an asynchronous single master to multiple slave replication system Updates are applied at the origin, and are replicated to a set of subscribers Slony-I allows each table to have a different origin – but only one origin! Alternative: multimaster – more complex, heavy locking costs and/or conflict resolution problems
  • 7. What is Slony-I? Slony-I supports multiple PostgreSQL releases Supports PostgreSQL versions 7.3.3 and higher Earlier versions not supported – no namespaces
  • 8. Preparing version upgrade ● Prepare upgrade... Master Slave S 7.3.9 Replicate 8.0.3 Slony-I may take 48h to populate the replica, but that requires no outage on the master system
  • 9. Database version upgrade (2) ● Once “in sync,” MOVE SET takes seconds Slave Master S 7.3.9 move set 8.0.3 The former master can become slave; this provides a fall back strategy “Just in Case”
  • 10. What is Slony-I? Slony-I supports cascaded replication NYC Data Center LA Data Center NY1 NY2 WAN Master LA1 LA2 Several LA servers feeding from just LA3 one source
  • 11. What is Slony-I? Slony-I supports slave promotion NYC Data Center LA Data Center NY1 NY2 LA1 LA2 Master MOVE SET shifts origin to LA LA3
  • 12. Uses for Slave Promotion ● Upgrades: Set up subscriber running new PG version, then promote it to “master” ● Maintenance: Shift origin to a new server allowing extended maintenance ● Avoid failure: Shift origin from a failing server to one that is “less ailing.”
  • 13. Fail Over ● For extreme cases of problems with master, Slony-I supports full scale fail- over ● Since Slony-I is asynchronous, some transactions committed on the master won't have made it to other nodes ● As a result, FAIL OVER must lead to dropping the failed node
  • 14. Slony-I Components ● Databases – one for each node ● Slon daemon – one for each node ● Slonik – configuration controller ● Virtual: Network configuration
  • 15. Components: Databases Each node is a PostgreSQL database with: ● C libraries to implement trigger functions ● pl/pgsql functions for non-time-critical code ● Database namespace/schema for configuration ● On origin nodes – triggers to capture updates ● On subscriber nodes – triggers to protect data ● Slony-I processes connect as a superuser, e.g. slony
  • 16. Components: slon daemons Each node has a slon instance. This is a C program that propagates events between nodes ● Most event types are for configuring Slony-I ● SYNC events are where data “providers” tell subscribers that they have new data to replicate
  • 17. Components: slonik The slonik command processor takes configuration scripts in an SQL-like language and submits them to the cluster ● STORE NODE, STORE PATH, STORE LISTEN ● CREATE SET, SET (ADD|DROP|MOVE) TABLE, SET (ADD| DROP|MOVE) SEQUENCE ● SUBSCRIBE SET, LOCK SET, MOVE SET, FAIL OVER, EXECUTE SCRIPT Slonik is only used when modifying configuration; when system is stable, it remains unused
  • 18. Components: Network Configuration ● Configuration paths from “admin workstation” to all nodes – connections may be temporary and/or slow but must be comprehensive ● Communications paths between slon daemons and Slony-I nodes – need to be fast and reliable; create only the links you need
  • 19. Administrative Connections ● slonik needs to communicate with every node
  • 20. Replication Connections ● Persistent, reliable, fast 2-way connections between some nodes Redundancy wanted!
  • 21. Configuration Terminology ● Cluster – the set of databases ● Node – each database in the cluster ● Replication set – a set of tables and sequences replicated from a single origin ● Origin, subscribers, providers – the shape of the replication “network” ● Paths – routes slon uses to talk to DBs ● Listen paths – determine path usage
  • 22. Cluster A Slony-I cluster is the set of database instances where replication takes place. Give the thing being replicated a name: ● ORG, Payroll, PriceDB, STorm The name identifies the schema used to store Slony-I data, thus _ORG, _Payroll, _PriceDB, ... Slonik scripts specify: cluster name=ORG; Slon daemons are passed the cluster name: slon -d4 -g80 STorm 'host=db1 db=nws_storm'
  • 23. Node Each PostgreSQL database being used for replication is a Slony-I “node” Each has a schema containing Slony-I-specific tables, sequences, functions Cluster T1 has the following tables: _T1.sl_config_lock _T1.sl_confirm _T1.sl_event _T1.sl_listen _T1.sl_log_1 _T1.sl_log_2 _T1.sl_log_status _T1.sl_node _T1.sl_path _T1.sl_seqlastvalue _T1.sl_seqlog _T1.sl_sequence _T1.sl_set _T1.sl_setsync _T1.sl_status _T1.sl_subscribe _T1.sl_table _T1.sl_trigger Slonik commands: store node, drop node, uninstall node
  • 24. Replication Sets ● Replication sets are the “container” for each set of tables and sequences being replicated ● Each set's data originates on one node and is published to other nodes ● By having multiple sets with multiple origins, you can get a sort of multimaster replication Slonik commands: create set, drop set, subscribe set, merge set, set add table, set add sequence, ...
  • 25. Weak Form of Multimaster Replication ● DB1 is origin for table tab1 in set 1 ● DB2 is origin for table tab2 in set 2 ● DB3 is origin for table tab3 in set 3 tab1 tab2 DB1 tab2 DB2 tab3 DB3 tab3 Three replication sets can have different propagation networks
  • 26. Origin, Provider, Subscriber The terms “master” and “slave” become inaccurate if there are more than 2 nodes Nodes are not themselves either master or slave For each replication set, and hence for each table, there is exactly one “origin” All the other nodes can be “subscribers” Each subscriber draws data from a “provider” which may either be the origin, or a subscriber downstream from the origin.
  • 27. Admin Paths ● One variety of “communications path” is the one used by slonik from “admin server” to all nodes ● These are encoded in a preamble to each slonik script ● There needs to be one 'admin conninfo' path to each Slony-I node ● These are used sporadically, just to do configuration, so they could be temporary (e.g. - SSH tunnels)
  • 28. Paths Between Nodes ● The store path command stores the paths used so the slon for node X knows how to access the database for node Y ● If there are n nodes, there could be as many as n(n-1) paths in sl_path; no less than 2n ● Multiple sites with complex firewall policies may mean nonuniform communications paths ● But there still must be some form of 2-way communications between sites
  • 29. Complex Path Scenario network #1 network #2 db db db db 1 2 4 5 db db Tightly interconnected 3 6 in network #2 Tightly interconnected in network #1 But between the networks, only db2 and db4 talk to one another
  • 30. Security Considerations ● slonik and slon must connect as PostgreSQL superuser because they do DB alterations ● In practice, events propagate so any action could come from anywhere ● Connection issues and mechanisms are the same as for any software using libpq ● Slony-I doesn't mess around with users or roles; you manage security your way
  • 31. .pgpass for Password Storage Use .pgpass for storing passwords ● Removes passwords from command lines ● Removes passwords from environment variables ● Removes passwords from sl_path All of those are vulnerable to capture
  • 32. SSH Connections Consider using ssh connections across untrusted networks ● Slony-I opens connections infrequently – costs are amortized over much usage ● Presently, PostgreSQL has decent support for server certificates but client certificates not usable for authentication ● Use of client certificates for authentication would provide a more “opaque” token than .pgpass – future PostgreSQL enhancement
  • 33. Slony-I User Use of “slony” PG user to run Slony-I processes is highly recommended ● Makes replication connections highly identifiable ● Makes it easy to lock out all but the slony user when running COPY_SET ● Separating maintenance roles to multiple users (molly, dumpy, slony) has proven useful.
  • 34. Security – Log Shipping ● Conventional nodes require 2-way communications between participating servers ● Log shipping allows serializing updates to files ● Transmit (1-way!) via FTP, scp, rsync, DVD-ROM, USB Key, RFC 1149, 2549
  • 35. Sometimes Slony-I isn't the Answer ● If you truly, honest to goodness, need multimaster, watch for Slony-II... ● If you need DDL to be handled automagically, look at PG 8.0 PITR ● If you have a loosely run environment, Slony-I will not go well ● No answer yet for async multimaster!
  • 36. More Cases Not to Use Slony-I ● Slony-I needs to define a node (and spawn a slon + connections) for each database – replicating 80 databases on one cluster may not turn out ● If you have 300 sequences, all 300 are propagated with each sync – this may not turn out well
  • 37. Summary ● What is Slony-I and what does it do? ● What are the components of Slony-I? ● What are some security issues surrounding the use of Slony-I?