Re: replication/redundancy
От | weigelt@metux.de |
---|---|
Тема | Re: replication/redundancy |
Дата | |
Msg-id | 20030701160051.GB10174@metux.de обсуждение исходный текст |
Ответ на | replication/redundancy ("Dave [Hawk-Systems]" <dave@hawk-systems.com>) |
Список | pgsql-admin |
On Tue, Jul 01, 2003 at 08:22:37AM -0700, Jonathan Gardner wrote: <snip> > So you are using "lazy" rather than "eager" replication. correct. <snip> > 1) The data is not consistent. This means if you run the same select query > at the same time on the two databases, you may get different results. For > some situations, that is okay (like Usenet). For others, it is not. (like > registrations -- you'll sign up on one database, but you won't appear on the > other.) Yes. For those cases, an explicit syncout should be triggered as fast as possible. What you of course cannot is to store session data into the clustered DB. All requests to same session must go to the same host. In web applications this can be done by redirecting the client to an per-server-vhost before creating the session. (i.e. from www.metux.de to s[1..n].metux.de). So the session data is always available for the application. In the case of failure only those sessions are lost, which run on the failing server. Another solution could be an NFS-shared session directory or an rpc-based update notification system. Perhaps we could implement some remote locking features direct into the postmaster. <snip> > 3) These two factors above make using the second database as a hot-swappable > backup risky at best. You will lose some data when you switch to the backup, > unless changes to the database are so rare that the backup is usually up to > date. If that were the case, you probably don't need the backup in the first > place, because databases that don't do much tend not to be very important. For my current applications it seems ok that some DBs are one or two minutes behind. <snip> > The most obvious problem with this comes from incrementing a column. I had such an case. If i want to count objects, i normally put them into an table and count the rows (i.e. from an view). If both servers add an new object, there will be no conflict. <snip> > This would be bad for things like paypal, where your account would only > increase by one or the other account transfers, rather than both, if two > occured at the same time. Well, for such applications, the actual account value must be calculated from an checkpoint and the lasted transactions. Checkpoints may be made only by an master (which may change from time to time) cu -- --------------------------------------------------------------------- Enrico Weigelt == metux ITS Webhosting ab 5 EUR/Monat. UUCP, rawIP und vieles mehr. phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: contact@metux.de cellphone: +49 174 7066481 smsgate: sms.weigelt@metux.de --------------------------------------------------------------------- Diese Mail wurde mit UUCP versandt. http://www.metux.de/uucp/
В списке pgsql-admin по дате отправления: