On Fri, 31 Aug 2018, Andy Dossett wrote:
I have carried out a basic test with the master at 2.2.7, with
enable_version_check ‘off’, and a slave at 2.2.3. The slave still checks
versions.
My conclusion is that this option only has any value when master and slave
are at, or above, 2.2.7. The only way I can see it working for older
versions is if the master holds the version number of the slave and ‘lies’
by reporting the stored version number when queried by the slave.
I think 'version number of the slave' is a bit misleading.
You have slonik, slon, and the stored functions.
Only the stored functions are directly tied to the version number 'of the
slave'.
You could do something like the following.
Step 1) Upgrade all your slon processes to be 2.2.7 and set
enable_version_check=false. Slon should start.
Step 2) Upgrade your slonik instance
Step 3) Upgrade each database and then run UPDATE FUNCTIONS on each
Set enable_version_check=true again
This of course should be tested.
Here’s some snippets from the logs;
2.2.7 (master)
2018-08-31 14:00:05 BST [20062] CONFIG main: slon version 2.2.7 starting up
2018-08-31 14:00:05 BST [20063] CONFIG main: Boolean option
enable_version_check = 0
2.2.3 (slave)
2018-08-31 14:09:17 BST [10640] CONFIG version for "host=xxx.xxx.xxx.xxx
dbname=posdb user=postgres port=5432 password=abcdefg" is 90603
2018-08-31 14:09:17 BST [10640] ERROR Slony-I schema version is 2.2.7
2018-08-31 14:09:17 BST [10640] ERROR please upgrade Slony-I schema to version
2.2.3
2018-08-31 14:09:17 BST [10640] ERROR Slony-I module version is 2.2.7
2018-08-31 14:09:17 BST [10640] ERROR please upgrade Slony-I shared module to
version 2.2.3
2018-08-31 14:09:17 BST [10640] ERROR remoteListenThread_1:
db_checkSchemaVersion() failed
A few other things from the log.
Both 2.2.3 and 2.2.7 warn that three config options are missing, yet complain
that those same options are present! Note, no line break for the ‘not found’
warning.
2018-08-31 14:00:05 BST [0] WARN conf option sync_max_rowsize not found2018-08-31
14:00:05 BST [0] WARN unrecognized configuration parameter "sync_max_rowsize"
2018-08-31 14:00:05 BST [0] WARN conf option sync_max_largemem not found2018-08-31
14:00:05 BST [0] WARN unrecognized configuration parameter "sync_max_largemem"
2018-08-31 14:00:05 BST [0] WARN conf option desired_sync_time not found2018-08-31
14:00:05 BST [0] WARN unrecognized configuration parameter "desired_sync_time"
The log says that enable_version_check is a boolean option – the documentation
says it is integer.
Should the password in the reporting of the connection string be obfuscated?
-----Original Message-----
From: Steve Singer <[email protected]>
Sent: 27 August 2018 02:28
To: [email protected]
Cc: [email protected]
Subject: Re: [Slony1-general] enable_version_check
On Fri, 24 Aug 2018, [email protected] wrote:
Hi
We are currently running our master server on SuSE 10 with Postgres
9.3 and Slony 2.2.3. Our slaves are running on CentOS, also with Postgres 9.3
and Slony 2.2.3.
We are running a project to upgrade the master to SuSE 12 and Postgres
9.6. Unfortunately Slony 2.2.3 would not install so we went up to
2.2.6. Unfortunately this means that we have to upgrade the slaves to 2.2.6 as
well.
However, 2.2.7 has just been released which includes the enable_version_check
feature.
If we went up to 2.2.7 on the master and turned version checking off,
would this enable master and slaves to replicate, or would the version checking
in the slave prevent it?
If turning off version checking does allow replication, are 2.2.3 and 2.2.7
compatible with each other?
You should test it but there is a good chance data replication will work
between them. Just looking at the release notes I don't see anything that
would obviously break data replication. Configuration events, including
failovers and DDL replication did have some changes though.
Thanks
Andy
_______________________________________________
Slony1-general mailing list
[email protected]
http://lists.slony.info/mailman/listinfo/slony1-general
