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:
=============== =============== =============== =============== ========
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@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
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:
=============== =============== =============== =============== ========
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@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