Re: [Pgreplication-general] Master/Slave is in town!
От | Andy Samuel |
---|---|
Тема | Re: [Pgreplication-general] Master/Slave is in town! |
Дата | |
Msg-id | 007b01c24f07$fc766c60$0200a8c0@edphgm обсуждение исходный текст |
Список | pgsql-general |
This is certainly a good news ! Congratulations to you ( or to your team ) !! I would like to personally say thank you for the great job ! Warmest regards Andy ----- Original Message ----- From: "Mabrouk CHOUK" <mchouk@cs.mcgill.ca> To: <pgreplication-general@gborg.postgresql.org> Sent: Wednesday, August 28, 2002 9:09 PM Subject: [Pgreplication-general] Master/Slave is in town! > Hello All, > > I would like to announce that the Master/Slave approach to postgres is > almost finished. I have presently a working system. I am presently testing > the system and adding some "syntactic suger", i.e. making it nice and > sweet. > > I am testing the new system on two solaris machines (one Master and one > Slave). I will provide the new system for the general community for > testing on a hopefully much larger cluster as soon as I wrap it up and > have it approved by Dr. Bettina Kemme. > > There are many changes that I integrated into postgres. The main part of > these changes are in the replication module, i.e. the replication manager > process, the group communication process and the remote backends. This > e-mail will be quite large if I have to describe all the changes. However, > I have a suggestion: the replicationManager.c file have been dramatically > reduced and simplified, to the point that I suggest renaming the new file > to something like "MasterSlaveRMgr.c" or something alike. The reasons > behind this is avoid confusion with the old update-everywhere file, and to > make easier for developers to follow the changes to the system, and to > make improvements to it if need be. > > The general direction of my near-future work will be the following: > > 1. failure over integration of both the Mater and any slave: the system > has to be robust enough to handle failure of any host. > > 2. user transparent recovery mechanisms for both the Master and any Slave. > > I will be posting design suggestions on how I intend to pursue these two > goals. As usual, any comments/suggestions that might help me design a > better algorithm are very welcome. > > Cheers, > > Mabrouk > > _______________________________________________ > Pgreplication-general mailing list > Pgreplication-general@gborg.postgresql.org > http://gborg.postgresql.org/mailman/listinfo/pgreplication-general >
В списке pgsql-general по дате отправления: