By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
460,022 Members | 1,367 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 460,022 IT Pros & Developers. It's quick & easy.

Slony-I makes progress

P: n/a
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/...rojdisplay.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. #
#================================================= = Ja******@Yahoo.com #
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

Nov 23 '05 #1
Share this question for a faster answer!
Share on Google+

This discussion thread is closed

Replies have been disabled for this discussion.