Re: No flamefest please, MySQL vs. PostgreSQL AGAIN

Поиск
Список
Период
Сортировка
От Murthy Kambhampaty
Тема Re: No flamefest please, MySQL vs. PostgreSQL AGAIN
Дата
Msg-id 2D92FEBFD3BE1346A6C397223A8DD3FC09225D@THOR.goeci.com
обсуждение исходный текст
Ответ на No flamefest please, MySQL vs. PostgreSQL AGAIN  (timeless postgres <pvspam-postgres@hacklab.net>)
Список pgsql-admin
>-----Original Message-----
>From: David F. Skoll [mailto:dfs@roaringpenguin.com]
>Sent: Monday, May 12, 2003 16:08
>To: pgsql-admin@postgresql.org
>Subject: Re: [ADMIN] No flamefest please, MySQL vs. PostgreSQL AGAIN
>
>
>On Mon, 12 May 2003, Naomi Walker wrote:
>
>> We would be interested in replication, so reporting could be
>done against a
>> different server than production.
>
>And I'm interested in replication for failover purposes.  Automatic
>hot-failover isn't really required for my application, but a "warm"
>failover that can have a mostly-up-to-date data set and be activated
>within a few minutes would be very nice.

I think you'll find the discussion on "LVM snapshots"
http://marc.theaimsgroup.com/?l=postgresql-admin&w=2&r=1&s=LVM+snapshots&q=b
relevant. If you don't need the log roll-forward coming with postgresql
PITR, and your reporting function is run infrequently, you can get "really
lazy replication" with rsync, LVM (or EVMS or hardware) snapshots, and a
journaling filesystem (an example script is included in the discussion).
This strategy has eliminated a big problem we had with postgresql dumps
taking too long on large datasets, but it also facilitates the applications
David and Naomi are interested in, under the right circumstances.

    Murthy

(With XFS as the underlying filesystem, snapshot creation sometimes gets
stuck in D state, and so does the $PGDATA filesystem. I have an updated
example script with a workaround for this, which I will post in a day or
two; an updated version of XFS with a permanent fix is in testing.)


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

Предыдущее
От: Oliver Kullmann
Дата:
Сообщение: problems with moving a database
Следующее
От: Will LaShell
Дата:
Сообщение: Re: No flamefest please, MySQL vs. PostgreSQL AGAIN