Slony-I makes progress

From: Jan Wieck <JanWieck(at)Yahoo(dot)com>
To: PostgreSQL General <pgsql-general(at)postgresql(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Slony-I makes progress
Date: 2004-03-03 21:57:28
Message-ID: 404654C8.1030705@Yahoo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

After some substantial progress on the Slony-I engine development, I'd
like to give a little status report and invite everyone who wants to
participate in this project to join the mailing list and the development
team.

The project homepage is here:

http://gborg.postgresql.org/project/slony1/projdisplay.php

====================================================================

The current development status:

Slony-I configures on RedHat Linux and FreeBSD 4.9 against a PostgreSQL
7.4. The engine is capable of hot install, hot subscribe with catch up
and cascaded slaves. The config utilities are either not existent yet or
ugly, incomplete shell scripts. The replication log trigger is the
pototypes version in PL/Tcl.

What this odd collection is capable of doing is creating a master, slave
and cascaded slave replication system with a pgbench database as master.
The kick is, that the master database is originally just a plain, stock
PG 7.4.1 with zero changes, and the pgbench application is running non
stop through the whole process.

====================================================================

Next steps:

The log trigger function must be reimplemented in C. I will do this
during the next couple of days.

Implement the functionality to change the data provider of a slave. With
that a slave can be added as a cascaded slave, copy the data, catch up
and then switch over to replicate against the master, or an existing
slave can become a cascaded one to reduce the load on the master.

Implement the failover capability to replace a failed master with a slave.

Add backup and replication logging (sort of PITR based on replication
information).

Add sequence replication.

Add script execution support for schema changes.

Both, the provider change and the failover need a much more complex
configuration than the current shell scripts can setup. The problem is
that the configuration and administration tools are not designed yet. So
here is a huge field for others to step up and take a key role in this
project.

Jan

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Ben 2004-03-03 22:15:20 Re: Simple, but VERYuseful enhancement for psql command - or am I missing something?
Previous Message Bill Moran 2004-03-03 21:42:34 Shouldn't B'1' = 1::bit be true?

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2004-03-03 22:10:01 Re: Out of space situation and WAL log pre-allocation (was Tablespaces)
Previous Message Joe Conway 2004-03-03 21:52:06 Re: Out of space situation and WAL log pre-allocation (was