Using VIEW

Changing the Cluster Topology (Re mastering and Failover)

Slony makes it very easy to change the topology of a replication cluster. Let's say that business at the Boomtown store is really booming (ouch) and you want to lighten the load on the boomtown server. boomtown pulls replication data from springfield and forwards the data to snoozeville. You can tell snoozeville to pull its replication data directly from springfield by re-subscribing snoozeville and specifying a different provider (see Listing 24.9).

Listing 24.9.


# File:
include ;

subscribe set ( id = 1, provider = @SPRINGFIELD, 
 receiver = @SNOOZEVILLE, forward = no );

That's nearly identical to the previous subscribe set command; the only difference is that you've changed the provider from @BOOMTOWN to @SPRINGFIELD.

You can also change the origin of a replication seta process known as re-mastering. To move a replication set from its current origin to a different node, you execute two slonik commands:

lock set ( id = set-id, origin = current-origin );
move set ( id = set-id, old origin = current-origin, new origin = target-origin );

When the move set command completes, Slony reverses the roles between the old origin (which is now a subscriber) and the new origin (which was formerly a subscriber). The old origin remains a member of the replication set, but it's just another subscriber now.

You can only re-master via the move set command if the origin node is healthy. If the origin has experienced a catastrophic failure, you can force another node to assume ownership of the replication set with the failover command. The failover command moves the replication set to a new origin just like the move set command, but it also invalidates the failed node. (Remove the failed node from the cluster with a drop node command once the failover command completes.) The syntax for the failover command is

failover ( id = failed-node, backup node = replacement-node );

The failover command replaces an entire node, not a single set. If the failed node originated more than one set, they're all re-mastered to the replacement node. If the failed node acted as a forwarding provider, failover moves all subscribers to the replacement node. If the failed node was a simple (non-forwarding) subscriber, the failover command doesn't do much of anything.

Part I: General PostgreSQL Use

Introduction to PostgreSQL and SQL

Working with Data in PostgreSQL

PostgreSQL SQL Syntax and Use


Part II: Programming with PostgreSQL

Introduction to PostgreSQL Programming

Extending PostgreSQL


The PostgreSQL C APIlibpq

A Simpler C APIlibpgeasy

The New PostgreSQL C++ APIlibpqxx

Embedding SQL Commands in C Programsecpg

Using PostgreSQL from an ODBC Client Application

Using PostgreSQL from a Java Client Application

Using PostgreSQL with Perl

Using PostgreSQL with PHP

Using PostgreSQL with Tcl and Tcl/Tk

Using PostgreSQL with Python

Npgsql: The .NET Data Provider

Other Useful Programming Tools

Part III: PostgreSQL Administration

Introduction to PostgreSQL Administration

PostgreSQL Administration

Internationalization and Localization


Replicating PostgreSQL Data with Slony

Contributed Modules


PostgreSQL(c) The comprehensive guide to building, programming, and administering PostgreSQL databases
PostgreSQL(c) The comprehensive guide to building, programming, and administering PostgreSQL databases
ISBN: 735712573
Year: 2004
Pages: 261 © 2008-2020.
If you may any questions please contact us: