Re: minimizing downtime when upgrading
От
snacktime
Тема
Re: minimizing downtime when upgrading
Дата
Msg-id
1f060c4c0606161016m6e3a11fct1b8b79c1e96808d3@mail.gmail.com
Ответ на
Re: minimizing downtime when upgrading (Richard Huxton)
Список
Дерево обсуждения
minimizing downtime when upgrading snacktime <snacktime@gmail.com>
Re: minimizing downtime when upgrading Richard Huxton <dev@archonet.com>
Re: minimizing downtime when upgrading snacktime <snacktime@gmail.com>
Re: minimizing downtime when upgrading Bill Moran <wmoran@collaborativefusion.com>
Re: minimizing downtime when upgrading Kenneth Downs <ken@secdat.com>
Re: minimizing downtime when upgrading Richard Huxton <dev@archonet.com>
Re: minimizing downtime when upgrading Kenneth Downs <ken@secdat.com>
Re: minimizing downtime when upgrading Martijn van Oosterhout <kleptog@svana.org>
Re: minimizing downtime when upgrading Alban Hertroys <alban@magproductions.nl>
Re: minimizing downtime when upgrading "H.J. Sanders" <hjs@rmax.nl>
Re: minimizing downtime when upgrading Jim Nasby <decibel@decibel.org>
Re: minimizing downtime when upgrading Kenneth Downs <ken@secdat.com>
Re: minimizing downtime when upgrading Oleg Bartunov <oleg@sai.msu.su>
On 6/16/06, Richard Huxton wrote: > The other option would be to run replication, e.g. slony to migrate from > one version to another. I've done it and it works fine, but it will mean > slony adding its own tables to each database. I'd still do it one > merchant at a time, but that should reduce your downtime to seconds. > I'll have to take another look at slony, it's been a while. Our database structure is a bit non standard. Being a payment gateway, we are required to have a separation of data between merchants, which means not mixing data from different merchants in the same table. So what we do is every user has their own schema, with their own set of tables. Yes I know that's not considered the best practice design wise, but separate databases would have caused even more issues, and as it turns out there are some advantages to the separate schema approach that we never thought of. Last time I looked at slony you have to configure it for each individual table you want replicated. We have around 50,000 tables, and more are added on a daily basis.
В списке pgsql-general по дате отправления
От: Bruno Wolff III
Дата: