Basically you use PostgreSQL replication in conjunction with some other Linux failover management system (e.g. ucarp and friends). Which then determines how/when a new master is appointed, and grabs the virtual IP. Apps can continue to talk to that. There may of course be re-connections, but in this case the app is designed to manage that without the outside world knowing.
So yes, virtual hosts as the Oracle guys do it. P. On Sep 10, 2013, at 13:41, James S. K. Makumbi <[email protected]> wrote: > Paul, > This is like a db farm? How does my app know to point to the new master? > It is a distributed db that the application sees as one and is thus oblivious > to failovers? > Short of allowing servers to play the “I am spartacus” gag over dns, this is > not possible. > Thus the app needs to be re-pointed at every failover? > > From: [email protected] [mailto:[email protected]] On Behalf Of > Paul Bagyenda > Sent: 10 September 2013 13:25 > To: Uganda Linux User Group > Subject: Re: [LUG] PostgreSQL 9.3 Released > > Doing it in the code itself is a bit brave. Replication and failover have > been working respectably since 9.1. However at the time 1) getting the slaves > to point to a new master after a failover meant a *rebuild* of the slaves and > b) all machines had to have the *exact* same H/W and S/W. These have gone > away, which is nice. In the first case, rebuilding a new slave involved all > manner of rsyncs with all the attendant opportunities for a screw up. > > We have installations across timezones and oceans which without properly > running PostgreSQL replication systems would mean support calls at unholy > hours. So yes we are gratified that this database keeps getting better at > these things. > > > P. > > On Sep 10, 2013, at 11:13, James S. K. Makumbi <[email protected]> wrote: > > > Replication with failover? > WOW! > Do you have any idea how crazy it is to get this working on SQL Server? > I code using an ORM framework and use “code-first” (which does NASTY things > to the db if you are not careful). This way I am db agnostic but sometimes I > look at the advances in databases and realize more and more the reason to use > an ORM is growing unnecessary. > The problem is becoming deployment, replication and failover which are tough > to manage in code (updating tables and rollbacks). > > From: [email protected] [mailto:[email protected]] On Behalf Of > Paul Bagyenda > Sent: 10 September 2013 10:51 > To: Uganda Linux User Group > Subject: Re: [LUG] PostgreSQL 9.3 Released > > As always much improvement. The improvements in replication are most welcome: > https://wiki.postgresql.org/wiki/What%27s_new_in_PostgreSQL_9.3#Replication_Improvements > On Sep 10, 2013, at 07:41, Martin Atukunda <[email protected]> wrote: > > > > http://www.postgresql.org/about/news/1481/ > > The PostgreSQL Global Development Group announces the release of PostgreSQL > 9.3, the latest version of the world's leading open source relational > database system. This release expands PostgreSQL's reliability, availability, > and ability to integrate with other databases. Users are already finding that > they can build applications using version 9.3 which would not have been > possible before. > > - Martin - > _______________________________________________ > The Uganda Linux User Group: http://linux.or.ug > > Send messages to this mailing list by addressing e-mails to: [email protected] > Mailing list archives: http://www.mail-archive.com/[email protected]/ > Mailing list settings: http://kym.net/mailman/listinfo/lug > To unsubscribe: http://kym.net/mailman/options/lug > > The Uganda LUG mailing list is generously hosted by INFOCOM: > http://www.infocom.co.ug/ > > The above comments and data are owned by whoever posted them (including > attachments if any). The mailing list host is not responsible for them in any > way. > > _______________________________________________ > The Uganda Linux User Group: http://linux.or.ug > > Send messages to this mailing list by addressing e-mails to: [email protected] > Mailing list archives: http://www.mail-archive.com/[email protected]/ > Mailing list settings: http://kym.net/mailman/listinfo/lug > To unsubscribe: http://kym.net/mailman/options/lug > > The Uganda LUG mailing list is generously hosted by INFOCOM: > http://www.infocom.co.ug/ > > The above comments and data are owned by whoever posted them (including > attachments if any). The mailing list host is not responsible for them in any > way. > > _______________________________________________ > The Uganda Linux User Group: http://linux.or.ug > > Send messages to this mailing list by addressing e-mails to: [email protected] > Mailing list archives: http://www.mail-archive.com/[email protected]/ > Mailing list settings: http://kym.net/mailman/listinfo/lug > To unsubscribe: http://kym.net/mailman/options/lug > > The Uganda LUG mailing list is generously hosted by INFOCOM: > http://www.infocom.co.ug/ > > The above comments and data are owned by whoever posted them (including > attachments if any). The mailing list host is not responsible for them in any > way.
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ The Uganda Linux User Group: http://linux.or.ug Send messages to this mailing list by addressing e-mails to: [email protected] Mailing list archives: http://www.mail-archive.com/[email protected]/ Mailing list settings: http://kym.net/mailman/listinfo/lug To unsubscribe: http://kym.net/mailman/options/lug The Uganda LUG mailing list is generously hosted by INFOCOM: http://www.infocom.co.ug/ The above comments and data are owned by whoever posted them (including attachments if any). The mailing list host is not responsible for them in any way.
