Обсуждение: pg_xlog symlink
Hello. I have just moved our database from one server to another using warm standby. It worked very well. The setup: PostgreSQL 8.2.5 on Ubuntu. One partition for OS, one for backup including wal archiving, one for base and one for pg_xlog. It is set up to archive wals to /backup/masterhostname/wal There is something strange in the pg_xlog directory of our new master. %:/usr/local/postgresql-8.2.5/data/pg_xlog# ls -l total 49220 -rw------- 1 postgres postgres 257 2008-02-15 00:35 000000010000003A00000046.00004D60.backup -rw------- 1 postgres postgres 16777216 2008-02-15 10:04 000000010000003A0000006C -rw------- 1 postgres postgres 16777216 2008-02-15 10:04 000000010000003A0000006D lrwxrwxrwx 1 postgres postgres 45 2008-02-14 21:56 000000010000003A0000006E -> /backup/oldmasterhostname/wal/ 000000010000003A0000003B -rw------- 1 postgres postgres 16777216 2008-02-15 10:08 000000010000003A0000006F drwx------ 2 postgres root 4096 2008-02-15 10:08 archive_status As you see, one of the wal files is a symlink to a file on the backup partition. I would like all the wal files to exist on the pg_xlog for performance and clarity. Can I safely fix this situation without restarting the database? Why did not PostgreSQL fix this automatically? Regards, - Tore.
Tore Halset wrote: > Hello. > > I have just moved our database from one server to another using warm > standby. It worked very well. > > The setup: PostgreSQL 8.2.5 on Ubuntu. One partition for OS, one for > backup including wal archiving, one for base and one for pg_xlog. It > is set up to archive wals to /backup/masterhostname/wal > > There is something strange in the pg_xlog directory of our new master. > > %:/usr/local/postgresql-8.2.5/data/pg_xlog# ls -l > total 49220 > -rw------- 1 postgres postgres 257 2008-02-15 00:35 > 000000010000003A00000046.00004D60.backup > -rw------- 1 postgres postgres 16777216 2008-02-15 10:04 > 000000010000003A0000006C > -rw------- 1 postgres postgres 16777216 2008-02-15 10:04 > 000000010000003A0000006D > lrwxrwxrwx 1 postgres postgres 45 2008-02-14 21:56 > 000000010000003A0000006E -> /backup/oldmasterhostname/wal/ > 000000010000003A0000003B > -rw------- 1 postgres postgres 16777216 2008-02-15 10:08 > 000000010000003A0000006F > drwx------ 2 postgres root 4096 2008-02-15 10:08 archive_status > > As you see, one of the wal files is a symlink to a file on the backup > partition. I would like all the wal files to exist on the pg_xlog for > performance and clarity. Can I safely fix this situation without > restarting the database? Why did not PostgreSQL fix this automatically? Having a symlink in pg_xlog is very odd and we have no idea how that happened. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
On Feb 15, 2008, at 10:17 , Tore Halset wrote: > Hello. > > I have just moved our database from one server to another using warm > standby. It worked very well. > > The setup: PostgreSQL 8.2.5 on Ubuntu. One partition for OS, one for > backup including wal archiving, one for base and one for pg_xlog. It > is set up to archive wals to /backup/masterhostname/wal > > There is something strange in the pg_xlog directory of our new master. > > %:/usr/local/postgresql-8.2.5/data/pg_xlog# ls -l > total 49220 > -rw------- 1 postgres postgres 257 2008-02-15 00:35 > 000000010000003A00000046.00004D60.backup > -rw------- 1 postgres postgres 16777216 2008-02-15 10:04 > 000000010000003A0000006C > -rw------- 1 postgres postgres 16777216 2008-02-15 10:04 > 000000010000003A0000006D > lrwxrwxrwx 1 postgres postgres 45 2008-02-14 21:56 > 000000010000003A0000006E -> /backup/oldmasterhostname/wal/ > 000000010000003A0000003B > -rw------- 1 postgres postgres 16777216 2008-02-15 10:08 > 000000010000003A0000006F > drwx------ 2 postgres root 4096 2008-02-15 10:08 > archive_status > > As you see, one of the wal files is a symlink to a file on the > backup partition. I would like all the wal files to exist on the > pg_xlog for performance and clarity. Can I safely fix this situation > without restarting the database? Why did not PostgreSQL fix this > automatically? The problem seem to be that I used pg_standby with the "-l" option. Regards, - Tore.