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 по дате отправления: