O'Reilly Databases

oreilly.comSafari Books Online.Conferences.

We've expanded our coverage and improved our search! Search for all things Database across O'Reilly!

Search Search Tips

advertisement
AddThis Social Bookmark Button

Listen Print Discuss Subscribe to Databases Subscribe to Newsletters

Modifying Slony Clusters

by A. Elein Mustain
03/17/2005

Slony logo

Replication clusters have much forethought applied to their creation. However, in the course of systems development, some changes are always necessary sooner or later. This article walks through the steps required to:

  • Add a node to the cluster.
  • Switch data providers of a table set.
  • Promote a replication to master.
  • Apply schema changes to the replication cluster.

These examples will use the replication scheme originally set up in "Introducing Slony."

Figure 1
Figure 1.

Adding a Node

Suppose that in addition to the replica you created for the gb database, you want another replica of the same database for reporting. Here's how to add a replica of the gb table set on a second database in the 8.0 installation. The 7.4 Node 1, database gb, will originate the data set and replicate it directly to Node 2, also database gb, and Node 3, database gb2.

Figure 2
Figure 2.

Before starting, be sure to create gb2 in the 8.0 installation, seeding it with the same empty schema as the other two databases in this cluster. You do not want a dump of the schema of gb as is it now, but rather as it was before you defined the Slony-I cluster.

Next, define Node 3 and ensure there are paths from Node 3 to and from Nodes 1 and 2. From there, enable listening along each path mirroring the expected table set replication. The listening of 2 and 3 via Node 1 reflects this mirroring, rather than having a direct listen path between 2 and 3.

This is a really good time to remember that the connection information in the store path command pertains to the server node. This is also a pretty good time to look up drop path and drop listen, two more slonik commands.

#!/bin/sh
slonik << _END_
#
# Define cluster namespace and node connection information
#
cluster name = gbcluster;
node 1 admin conninfo = 'dbname=gb host=localhost port=5434 user=postgres';
node 2 admin conninfo = 'dbname=gb host=localhost port=5430 user=postgres';
node 3 admin conninfo = 'dbname=gb2 host=localhost port=5430 user=postgres';
echo 'Cluster defined, nodes identified';

#
# Initialize the cluster and create the second node
#
store node (id=3, comment='gb2 8.0 5430');

#
# create paths
#
store path (server=1, client=3, conninfo='dbname=gb host=localhost 
     port=5434 user=postgres');
store path (server=2, client=3, conninfo='dbname=gb host=localhost 
     port=5430 user=postgres');
store path (server=3, client=1, conninfo='dbname=gb2 host=localhost 
     port=5430 user=postgres');
store path (server=3, client=2, conninfo='dbname=gb2 host=localhost 
     port=5430 user=postgres');

#
# Enable listening along each path
#
store listen (origin=1, receiver=3, provider=1);
store listen (origin=3, receiver=1, provider=3);
store listen (origin=2, receiver=3, provider=1);
store listen (origin=3, receiver=2, provider=1);

_END_

Now you are ready to start a new slon process for Node 3, the 8.0 installation with the gb2 database. Because there are two replica databases on the 8.0 installation:

#! /bin/bash
#
# varlena Slony Start Up
# ==============================
slon gb "dbname=gb2 host=localhost port=5430 user=postgres" > slon_gb_3.out 2>&1 &

Once the new slon process is up and running, you can subscribe Table Set 1, originating at Node 1, to Node 3. At this point the log files are invaluable; tail -f the log files to watch for progress and errors. The log files in this case are slon_gb_1.out, slon_gb_2.out, and slon_gb_3.out. If you see any problems, you may have to remove the paths and/or listens, replacing them with corrected ones.

The log file slon_gb_1.out looks like:

CONFIG main: slon version 1.0.5 starting up
CONFIG main: local node id = 1
CONFIG main: loading current cluster configuration
CONFIG storeNode: no_id=2 no_comment='Node 2 dbname=gb host=localhost 
     port=5430 user=postgres'
CONFIG storePath: pa_server=2 pa_client=1 pa_conninfo="dbname=gb host=localhost 
     port=5430 user=postgres" pa_connretry=10
CONFIG storeListen: li_origin=2 li_receiver=1 li_provider=2
CONFIG main: configuration complete - starting threads
CONFIG enableNode: no_id=2
CONFIG storeSet: set_id=1 set_origin=1 set_comment=''
CONFIG storeNode: no_id=3 no_comment='gb2 8.0 5430'
CONFIG enableNode: no_id=3
CONFIG storePath: pa_server=3 pa_client=1 pa_conninfo="dbname=gb2 host=localhost 
     port=5430 user=postgres" pa_connretry=10
CONFIG storeListen: li_origin=3 li_receiver=1 li_provider=3

The one for Node 2, slon_gb_2.out, looks very similar except the paths and listens are appropriate for Node 2.

Now subscribe Node 3 to the table set.

#!/bin/sh
slonik << _END_
#
# Define cluster namespace and node connection information
#
cluster name = gbcluster;
node 1 admin conninfo = 'dbname=gb host=localhost port=5434 user=postgres';
node 2 admin conninfo = 'dbname=gb host=localhost port=5430 user=postgres';
node 3 admin conninfo = 'dbname=gb2 host=localhost port=5430 user=postgres';

subscribe set (id=1, provider=1, receiver=3, forward=yes);
echo 'set 1 of gb tables subscribed by node 3';

_END_

Verification of data is reassuring at this point.

Pages: 1, 2

Next Pagearrow




Tagged Articles

Post to del.icio.us

This article has been tagged:

replication

Articles that share the tag replication:

Advanced MySQL Replication Techniques (80 tags)

Live Backups of MySQL Using Replication (42 tags)

Building and Configuring Slony (4 tags)

Introducing Slony (4 tags)

Modifying Slony Clusters (3 tags)

View All

postgres

Articles that share the tag postgres:

Writing PostgreSQL Functions with PL/pgSQL (8 tags)

Introducing Slony (5 tags)

Automating PostgreSQL Tasks (4 tags)

Modifying Slony Clusters (3 tags)

Managing Many-to-Many Relationships with PL/pgSQL (3 tags)

View All

postgresql

Articles that share the tag postgresql:

Managing Many-to-Many Relationships with PL/pgSQL (17 tags)

Writing PostgreSQL Functions with PL/pgSQL (11 tags)

Datamining Apache Logs with PostgreSQL (8 tags)

Introducing Slony (8 tags)

Batch Updates with PL/pgSQL (8 tags)

View All

database

Articles that share the tag database:

MySQL FULLTEXT Searching (54 tags)

Live Backups of MySQL Using Replication (53 tags)

Advanced MySQL Replication Techniques (53 tags)

Dreaming of an Atom Store: A Database for the Web (49 tags)

How to Misuse SQL's FROM Clause (38 tags)

View All

Sponsored Resources

  • Inside Lightroom

Related to this Article

Understanding Oracle Clinical Understanding Oracle Clinical
by Joan M. Johnson
May 2007
$9.99 USD

Inside SQLite Inside SQLite
by Sibsankar Haldar
April 2007
$9.99 USD

Advertisement
O'Reilly Media

©2009, O'Reilly Media, Inc.
(707) 827-7000 / (800) 998-9938
All trademarks and registered trademarks appearing on oreilly.com are the property of their respective owners.
About O'Reilly
Academic Solutions
Authors
Contacts
Customer Service
Jobs
Newsletters
O'Reilly Labs
Press Room
Privacy Policy
RSS Feeds
Terms of Service
User Groups
Writing for O'Reilly
Content Archive
Business Technology
Computer Technology
Google
Microsoft
Mobile
Network
Operating System
Digital Photography
Programming
Software
Web
Web Design
More O'Reilly Sites
O'Reilly Radar
Ignite
Tools of Change for Publishing
Digital Media
Inside iPhone
O'Reilly FYI
makezine.com
craftzine.com
hackszine.com
perl.com
xml.com

Partner Sites
InsideRIA
java.net
O'Reilly Insights on Forbes.com