PostgreSQL mirroring from RPM install to Source install
Good day to you!
I've got a PostgreSQL database server version 9.4.1 installed on an OEL 6 server. I have a second PostgreSQL database server version 9.4.1 running on an identical OEL 6 server. The first PostgreSQL was installed by system admins using RPM. The second PostgreSQL was installed from source, using --prefix to set the user and path to the installation. I want to run a mirror on the second server.
I do not have root, and cannot get root on these systems. Also, the sys admins now refuse to install PostgreSQL anywhere. This is really annoying!
I've followed all the instructions found here:
https://www.postgresql.org/docs/9.4/static/warm-standby.html#STREAMING-REPLICATION
The slave, running PostgreSQL 9.4.1 built from source, runs fine after I've run initdb and set things up.
When I replace its data directory as part of the mirroring instructions, using pg_basebackup, PostgreSQL won't start.
I get a checksum error, from pg_ctl.
2016-12-15 08:27:14.520 PST >FATAL: incorrect checksum in control file
My guess is that despite the versions being the same, the binaries are different.
Is there a way to make this work, or should I give up? I wonder if the sys admins take bribes...
THANKS in advance!!
--
Richard Brosnahan
Richard Brosnahan <broz@mac.com> writes:
I've got a PostgreSQL database server version 9.4.1 installed on an OEL 6 server. I have a second PostgreSQL database server version 9.4.1 running on an identical OEL 6 server. The first PostgreSQL was installed by system admins using RPM. The second PostgreSQL was installed from source, using --prefix to set the user and path to the installation. I want to run a mirror on the second server.
I do not have root, and cannot get root on these systems. Also, the sys admins now refuse to install PostgreSQL anywhere. This is really annoying!
I've followed all the instructions found here:
https://www.postgresql.org/docs/9.4/static/warm-standby.html#STREAMING-REPLICATION
The slave, running PostgreSQL 9.4.1 built from source, runs fine after I've run initdb and set things up.
When I replace its data directory as part of the mirroring instructions, using pg_basebackup, PostgreSQL won't start.
I get a checksum error, from pg_ctl.
2016-12-15 08:27:14.520 PST >FATAL: incorrect checksum in control file
My guess is that despite the versions being the same, the binaries are different.
You could try using pg_controldata to compare the pg_control contents;
it should be willing to print field values even if it thinks the checksum
is bad. It would be interesting to see (a) what the master's
pg_controldata prints about its pg_control, (b) what the slave's
pg_controldata prints about pg_control from a fresh initdb there, and
(c) what the slave's pg_controldata prints about the copied pg_control.
I am a little suspicious about whether the PG versions are really the same.
There's a bug in the 9.5.x series that it will issue a checksum complaint
not a version-number complaint if started against a 9.4.x pg_control.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
The slave:
$ pg_controldata --version
pg_controldata (PostgreSQL) 9.4.1
$ echo $PGDATA
/apps/database/postgresql-data
$ pg_controldata $PGDATA
WARNING: Calculated CRC checksum does not match value stored in file.
Either the file is corrupt, or it has a different layout than this program
is expecting. The results below are untrustworthy.
Segmentation fault (core dumped)
The master:
$ echo $PGDATA
/var/lib/pgsql/9.4/data
$ pg_controldata --version
pg_controldata (PostgreSQL) 9.4.1
$ pg_controldata $PGDATA
pg_control version number: 942
Catalog version number: 201409291
Database system identifier: 6158049305757004233
Database cluster state: in production
pg_control last modified: Thu 15 Dec 2016 11:19:04 AM PST
Latest checkpoint location: 44/E8FDC2F0
Prior checkpoint location: 44/E8EEE07C
Latest checkpoint's REDO location: 44/E8F72A4C
Latest checkpoint's REDO WAL file: 0000000100000044000000E8
Latest checkpoint's TimeLineID: 1
Latest checkpoint's PrevTimeLineID: 1
Latest checkpoint's full_page_writes: on
Latest checkpoint's NextXID: 0/231975962
Latest checkpoint's NextOID: 602794
Latest checkpoint's NextMultiXactId: 86
Latest checkpoint's NextMultiOffset: 171
Latest checkpoint's oldestXID: 40676549
Latest checkpoint's oldestXID's DB: 36696
Latest checkpoint's oldestActiveXID: 231975962
Latest checkpoint's oldestMultiXid: 1
Latest checkpoint's oldestMulti's DB: 421289
Time of latest checkpoint: Thu 15 Dec 2016 11:18:39 AM PST
Fake LSN counter for unlogged rels: 0/1
Minimum recovery ending location: 0/0
Min recovery ending loc's timeline: 0
Backup start location: 0/0
Backup end location: 0/0
End-of-backup record required: no
Current wal_level setting: hot_standby
Current wal_log_hints setting: off
Current max_connections setting: 200
Current max_worker_processes setting: 8
Current max_prepared_xacts setting: 0
Current max_locks_per_xact setting: 64
Maximum data alignment: 4
Database block size: 8192
Blocks per segment of large relation: 131072
WAL block size: 8192
Bytes per WAL segment: 16777216
Maximum length of identifiers: 64
Maximum columns in an index: 32
Maximum size of a TOAST chunk: 2000
Size of a large-object chunk: 2048
Date/time type storage: 64-bit integers
Float4 argument passing: by value
Float8 argument passing: by reference
Data page checksum version: 0
The seg fault on the slave looks suspicious.
Understood that it's way easier to do the mirroring when the directory paths agree. In my case, I can't line them up, due to restrictions.
It's really looking like I'll need to do something more drastic, like blackmail a sys admin to coerce him to install PostgreSQL on the slave using RPM.
Thanks for the help!
--
Richard Brosnahan
On Dec 15, 2016, at 10:01 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Richard Brosnahan <broz@mac.com> writes:
I've got a PostgreSQL database server version 9.4.1 installed on an OEL 6 server. I have a second PostgreSQL database server version 9.4.1 running on an identical OEL 6 server. The first PostgreSQL was installed by system admins using RPM. The second PostgreSQL was installed from source, using --prefix to set the user and path to the installation. I want to run a mirror on the second server.
I do not have root, and cannot get root on these systems. Also, the sys admins now refuse to install PostgreSQL anywhere. This is really annoying!
I've followed all the instructions found here:
https://www.postgresql.org/docs/9.4/static/warm-standby.html#STREAMING-REPLICATION
The slave, running PostgreSQL 9.4.1 built from source, runs fine after I've run initdb and set things up.
When I replace its data directory as part of the mirroring instructions, using pg_basebackup, PostgreSQL won't start.
I get a checksum error, from pg_ctl.
2016-12-15 08:27:14.520 PST >FATAL: incorrect checksum in control file
My guess is that despite the versions being the same, the binaries are different.
You could try using pg_controldata to compare the pg_control contents;
it should be willing to print field values even if it thinks the checksum
is bad. It would be interesting to see (a) what the master's
pg_controldata prints about its pg_control, (b) what the slave's
pg_controldata prints about pg_control from a fresh initdb there, and
(c) what the slave's pg_controldata prints about the copied pg_control.
I am a little suspicious about whether the PG versions are really the same.
There's a bug in the 9.5.x series that it will issue a checksum complaint
not a version-number complaint if started against a 9.4.x pg_control.
regards, tom lane
Import Notes
Resolved by subject fallback
Richard Brosnahan <broz@mac.com> =?utf-8?B?UmU6IFtHRU5FUkFMXSBQb3N0Z3JlU1FMIG1pcnJvcmluZyBmcm9tIFJQTSBp?= =?utf-8?B?bnN0YWxsIHRvIFNvdXJjZSBpbnN0YWxs?= writes:
The slave:
$ pg_controldata --version
pg_controldata (PostgreSQL) 9.4.1
$ echo $PGDATA
/apps/database/postgresql-data
$ pg_controldata $PGDATA
WARNING: Calculated CRC checksum does not match value stored in file.
Either the file is corrupt, or it has a different layout than this program
is expecting. The results below are untrustworthy.
Segmentation fault (core dumped)
Wow --- a core dump in pg_controldata is *really* unexpected, since it's
just printing some scalar fields. I can easily believe garbage out, but
a crash is harder. I'm beginning to think that there's something wrong
with your hand-rolled build, though I have no idea what.
Can you get a stack trace out of that? Should be enough to do
$ gdb path/to/pg_controldata
gdb> run /apps/database/postgresql-data
(wait for it to report segfault)
gdb> bt
Understood that it's way easier to do the mirroring when the directory paths agree. In my case, I can't line them up, due to restrictions.
That doesn't seem to be your problem, at least not yet.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
gdb is not available on this machine. Neither which or locate could find it. The servers we're given are truly, shockingly, stripped down models.
At this point, I believe my best course of action is to twist some sys admin arms and get a properly installed PostgreSQL on this machine. Even if I manage to get the mirror working with the current install, there's a real risk something bad will happen. I can't trust this source built version.
Sigh
Thanks again for your help.
--
Richard Brosnahan
On Dec 15, 2016, at 01:00 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Richard Brosnahan <broz@mac.com> =?utf-8?B?UmU6IFtHRU5FUkFMXSBQb3N0Z3JlU1FMIG1pcnJvcmluZyBmcm9tIFJQTSBp?= =?utf-8?B?bnN0YWxsIHRvIFNvdXJjZSBpbnN0YWxs?= writes:
The slave:
$ pg_controldata --version
pg_controldata (PostgreSQL) 9.4.1
$ echo $PGDATA
/apps/database/postgresql-data
$ pg_controldata $PGDATA
WARNING: Calculated CRC checksum does not match value stored in file.
Either the file is corrupt, or it has a different layout than this program
is expecting. The results below are untrustworthy.
Segmentation fault (core dumped)
Wow --- a core dump in pg_controldata is *really* unexpected, since it's
just printing some scalar fields. I can easily believe garbage out, but
a crash is harder. I'm beginning to think that there's something wrong
with your hand-rolled build, though I have no idea what.
Can you get a stack trace out of that? Should be enough to do
$ gdb path/to/pg_controldata
gdb> run /apps/database/postgresql-data
(wait for it to report segfault)
gdb> bt
Understood that it's way easier to do the mirroring when the directory paths agree. In my case, I can't line them up, due to restrictions.
That doesn't seem to be your problem, at least not yet.
regards, tom lane
Import Notes
Resolved by subject fallback
On Thu, 15 Dec 2016 16:42:13 +0000 (GMT)
Richard Brosnahan <broz@mac.com> wrote:
I get a checksum error, from pg_ctl.
2016-12-15 08:27:14.520 PST >FATAL: incorrect checksum in control file
Hi Richard,
Not sure if it applies, but just in case, I got this error when trying to use a cluster copied from one machine to another one because they had different processors.
It worked after I used a machine with the same processor.
--
Bien à vous, Vincent Veyron
https://marica.fr/
Gestion des sinistres assurances, des dossiers contentieux et des contrats pour le service juridique
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
[re-post, originally sent with wrong username]
On Thu, 15 Dec 2016 16:42:13 +0000 (GMT)
Richard Brosnahan <broz@mac.com> wrote:
I get a checksum error, from pg_ctl.
2016-12-15 08:27:14.520 PST >FATAL: incorrect checksum in control file
Hi Richard,
Not sure if it applies, but just in case, I got this error when trying to use a cluster copied from one machine to another one because they had different processors.
It worked after I used a machine with the same processor.
--
Bien à vous, Vincent Veyron
https://marica.fr/
Gestion des sinistres assurances, des dossiers contentieux et des contrats pour le service juridique
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On 12/15/2016 2:16 PM, Richard Brosnahan wrote:
gdb is not available on this machine. Neither which or locate could
find it. The servers we're given are truly, shockingly, stripped down
models.
what OS is this, what compiler toolchain did you use to build postgres
on them?
--
john r pierce, recycling bits in santa cruz
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general