Thu Mar 30 23:37:09 PST 2006
- Previous message: [Slony1-general] How can I avoid the delay
- Next message: [Slony1-general] How can I avoid the delay
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
--On Donnerstag, M?rz 30, 2006 19:10:06 -0300 Marco Canderle <marcocanderle at gmail.com> wrote: > As I said, Reads are solved locally by every local slave server, and > writes are routed directly to the master server, which then replicates > the changes made. > Here is where my problem arise. If a user is connected to a slave server > and needs to make changes to de database, the writes will be passed to > the master server. The master will make the corresponding changes and > Slony-I will replicate this changes back to the slave who passed the > writes (and all other slaves). All this steps adds a delay until the > remote user can see the changes he/she made to the database reflected in > his screen. For example if the user adds a new product to the database, > he won't see it in the products list until the replication takes place. > This kind of situations can make the system show wrong information, which > is dangerous in some scenarios of my system. > > So I ask: Are there any solutions that may help me reduce/avoid this > delay or at least prevent the slave server to respond to the user until > the replication have propagated to all the slaves (or at least the one > which originates the writes)? Maybe some kind of combination between > asynchronous replication (provided by Slony-I) and synchronous > replication? For once, you can reduce the interval slony uses to synchronize the updates around, no idea how the options are named, only twiddled with them a bit a time ago. This could reduce the delay, but would not remove it. I am not aware of a solution within slony, yet I can easily think of an architecture which might do what you want: Before every write, make the writing process first insert the row into the master server, insert a "object is dirty" row into a special table _at every satelite location_ and commit at the satelites, then commit the master. This way, the information that a row is dirty is known at every satelite server. You could then either connect a slightly modified slony-replication to your satelite server which instead of syncing does remove the marker rows (we did something similar at our company for other purposes). Or you could (which I'd clearly prefer, include the transaction id within your marker rows. If your client then requests a row from the local database it would need to have a look into the special table and could then say something along the lines of "object is currently being edited"... If the connection goes down, well writing gets impossible, but that's the case anyhow... And of course your local data gets non-up-to-date, well no way to change that. At least it should make conflicting updates impossible. Mit freundlichem Gru? Jens Schicke -- Jens Schicke j.schicke at asco.de asco GmbH http://www.asco.de Mittelweg 7 Tel 0531/3906-127 38106 Braunschweig Fax 0531/3906-400
- Previous message: [Slony1-general] How can I avoid the delay
- Next message: [Slony1-general] How can I avoid the delay
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Slony1-general mailing list