Re: Pgsql troubleshooting & Iscsi - Mailing list pgsql-general

From Alberto Cabello Sánchez
Subject Re: Pgsql troubleshooting & Iscsi
Date
Msg-id 20160218073201.GA2602@marmota.unex.es
Whole thread Raw
In response to Pgsql troubleshooting & Iscsi  (proj@free.fr)
Responses Re: Pgsql troubleshooting & Iscsi
List pgsql-general
On Wed, Feb 17, 2016 at 06:07:29PM +0100, proj@free.fr wrote:
> Hi everybody,
>
> I installed a postgresql database on Redhat 7.1 and I decided to move the
> database on an ISCSI device (LUN) inside a logical volume, mounted at
> starting of the machine (xfs formatted). The mounting point is /var/lib/pgsql
>
> At the boot of the server, postgresql.service is in failed status.
>
> In messages.log :
> systemd: mounting /var/lib/pgsql
>  starting PostgreSQL database server
>  kernel sdv: unknown partition table
>  sd 2:0:0:0: [sdb] attached SCSI disk
>  xfs (dm-4): Mounting V4 Filesystem
>  postgresql-check-db-dir: "/var/lib/pgsql/data" is missing or empty
>  postgresql.service: control process exited, code=exited status=1
>  Failed to start PostgreSQL database server.
>
>
> When I'm logged on the server, if it try to start manually the database :
> systemctl start postgresql --> OK (and I don't lose any data, database is
> available)
>
> I think it's a problem of order in the boot process : network service must
> be started, then iscsi, then lvm etc... So I tried to force dependencies
> on the /usr/lib/systemd/system/postgresql.service adding
> "After=lvm-pgscan.service iscsi.service" etc... but the result is
> the same : failure in starting postgresql
>
> Any ideas ?

Take a look at this thread:
http://www.gossamer-threads.com/lists/linux/kernel/1332888

I'm not an XFS guru, but it seems that XFS does a bunch of checks just
on/after mount, so perhaps PgSQL cannot access /var/lib/pgsql/data
immediately.

You could igive it a try forcing some delay in systemd conf file, or
tweaking the PgSQL startup script.

--
Alberto Cabello Sánchez
Universidad de Extremadura


pgsql-general by date:

Previous
From: David Rowley
Date:
Subject: Re: BRIN Usage
Next
From: Sridhar N Bamandlapally
Date:
Subject: JDBC behaviour