Re: Synchronous replication - patch status inquiry

Поиск
Список
Период
Сортировка
От Dimitri Fontaine
Тема Re: Synchronous replication - patch status inquiry
Дата
Msg-id 87vd6ouucp.fsf@hi-media-techno.com
обсуждение исходный текст
Ответ на Re: Synchronous replication - patch status inquiry  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> Tell that to the DBA.  I bet s/he knows what "all standbys" means.
> The fact that the system doesn't know something doesn't make it
> unimportant.

Well as a DBA I think I'd much prefer to attribute "votes" to each
standby so that each ack is weighted. Let me explain in more details the
setup I'm thinking about.

The transaction on the master wants a certain "service level" (async,
recv, fsync, replay) and a certain number of votes. As proposed earlier,
the standby would feedback the last XID known locally in each state
(received, synced, replayed) and its current weight, and the master
would arbitrate given those information.

That's highly flexible, you can have slaves join the party at any point
in time, and change 2 user GUC (set by session, transaction, function,
database, role, in postgresql.conf) to setup the service level target
you want to ensure, from the master.
 (We could go as far as wanting fsync:2,replay:1 as a service level.)

From that you have either the "fail when slave disappear" and the
"please don't shut the service down if a slave disappear" settings, per
transaction, and per slave too (that depends on its weight, remember).
 (You can setup the slave weights as powers of 2 and have the service  level be masks to allow you to choose precisely
whichslave will ack  your fsync service level, and you can switch this slave at run time  easily — sounds cleverer, but
soundsalso easier to implement given  the flexibility it gives — precedents in PostgreSQL? the PITR and WAL  Shipping
facilitiesare hard to use, full of traps, but very  flexible). 

You can even give some more weight to one slave while you're maintaining
another so that the master just don't complain.

I see a need for very dynamic *and decentralized* replication topology
setup, I fail to see a need for a centralized registration based setup.

> I agree that we don't absolutely need standby registration for some
> really basic version of synchronous replication.  But I think we'd be
> better off biting the bullet and adding it.

What does that mechanism allow us to implement we can't do without?
--
dim


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Haggerty
Дата:
Сообщение: Re: git: uh-oh
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: Synchronous replication - patch status inquiry