Re: repair table? database? how ? neccessary?
От | philo vivero |
---|---|
Тема | Re: repair table? database? how ? neccessary? |
Дата | |
Msg-id | 1041885578.2339.10.camel@timetop обсуждение исходный текст |
Ответ на | repair table? database? how ? neccessary? (mitchell laks <mlaks@bellatlantic.net>) |
Список | pgsql-admin |
On Mon, 2003-01-06 at 17:21, mitchell laks wrote: > The main issue I had with Access was that as the database got larger, My > application began to fail regularly, and I began to need to do "repair" of > the database almost on a daily or other daily basis. . . . > the Postgresql database is currently 5 times the size of the level when I > began to have m$ft problems . . . > without problems (knock wood) but what do I do if i need to repair? Fortunately for you, you're now in a different league of database backends. PostgreSQL won't need to be 'repaired' unless something catastrophic happens to it (ie: the HDD becomes corrupted, Linux virtual memory goes wacko, whatever) -- Each of these problems has an extremely low likelihood of happening. However, you are a DBA, and I am a DBA, so we must be paranoid and assume that tomorrow PostgreSQL will corrupt all our data, Linux will churn it up with /dev/urandom, and your nice Quantum HDD array will be subjected to some strong electromagnetic radiation. Take regular backups of your database (can be done while database is live), store the backups on media that is physically distant from the main database. On a regular basis, restore the backup you've made to another machine and do at least minimal sanity checking. My own method is to restore a copy of the production database to the developers' development database so they can use development versions of production software against the database. As for your concerns about killing the postmaster, don't "kill -9" the postmaster, which is a nasty SIGKILL signal which won't let it clean up. I believe "kill -15" SIGTERM will make the postmaster shut down as immediately as is safe. The pg_ctl command is a better way to go about it, however: $ pg_ctl --help . . . pg_ctl stop [-W] [-D DATADIR] [-s] [-m SHUTDOWN-MODE] . . . Shutdown modes are: smart Quit after all clients have disconnected fast Quit directly, with proper shutdown immediate Quit without complete shutdown; will lead to recovery run on restart So in the future, try "pg_ctl stop -m fast" or even "-m immediate" if necessary. I think, without looking into pg_ctl, that shutdown immediate is a wrapper for a nice smart "kill -15" -- take this with a grain of salt. Enjoy, -- Tim Ellis Senior Database Architect
В списке pgsql-admin по дате отправления: