Re: 9.6 -> 10.0
От | Bruce Momjian |
---|---|
Тема | Re: 9.6 -> 10.0 |
Дата | |
Msg-id | 20160512160902.GD2632@momjian.us обсуждение исходный текст |
Ответ на | Re: 9.6 -> 10.0 (Magnus Hagander <magnus@hagander.net>) |
Ответы |
Re: 9.6 -> 10.0
Re: 9.6 -> 10.0 |
Список | pgsql-advocacy |
On Thu, May 12, 2016 at 05:43:28PM +0200, Magnus Hagander wrote: > > On May 12, 2016 17:36, "Bruce Momjian" <bruce@momjian.us> wrote: > > In a master/slave setup with pg_logical, a major upgrade is _near_ > > zero-downtime, because you have to switch over all write transactions at > > a single point in time when you promote the slave to master. So you > > have to either prevent new write transactions from going to the slave > > while you wait for the master transactions to finish, or (more likely) > > you have to terminate the write transactions on the master and then > > promote the slave to master and allow everything to reconnect. > > > > (In practice, you can't change a read/write server to read-only without > > a restart, so effectively all old-master transactions have to be drained > > at some point.) > > You can make it closer to, or completely zero, if you combine it with pgbouncer > in transaction pooling mode. There will be a performance hiccup, but it should > work. That is an interesting approach. How many applications are prepared to re-sent a transaction block based on the error returned by pgbouncer in this case? I am thinking our docs need a new section about reducing downtime during switch-over, and using logical replication for major version upgrades. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
В списке pgsql-advocacy по дате отправления: