Hi Andy,
As you've noticed, the config option is provided separately to each
slon daemon in your service, so a slon before 2.2.7 isn't going to know about
the option and so will still run the schema check. We also use a single
provider cluster, and in our upgrade process, the replicas (slaves) are
upgraded first. That worked for our upgrade from 2.2.4 (using an alpha version
of the 2.2.7 changes.)
The option in the code is a boolean. We should fix the doc.
Tom (
On 8/31/18, 9:56 AM, "Andy Dossett" <[email protected]> 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.
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
_______________________________________________
Slony1-general mailing list
[email protected]
http://lists.slony.info/mailman/listinfo/slony1-general
