Re: Core team statement on replication in PostgreSQL

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Core team statement on replication in PostgreSQL
Дата
Msg-id 8400.1212102176@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Core team statement on replication in PostgreSQL  ("Joshua D. Drake" <jd@commandprompt.com>)
Ответы Re: Core team statement on replication in PostgreSQL  ("Joshua D. Drake" <jd@commandprompt.com>)
Re: Core team statement on replication in PostgreSQL  (Greg Smith <gsmith@gregsmith.com>)
Re: Core team statement on replication in PostgreSQL  (Andrew Sullivan <ajs@commandprompt.com>)
Список pgsql-hackers
"Joshua D. Drake" <jd@commandprompt.com> writes:
> One customer does not make a hundred. I am not saying that the shipping
> isn't valid, just that those that I talk to are more interested in the
> read only slave. Consider that we have any number of ways to solve the
> problem we are considering implementing now. DRBD being just one of
> them.

In principle, sure, but there's a big gap between theory and practice
here.  What you are arguing for is the "give the users a toolkit and
let them figure it out" approach that David was lambasting upthread.
People want the bits to go from point A to point B; they don't want
to have to research, design, test, and administer their own solution
for moving the bits.  Furthermore, as several people have pointed out
from their own bitter experiences, getting a reliable and easy-to-use
solution is not as easy as it sounds.  I think we have nontrivial
work in front of us to build a simple, reliable, community-tested
log shipping solution; and it's not very sexy work either.  But it
needs to get done, and it really needs to get done first.  There's
no point in having read-only slave queries if you don't have a
trustworthy method of getting the data to them.
        regards, tom lane


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

Предыдущее
От: "Joshua D. Drake"
Дата:
Сообщение: Re: Core team statement on replication in PostgreSQL
Следующее
От: Jan Urbański
Дата:
Сообщение: proposal: Preference SQL