Re: perl path issue

On 5/14/19 2:51 AM, Prakash Ramakrishnan wrote:
> Hi Ravi,
>
> Not , am saying we have the daily backup and full backup in prod server
> only and there is one database like a4 the db size is 1.5TB.
> so am not restore again in prod .
> Am taking directly single backup restore in dev its means in dev server
> only restore the database in new cluster.
> existing cluster we cant restore backups.
> so thats why am struggling the issue getting some perl issue and remote
> option terminated otherwise wont disturb anyone and need to solve this
> issue.
> this activity has been planned every 3 weeks.

I think to make this clearer for everyone a graphical layout might help.
Something like:

prod Pg db --pgBackRest--> some_host/some_dir/some_file @daily

dev Pg db <--pgBackRest -- some_host/some_dir/some_file @3 weeks

Of course the above is just made up.

What I think we know so far, please check and correct as necessary:

1) Prod server CentOS 7, Postgres 10 from EDB installer, pgBackRest from
PGDG repo

2) Dev server CentOS 7, Postgres 10 from EDB installer, pgBackRest from
PGDG repo

3) sydcosausd001.enterprisenet.org is your dev

4) sydcosafpp001.enterprisenet.org is your prod

5) pgBackRest works on prod server.

6) pgBackRest fails on dev server with:

Can't load '/usr/lib64/perl5/vendor_perl/auto/DBD/Pg/Pg.so' for module
DBD::Pg: libpq.so.5: cannot open shared object file: No such file or
directory at /usr/lib64/perl5/DynaLoader.pm line 190.

7) ldd of Pg.so. From dev correct?:

ldd /usr/lib64/perl5/vendor_perl/auto/DBD/Pg/Pg.so
linux-vdso.so.1 => (0x00007fffddd8f000)
libpq.so.5 => /usr/lib64/perl5/CORE/libpq.so.5 (0x00007f5ecdbd6000)
libm.so.6 => /lib64/libm.so.6 (0x00007f5ecd8d4000)
libc.so.6 => /lib64/libc.so.6 (0x00007f5ecd507000)
libssl.so.1.0.0 => /usr/lib64/perl5/CORE/libssl.so.1.0.0
(0x00007f5ecd297000)
libcrypto.so.1.0.0 => /usr/lib64/perl5/CORE/libcrypto.so.1.0.0
(0x00007f5ecce5d000)
libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2
(0x00007f5eccc10000)
libldap_r-2.4.so.2 => /lib64/libldap_r-2.4.so.2
(0x00007f5ecc9b1000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f5ecc795000)
/lib64/ld-linux-x86-64.so.2 (0x00007f5ece056000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f5ecc591000)
libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007f5ecc2a8000)
libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007f5ecc075000)
libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007f5ecbe71000)
libkrb5support.so.0 => /lib64/libkrb5support.so.0
(0x00007f5ecbc61000)
libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007f5ecba5d000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f5ecb844000)
liblber-2.4.so.2 => /lib64/liblber-2.4.so.2 (0x00007f5ecb635000)
libsasl2.so.3 => /lib64/libsasl2.so.3 (0x00007f5ecb418000)
libssl.so.10 => /lib64/libssl.so.10 (0x00007f5ecb1a6000)
libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007f5ecad45000)
libssl3.so => /lib64/libssl3.so (0x00007f5ecaaf3000)
libsmime3.so => /lib64/libsmime3.so (0x00007f5eca8cc000)
libnss3.so => /lib64/libnss3.so (0x00007f5eca59f000)
libnssutil3.so => /lib64/libnssutil3.so (0x00007f5eca370000)
libplds4.so => /lib64/libplds4.so (0x00007f5eca16c000)
libplc4.so => /lib64/libplc4.so (0x00007f5ec9f67000)
libnspr4.so => /lib64/libnspr4.so (0x00007f5ec9d29000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f5ec9b02000)
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f5ec98cb000)
libz.so.1 => /lib64/libz.so.1 (0x00007f5ec96b5000)
librt.so.1 => /lib64/librt.so.1 (0x00007f5ec94ad000)
libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f5ec924b000)
libfreebl3.so => /lib64/libfreebl3.so (0x00007f5ec9048000)
postgres(at)sydcosausd001(dot)enterprisenet(dot)org:/home/postgres
>
> Regards,
> Prakash.R
>
> On Tue, May 14, 2019 at 3:10 PM Ravi Krishna <ravi_krishna(at)aol(dot)com
> <mailto:ravi_krishna(at)aol(dot)com>> wrote:
>
> >
> > Note - if am taking same prod single database backup and restore
> in new cluster no use for us and it will take more time.
> > so business and team they need every 3 weeks for restore in dev
> server one single database and cant we do it in pg_dump and restore .
> > They want using pgbackrest tool the db size is huge so tats why
> am trying remote restore option.
>
> I am baffled.  Are you telling that you are restoring it back on
> prod (using remote restore option),
> which effectively means overwriting prod db.  Also you never gave
> this information until now. You
> should have shared full details.
>
> I have not used pgbackest, but I have read the FAQ. If I am not
> mistaken it has single db restore option too. So you can restore
> the db in dev.
>
>
>
>
> --
>
>
>
> Thanks,
> Prakash.R
> PostgreSQL - Offshore DBA support TCS / Nielsen Infrastructure Team On
> call : +91-8939599426

--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com