Re: How robust is PostgreSQL
От | adb |
---|---|
Тема | Re: How robust is PostgreSQL |
Дата | |
Msg-id | Pine.GSO.4.10.10103061249310.2561-100000@hairdini.beast.com обсуждение исходный текст |
Ответ на | How robust is PostgreSQL ("Simon Crute" <Simon-lists@geordie.demon.co.uk>) |
Список | pgsql-general |
As of version 7.1 postgres uses write ahead logging which is what you are looking for. As for backups, currently your only option is full dumps of the entire db or full dumps of individual tables. Some folks are working around this by using replication to a secondary server with rserv (in contrib) Hopefully the incremental backup issue will be addressed soon. Also if your database is not huge, you can probably afford to do a full dump each hour to an alternate machine. Run some tests and see how a dump affects your production system under load. I'm in the same situation, did some prototyping in oracle and decided that once we are live, it's going to cost too much. I've done enough banging on rserv to feel somewhat comfortable using it as a crutch until there's something better. Alex. On Tue, 6 Mar 2001, Simon Crute wrote: > Hi all, > We're writing an app in Perl and currently using Oracle as the backend > database (via the perl DBI) but due to the costs when we put this live we're > thinking of useing Postgresql. > > However we need to know how crash resistant Posgresql is. Oracle has the > "Archive log mode" which writes a log of everything that's casued the > database to change. This allows you to recoved it properly in the event of a > crash. > > Does Postgresql have anything simmilar ? I've read about Postgresql's "fsync > mode". Does this guarantee that the data is written to the disk properly and > that the in the even of a crash (such as power outage etc) the database will > still be correct ? > > The other question is Backups. Is there anyway to take diferential backups ? > I.E do a full dump periodically, and then make diferential backups from time > to time (preferably to a differet box) > > Thanks. > > > > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster >
В списке pgsql-general по дате отправления: