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