public inbox for [email protected]help / color / mirror / Atom feed
Re: Linked directory or explicit reference 3+ messages / 2 participants [nested] [flat]
* Re: Linked directory or explicit reference @ 2024-05-01 00:31 Ron Johnson <[email protected]> 2024-05-02 04:50 ` Re: Linked directory or explicit reference Senor Cervesa <[email protected]> 0 siblings, 1 reply; 3+ messages in thread From: Ron Johnson @ 2024-05-01 00:31 UTC (permalink / raw) To: [email protected] <[email protected]> On Tue, Apr 30, 2024 at 7:00 PM Senor Cervesa <[email protected]> wrote: > Hi All; > > When doing an initial install of PostgreSQL on RHEL 7 or 8 derived OS via > rpm, what are pros, cons and recommendations of these 2 procedures for > utilizing a second disk? > > Secondary SSD or RAID mounted at /disk2. > > Option #1 > > 1. install the rpm which creates basic user and home > 2. Create symlink /var/lib/pgsql/15/data --> /disk2/data > 3. initdb with no special options > > Or Option #2 > > 1. install the rpm which creates basic user and home > 2. initdb with --pgdata=/disk2/data > Probably using included 'postgresql-12-setup' script > > I also link /var/lib/pgsql/data --> ../15/data so automation can > reference postgresql.conf without knowing version (legacy stuff). > In my experience,The PgBackRest restore feature does not like symlinks. > The install is automated with a bash script which handles several options > including whether there is a second disk for DB. Scripting the install with > or without the second disk is straight forward but I'm concerned with > either scenario causing unforeseen differences. > > I don't think there's a benefit to using tablespace here but I have no > experience with it. The systemd service is configured with a dependency on > the disk mount so I don't think there are different risks for starting > postgres with missing data directory. > > I've run postgres in both scenarios and not had any issues. I'm interested > in comments from others on their experience using these or other options. > Is the mount point just "/disk2" when using "--pgdata=/disk2/data"? I've gotten "directory not empty" errors when the mount point is "/Database/x.y/data". ^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: Linked directory or explicit reference 2024-05-01 00:31 Re: Linked directory or explicit reference Ron Johnson <[email protected]> @ 2024-05-02 04:50 ` Senor Cervesa <[email protected]> 2024-05-02 09:24 ` Re: Linked directory or explicit reference Ron Johnson <[email protected]> 0 siblings, 1 reply; 3+ messages in thread From: Senor Cervesa @ 2024-05-02 04:50 UTC (permalink / raw) To: [email protected] On 4/30/2024 17:31, Ron Johnson wrote: > On Tue, Apr 30, 2024 at 7:00 PM Senor Cervesa > <[email protected]> wrote: > > Hi All; > > When doing an initial install of PostgreSQL on RHEL 7 or 8 derived > OS via rpm, what are pros, cons and recommendations of these 2 > procedures for utilizing a second disk? > > Secondary SSD or RAID mounted at /disk2. > > Option #1 > > 1. install the rpm which creates basic user and home > 2. Create symlink /var/lib/pgsql/15/data --> /disk2/data > 3. initdb with no special options > > Or Option #2 > > 1. install the rpm which creates basic user and home > 2. initdb with --pgdata=/disk2/data > Probably using included 'postgresql-12-setup' script > > I also link /var/lib/pgsql/data --> ../15/data so automation can > reference postgresql.conf without knowing version (legacy stuff). > > > In my experience,The PgBackRest restore feature does not like symlinks. I hadn't considered that and it's the kind of experience feedback I'm looking for. It won't be an issue for me though. > > The install is automated with a bash script which handles several > options including whether there is a second disk for DB. Scripting > the install with or without the second disk is straight forward > but I'm concerned with either scenario causing unforeseen differences. > > I don't think there's a benefit to using tablespace here but I > have no experience with it. The systemd service is configured with > a dependency on the disk mount so I don't think there are > different risks for starting postgres with missing data directory. > > I've run postgres in both scenarios and not had any issues. I'm > interested in comments from others on their experience using these > or other options. > > Is the mount point just "/disk2" when using "--pgdata=/disk2/data"? > I've gotten "directory not empty" errors when the mount point is > "/Database/x.y/data". > When linked, it looks like: [root@test110 pgsql]# ll /var/lib/pgsql/15/data lrwxrwxrwx. 1 root root 12 May 1 05:21 /var/lib/pgsql/15/data -> /disk2/data/ I'm not sure what would trigger "directory not empty". When running initdb there is nothing under data. I could see a problem with a symlink throwing that message as a catchall though. I haven't run across any problems yet. Thank you Ron Johnson for the feedback. ^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: Linked directory or explicit reference 2024-05-01 00:31 Re: Linked directory or explicit reference Ron Johnson <[email protected]> 2024-05-02 04:50 ` Re: Linked directory or explicit reference Senor Cervesa <[email protected]> @ 2024-05-02 09:24 ` Ron Johnson <[email protected]> 0 siblings, 0 replies; 3+ messages in thread From: Ron Johnson @ 2024-05-02 09:24 UTC (permalink / raw) To: Senor Cervesa <[email protected]>; +Cc: [email protected] On Thu, May 2, 2024 at 12:50 AM Senor Cervesa <[email protected]> wrote: [snip] > I'm not sure what would trigger "directory not empty". The lost+found directory. ^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2024-05-02 09:24 UTC | newest] Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2024-05-01 00:31 Re: Linked directory or explicit reference Ron Johnson <[email protected]> 2024-05-02 04:50 ` Senor Cervesa <[email protected]> 2024-05-02 09:24 ` Ron Johnson <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox