Обсуждение: [GENERAL] Postgres 9.6 fails to start on VMWare
I’ve migrated a running Debian Jessie system from a Google Compute instance to a VMWare ESXi 6.5 system. Postgres won’t start, although returns [ok] : /etc/init.d/postgresql start 9.6 [ ok ] Starting postgresql (via systemctl): postgresql.service. 2017-10-22 14:08:28 UTC [2479-1] LOG: 00000: database system shutdown was interrupted; last known up at 2017-10-22 14:07:20UTC 2017-10-22 14:08:28 UTC [2479-2] LOCATION: StartupXLOG, xlog.c:6009 2017-10-22 14:08:28 UTC [2479-3] LOG: 00000: database system was not properly shut down; automatic recovery in progress 2017-10-22 14:08:28 UTC [2479-4] LOCATION: StartupXLOG, xlog.c:6505 2017-10-22 14:08:28 UTC [2479-5] LOG: 00000: redo starts at A1/688398C0 2017-10-22 14:08:28 UTC [2479-6] LOCATION: StartupXLOG, xlog.c:6760 2017-10-22 14:08:28 UTC [2479-7] LOG: 00000: invalid record length at A1/6AC96408: wanted 24, got 0 2017-10-22 14:08:28 UTC [2479-8] LOCATION: ReadRecord, xlog.c:4024 2017-10-22 14:08:28 UTC [2479-9] LOG: 00000: redo done at A1/6AC963E0 2017-10-22 14:08:28 UTC [2479-10] LOCATION: StartupXLOG, xlog.c:7023 2017-10-22 14:08:28 UTC [2479-11] LOG: 00000: last completed transaction was at log time 2017-10-21 16:40:52.629875+00 2017-10-22 14:08:28 UTC [2479-12] LOCATION: StartupXLOG, xlog.c:7028 2017-10-22 14:08:29 UTC [2479-13] LOG: 00000: request to flush past end of generated WAL; request A1/72AF47A8, currpos A1/6AC96408 2017-10-22 14:08:29 UTC [2479-14] CONTEXT: writing block 0 of relation base/203725/2840_vm 2017-10-22 14:08:29 UTC [2479-15] LOCATION: WaitXLogInsertionsToFinish, xlog.c:1583 2017-10-22 14:08:29 UTC [2479-16] FATAL: XX000: xlog flush request A1/72AF47A8 is not satisfied --- flushed only to A1/6AC96408 2017-10-22 14:08:29 UTC [2479-17] CONTEXT: writing block 0 of relation base/203725/2840_vm 2017-10-22 14:08:29 UTC [2479-18] LOCATION: XLogFlush, xlog.c:2765 2017-10-22 14:08:29 UTC [2478-1] LOG: 00000: startup process (PID 2479) exited with exit code 1 2017-10-22 14:08:29 UTC [2478-2] LOCATION: LogChildExit, postmaster.c:3504 2017-10-22 14:08:29 UTC [2478-3] LOG: 00000: aborting startup due to startup process failure 2017-10-22 14:08:29 UTC [2478-4] LOCATION: reaper, postmaster.c:2777 2017-10-22 14:08:29 UTC [2478-5] LOG: 00000: database system is shut down 2017-10-22 14:08:29 UTC [2478-6] LOCATION: UnlinkLockFiles, miscinit.c:755 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
On Sun, Oct 22, 2017 at 11:13 PM, Martin Moore <martin.moore@avbrief.com> wrote: > I’ve migrated a running Debian Jessie system from a Google Compute instance to a VMWare ESXi 6.5 system. How did you actually do this migration? It is really easy to finish with a corrupted instance if not doing things correctly in this world (I am referring to quiesced snapshot & co). -- Michael -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
On Sun, 2017-10-22 at 15:13 +0100, Martin Moore wrote: > 2017-10-22 14:08:28 UTC [2479-1] LOG: 00000: database system > shutdown was interrupted; last known up at 2017-10-22 14:07:20 UTC There is something missing here. Last shutdown at 2017-10-22 14:07:20 UTC on which server? Then attempting to start it at 2017-10-22 14:08:28 UTC? One minute and eight seconds later. It might also help if you explained exactly how you moved the database from Google Compute to this VM machine. Cheers, robert -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Same server. I tried a few times.
I didn’t move the db separately, but did a ‘dd’ to copy the disk to an imagefile which was converted and loaded into
VMWare.
I ‘believed’ that this should keep the low level disk structure the same, but if this has corrupted the files I can
drop,dump and restore, in which case how do I ‘drop’ the DB without postgres running?
Ta,
Martin.
On 23/10/2017, 00:51, "rob stone" <floriparob@gmail.com> wrote:
On Sun, 2017-10-22 at 15:13 +0100, Martin Moore wrote: > 2017-10-22 14:08:28 UTC [2479-1] LOG: 00000:
databasesystem > shutdown was interrupted; last known up at 2017-10-22 14:07:20 UTC There is something missing
here.Last shutdown at 2017-10-22 14:07:20 UTC on which server? Then attempting to start it at 2017-10-22 14:08:28
UTC?One minute and eight seconds later. It might also help if you explained exactly how you moved the database
fromGoogle Compute to this VM machine. Cheers, robert
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Same server. I tried a few times.
I didn’t move the db separately, but did a ‘dd’ to copy the disk to an imagefile which was converted and loaded into VMWare.
I ‘believed’ that this should keep the low level disk structure the same, but if this has corrupted the files I can drop, dump and restore, in which case how do I ‘drop’ the DB without postgres running?
Ta,
Martin.
It was running – not sure how dd handles this. Maybe badly… ☺
From: Michael Nolan <htfoot@gmail.com>
Date: Monday, 23 October 2017 at 15:52
To: Martin Moore <martin.moore@avbrief.com>
Cc: rob stone <floriparob@gmail.com>, "pgsql-general@postgresql.org" <pgsql-general@postgresql.org>
Subject: Re: [GENERAL] Postgres 9.6 fails to start on VMWare
On Mon, Oct 23, 2017 at 3:14 AM, Martin Moore <martin.moore@avbrief.com> wrote:
Same server. I tried a few times.
I didn’t move the db separately, but did a ‘dd’ to copy the disk to an imagefile which was converted and loaded into VMWare.
I ‘believed’ that this should keep the low level disk structure the same, but if this has corrupted the files I can drop, dump and restore, in which case how do I ‘drop’ the DB without postgres running?
Ta,
Martin.
Was the server you were backing up shut down or in backup mode when you did the 'dd' copy?
--
Mike Nolan
It was running – not sure how dd handles this. Maybe badly… ☺
From: Michael Nolan <htfoot@gmail.com>
Date: Monday, 23 October 2017 at 15:52
To: Martin Moore <martin.moore@avbrief.com>
Cc: rob stone <floriparob@gmail.com>, "pgsql-general@postgresql.org" <pgsql-general@postgresql.org>
Subject: Re: [GENERAL] Postgres 9.6 fails to start on VMWare
On Mon, Oct 23, 2017 at 3:14 AM, Martin Moore <martin.moore@avbrief.com> wrote:
Same server. I tried a few times.
I didn’t move the db separately, but did a ‘dd’ to copy the disk to an imagefile which was converted and loaded into VMWare.
I ‘believed’ that this should keep the low level disk structure the same, but if this has corrupted the files I can drop, dump and restore, in which case how do I ‘drop’ the DB without postgres running?
Ta,
Martin.
Was the server you were backing up shut down or in backup mode when you did the 'dd' copy?
--
Mike Nolan
OK, cheers.
How can I remove the db so I can restore it properly?
From: Scott Mead <scottm@openscg.com>
Date: Monday, 23 October 2017 at 16:35
To: Martin Moore <martin.moore@avbrief.com>
Cc: Michael Nolan <htfoot@gmail.com>, "pgsql-general@postgresql.org" <pgsql-general@postgresql.org>
Subject: Re: [GENERAL] Postgres 9.6 fails to start on VMWare
On Mon, Oct 23, 2017 at 11:26 AM, Martin Moore <martin.moore@avbrief.com> wrote:
It was running – not sure how dd handles this. Maybe badly… ☺
it doesn't handle it at all. This would be the cause of your issue.
--Scott
From: Michael Nolan <htfoot@gmail.com>
Date: Monday, 23 October 2017 at 15:52
To: Martin Moore <martin.moore@avbrief.com>
Cc: rob stone <floriparob@gmail.com>, "pgsql-general@postgresql.org" <pgsql-general@postgresql.org>
Subject: Re: [GENERAL] Postgres 9.6 fails to start on VMWare
On Mon, Oct 23, 2017 at 3:14 AM, Martin Moore <martin.moore@avbrief.com> wrote:
Same server. I tried a few times.
I didn’t move the db separately, but did a ‘dd’ to copy the disk to an imagefile which was converted and loaded into VMWare.
I ‘believed’ that this should keep the low level disk structure the same, but if this has corrupted the files I can drop, dump and restore, in which case how do I ‘drop’ the DB without postgres running?
Ta,
Martin.
Was the server you were backing up shut down or in backup mode when you did the 'dd' copy?
--
Mike Nolan
--
--
Scott Mead
Sr. Architect
OpenSCG
On Mon, 23 Oct 2017 09:14:18 +0100, Martin Moore <martin.moore@avbrief.com> wrote: >Same server. I tried a few times. > >I didn’t move the db separately, but did a ‘dd’ to copy the disk >to an imagefile which was converted and loaded into VMWare. If you copied the boot device that way while the system was running, then you are lucky it even starts in the new environment. What you did is only [really] safe to do with a data volume ... and the volume should be mounted R/O while it is being copied. Doesn't GCloud provide a way to export drive images? [He asks naively, never having used it.] >I ‘believed’ that this should keep the low level disk structure the >same, but if this has corrupted the files I can drop, dump and >restore, in which case how do I ‘drop’ the DB without postgres >running? Move/rename the PG data directory, then use initdb to create a new cluster. You'll have to reload your databases from backups. But I would be concerned that the disk structure is damaged. I would run e2fsck on it - and if there are lots of errors found I wouldn't use it. George -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
On 23/10/2017, 17:17, "George Neuner" <gneuner2@comcast.net> wrote: >Doesn't GCloud provide a way to export drive images? [He asks naively, never having used it.] Nope – just the dd method (although this doesn’t work on VMWare, so you need to use a VWM utility on a Win pc to get it).I’m pretty sure Google use VMW, so it’s pretty poor! > Move/rename the PG data directory, then use initdb to create a new cluster. You'll have to reload your databases frombackups. Cheers. I’m going off the idea of using VMs very quickly as I can see no real advantage and plenty of grief for my use case. Consider this question resolved ( -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general