Re: [PERFORM] Sort-of replication for reporting purposes

Поиск
Список
Период
Сортировка
От Scott Marlowe
Тема Re: [PERFORM] Sort-of replication for reporting purposes
Дата
Msg-id CAOR=d=2YQ=e1FQhqPGoV2a2VLi69gXOEeZtgrbm63tLXXvcjWA@mail.gmail.com
обсуждение исходный текст
Ответ на [PERFORM] Sort-of replication for reporting purposes  (Ivan Voras <ivoras@gmail.com>)
Ответы Re: [PERFORM] Sort-of replication for reporting purposes
Список pgsql-performance
On Fri, Jan 6, 2017 at 12:24 PM, Ivan Voras <ivoras@gmail.com> wrote:
> Hello,
>
> I'm investigating options for an environment which has about a dozen servers
> and several dozen databases on each, and they occasionally need to run huge
> reports which slow down other services. This is of course "legacy code".
> After some discussion, the idea is to offload these reports to separate
> servers - and that would be fairly straightforward if not for the fact that
> the report code creates temp tables which are not allowed on read-only hot
> standby replicas.
>
> So, the next best thing would be to fiddle with the storage system and make
> lightweight snapshots of live database clusters (their storage volumes) and
> mount them on the reporting servers when needed for the reports. This is a
> bit messy :-)
>
> I'm basically fishing for ideas. Are there any other options available which
> would offer fast replication-like behaviour ?
>
> If not, what practices would minimise problems with the storage snapshots
> idea? Any filesystem options?

I've always solved this with slony replication, but pg_basebackup
should be pretty good for making sort of up to date slave copies. Just
toss a recovery.conf file and touch whatever failover file the slave
expects etc.


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

Предыдущее
От: Ivan Voras
Дата:
Сообщение: [PERFORM] Sort-of replication for reporting purposes
Следующее
От: Ivan Voras
Дата:
Сообщение: Re: [PERFORM] Sort-of replication for reporting purposes