Hi You told me
No, events never go on to subscribers until after they are successfully applied on the origin node. And this is OK , it is logical ... I think there is a misunderstanding here, I didn t clearify my question . I wanted to know : If there is a way to have : (DML changes that are commited only WRITTEN on the Master) ==== (if )====> (They are successfully written on the SLAVE) . I know it is complicated but I do not mean to have a SYNCHRONOUS solution. But : DML operations are processed ONLY by the Master. A commit is done . And the records will be written in the Master and SLAVE at the same time. So : the processor is MASTER , and data will be saved in Master only if it also saved at the same time or "before" on the SLAVE. Thanke you ! Largo PS : I know it is complicated but U also help me with ideas or methods ! ---------------------------------------------------------------------------------------- ---------------------------------------------------------------------------------------- [EMAIL PROTECTED] schrieb: >> Hi Andrew >> >> I thank you for the reply, your suggestions are quite good, but it is >> still not possible for me to convince my CHEF to adapt SLONY-I in the >> prod. env. because of the non sync.-ed data in case of a failover . >> >> My question is : >> >> IS IT POSSIBLE TO CONFIGURE SLONY-I SO THAT : >> - DML changes will be commited on the Master only after they are >> SYNC.-ed to the slave. >> > > No, events never go on to subscribers until after they are successfully > applied on the origin node. > > There was a brief discussion at the Anniversary Summit about the > notion of > maybe using PREPARE TRANSACTION and handling this sort of thing via 2 > phase commit, but there seemed to be general agreement that it's not the > right time for that. > > >> - I mean it is better for me (if my data-records will not be written on >> the master), than (written on master and missed on the slave after a >> failover as example). >> > > I fully understand the issue; you don't want to have the possibility of > some transactions being missed on FAILOVER that were reported to > customers > as completed. > > Unfortunately, no, there's not a way to make Slony-I wait in this > fashion. > > >> - Knowing that : - I work with a SLON Sync-Interval of 500 msec and >> will reduce it now to 100 msec >> > > Dropping the SYNC interval that way may not be as useful as you think; it > *may* reduce the latency time, but it may also add more replication work, > adding something back to the latency time. > > The intervals are not "real time guarantees," so you can't depend on them > as perfect protection from problems that may arise. > > And remember, if your origin node starts failing, say with disk drives > falling over, that will likely degrade system behaviour before it > actually > leads to outright failure. > > _______________________________________________ Slony1-general mailing list [email protected] http://gborg.postgresql.org/mailman/listinfo/slony1-general
