Re: [GENERAL] Binary Replication and Slony
От | Bruce Momjian |
---|---|
Тема | Re: [GENERAL] Binary Replication and Slony |
Дата | |
Msg-id | 201102012021.p11KLWC19481@momjian.us обсуждение исходный текст |
Список | pgsql-docs |
I have applied the attached documentation improvement to better highlight Slony's abilities. --------------------------------------------------------------------------- Brad Nicholson wrote: > On 10-09-20 12:49 PM, Bruce Momjian wrote: > > John Cheng wrote: > >> Congrats on the 9.0 release of PostgreSQL. One of the features I am really > >> interested in is the built-in binary replication. > >> > >> Our production environment has been using PostgreSQL for more than 5 years > >> (since this project started). We have been using Slony-I as our replication > >> mechanism. I am interested to find out the pros and cons of Slony vs the > >> built-in replication in 9.0. Based on what I understand: > >> > >> * Slony has a higher overhead than the binary replication in 9.0 > >> * When using Slony, schema change must be applied via slonik (in most cases) > >> * Unfortunately, IMO it is easy to make a mistake when applying schema > >> changes in Slony, fortunately, it is easy to drop and recreate the > >> replication sets > >> * Slony is an asynchronous replication mechanism > >> * Slony allows you to replication some tables, while ignoring others > >> > >> * PostgreSQL 9.0 with hot standby& streaming replication is an asynchronous > >> replication mechanism > >> * Overhead is low compared to Slony > >> > >> Are there some cases where it is better to use Slony, for example, when you > >> must specifically exclude tables from replication? I believe our system will > >> be better off using the built-in replication mechanism of 9.0, and I am > >> guessing most people will be in the same boat. > > You have summarized the differences well. Streaming replication has > > lower overhread, but doesn't allow per-table granularity or allow > > replication between different versions of Postgres. > > > > Slony will also allow you to: > > -run custom schema (like extra indexes) on replicas > -replicate between different hardware architectures and OS's > -run lengthy queries against replicas having to worry about trade offs > surrounding query cancellation vs standby lagging. > -switch roles of two nodes without entering a degraded state or worrying > about STONITH. If you switch roles in a controlled manner, both nodes > remain in the cluster. Slony prevents writes against the replica. > > I do agree that for most, Slony is overkill and streaming replication > and hot standby will be the better choice. > > -- > Brad Nicholson 416-673-4106 > Database Administrator, Afilias Canada Corp. > > > > -- > Sent via pgsql-general mailing list (pgsql-general@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml index 4f59fd1..226d616 100644 *** a/doc/src/sgml/runtime.sgml --- b/doc/src/sgml/runtime.sgml *************** pg_dumpall -p 5432 | psql -d postgres -p *** 1704,1709 **** --- 1704,1711 ---- <para> It is also possible to use certain replication methods, such as <productname>Slony</>, to create a standby server with the updated version of + <productname>PostgreSQL</>. This is possible because Slony supports + replication between different major versions of <productname>PostgreSQL</>. The standby can be on the same computer or a different computer. Once it has synced up with the master server (running the older version of <productname>PostgreSQL</>), you can
В списке pgsql-docs по дате отправления:
Предыдущее
От: Itagaki TakahiroДата:
Сообщение: Re: [HACKERS] Add reference to client_encoding parameter