IMO, tout en effectuant des mises à niveau de version majeures, il devrait y avoir un plan de secours approprié, car juste au cas où l'application se révélerait boguée ou ne fonctionnerait pas bien sur la version mise à niveau, nous devrions être en mesure de revenir immédiatement à l'ancienne version. Slony-I fournit une telle fonctionnalité de retour en arrière. Cet article montre une mise à niveau minimale des temps d'arrêt, y compris les étapes de basculement/basculement.
Avant de passer à la démo, une étape importante à noter, les colonnes de type de données bytea antérieures à la version PG 9.0.x utilisaient pour stocker les données au format ESCAPE et les versions ultérieures au format HEX. Lors de l'exécution du basculement (version plus récente vers une version plus ancienne), ce type de différences de format bytea n'est pas pris en charge par Slony-I, par conséquent, le format ESCAPE doit être conservé pendant toute la durée de la mise à niveau, sinon vous risquez de rencontrer une erreur :
ERROR remoteWorkerThread_1_1: error at end of COPY IN: ERROR: invalid input syntax for type bytea
CONTEXT: COPY sl_log_1, line 1: "1 991380 1 100001 public foo I 0 {id,500003,name,"A ",b,"\\x41"}"
ERROR remoteWorkerThread_1: SYNC aborted
Pour corriger, aucune modification requise sur PG 8.4.x mais sur PG 9.3.5, le paramètre bytea_output doit être défini de HEX à ESCAPE, comme indiqué. Nous pouvons le définir au niveau du cluster ($PGDATA/postgresql.conf) ou au niveau de l'utilisateur (ALTER TABLE… SET), j'ai préféré opter pour des modifications au niveau de l'utilisateur.
slavedb=# alter user postgres set bytea_output to escape;
ALTER ROLE
Continuons avec les étapes de mise à niveau. Vous trouverez ci-dessous les détails de mes deux versions de serveur utilisées dans cette démo, modifiez-les en fonction de la configuration de votre serveur si vous essayez :
Origin Node (Master/Primary are called as Origin) Subscriber Node (Slave/Secondary are called as Subscriber)
------------------------------------------------- ----------------------------------------------------------
Host IP : 192.168.22.130 192.168.22.131
OS Version : RHEL 6.5 64 bit RHEL 6.5 64 bit
PG Version : 8.4.22 (5432 Port) 9.3.5 (5432 Port)
Slony Vers. : 2.2.2 2.2.2
PG Binaries : /usr/local/pg84/bin /opt/PostgreSQL/9.3/
Database : masterdb slavedb
PK Table : foo(id int primary key, name char(20), image bytea) ...restore PK tables structure from Origin...
Pour une compréhension simple et une mise en œuvre facile, j'ai divisé la démo en trois sections
1. Compilation pour les binaires Slony-I avec les versions PostgreSQL2. Création de scripts de réplication et exécution
3. Test de basculement/basculement.
1. Compilation pour les binaires Slony-I avec la version PostgreSQL
Téléchargez les sources de Slony-I à partir d'ici et effectuez l'installation des sources avec les binaires PostgreSQL sur les nœuds d'origine et d'abonné.
On Origin Node:
# tar -xvf slony1-2.2.2.tar.bz2
# cd slony1-2.2.2
./configure --with-pgbindir=/usr/local/pg84/bin
--with-pglibdir=/usr/local/pg84/lib
--with-pgincludedir=/usr/local/pg84/include
--with-pgpkglibdir=/usr/local/pg84/lib/postgresql
--with-pgincludeserverdir=/usr/local/pg84/include/postgresql/
make
make install
On Subscriber Node: (assuming PG 9.3.5 installed)
# tar -xvf slony1-2.2.2.tar.bz2
# cd slony1-2.2.2
./configure --with-pgconfigdir=/opt/PostgreSQL/9.3/bin
--with-pgbindir=/opt/PostgreSQL/9.3/bin
--with-pglibdir=/opt/PostgreSQL/9.3/lib
--with-pgincludedir=/opt/PostgreSQL/9.3/include
--with-pgpkglibdir=/opt/PostgreSQL/9.3/lib/postgresql
--with-pgincludeserverdir=/opt/PostgreSQL/9.3/include/postgresql/server/
--with-pgsharedir=/opt/PostgreSQL/9.3/share
make
make install
2. Création de scripts de réplication et exécution
Pour configurer la réplication, nous devons créer quelques scripts prenant en charge la réplication, y compris le basculement/basculement.
1. initialize.slonik – Ce script contient les informations de connexion des nœuds Origin/Subscriber.
2. create_set.slonik – Ce script contient toutes les tables PK d'origine qui se répliquent sur le nœud de l'abonné.
3. subscribe_set.slonik – Ce script commence à répliquer les données des ensembles vers le nœud de l'abonné.
4. switchover.slonik – Ce script aide à déplacer le contrôle de l'origine à l'abonné.
5. switchback.slonik - Ce script permet de basculer le contrôle de l'abonné vers l'origine.
Enfin, deux autres scripts de démarrage "start_OriginNode.sh" et "start_SubscriberNode.sh" qui démarre les processus slon en fonction des binaires compilés sur les nœuds Origin/Subscriber.
Téléchargez tous les scripts à partir d'ici.
Voici les exemples de données sur Origin Node (8.4.22) dans Foo Table avec une colonne de type de données bytea, que nous allons répliquer sur Subscriber Node (9.3.5) à l'aide de scripts créés.
masterdb=# select * from foo;
id | name | image
----+----------------------+-------
1 | Raghav | test1
2 | Rao | test2
3 | Rags | test3
(3 rows)
Appelons les scripts un par un pour configurer la réplication. RAPPELEZ-VOUS QUE TOUS LES SCRIPTS SLONIK DOIVENT ÊTRE EXÉCUTÉS UNIQUEMENT SUR LE NŒUD D'ORIGINE, SAUF "start_OriginNode.sh" ET "start_SubscriberNode.sh" QUI DOIVENT ÊTRE EXÉCUTÉS INDIVIDUELLEMENT.
-bash-4.1$ slonik initalize.slonik
-bash-4.1$ slonik create_set.slonik
create_set.slonik:13: Set 1 ...created
create_set.slonik:16: PKey table *** public.foo *** added.
-bash-4.1$ sh start_OriginNode.sh
-bash-4.1$ sh start_SubscriberNode.sh //ON SUBSCRIBER NODE
-bash-4.1$ slonik subscribe_set.slonik
Après l'exécution réussie du script ci-dessus, vous pouvez remarquer que les données sur Origin(masterdb) ont été répliquées sur Subscriber(slavedb). Interdire également toute opération DML sur le nœud de l'abonné :
slavedb=# select * from foo;
id | name | image
----+----------------------+-------
1 | Raghav | test1
2 | Rao | test2
3 | Rags | test3
(3 rows)
slavedb=# insert into foo values (4,'PG-Experts','Image2');
ERROR: Slony-I: Table foo is replicated and cannot be modified on a subscriber node - role=0
Cool… Nous avons déplacé les données vers la nouvelle version de PostgreSQL 9.3.5. À ce stade, si vous pensez que toutes les données ont été répliquées sur le nœud de l'abonné, vous pouvez effectuer la commutation.
3. Test de basculement/basculement.
Passons à la dernière version avec le script et essayons d'insérer des données sur les nœuds d'abonné/d'origine.
-bash-4.1$ slonik switchover.slonik
switchover.slonik:8: Set 1 has been moved from Node 1 to Node 2
slavedb=# insert into foo values (4,'PG-Experts','Image2');
INSERT 0 1
masterdb=# select * from foo ;
id | name | image
----+----------------------+-------
1 | Raghav | test1
2 | Rao | test2
3 | Rags | test3
4 | PG-Experts | Image2
(4 rows)
masterdb=# insert into foo values (5,'PG-Experts','Image3');
ERROR: Slony-I: Table foo is replicated and cannot be modified on a subscriber node - role=0
Parfait… C'est ce que nous recherchons, maintenant slavedb (Subscriber Node) exécutant la version PG 9.3.5 acceptant les données et masterdb (Origin Node) recevant les données slavedb. Aussi ses rejets DML exécutés sur masterdb.
Slony-I Logs affiche les mouvements de l'identifiant du nœud d'origine/abonné au moment du basculement :
2014-12-12 04:55:06 PST CONFIG moveSet: set_id=1 old_origin=1 new_origin=2
2014-12-12 04:55:06 PST CONFIG storeListen: li_origin=1 li_receiver=2 li_provider=1
2014-12-12 04:55:06 PST CONFIG remoteWorkerThread_1: update provider configuration
2014-12-12 04:55:06 PST CONFIG remoteWorkerThread_1: helper thread for provider 1 terminated
2014-12-12 04:55:06 PST CONFIG remoteWorkerThread_1: disconnecting from data provider 1
...
...
2014-12-12 04:55:11 PST INFO start processing ACCEPT_SET
2014-12-12 04:55:11 PST INFO ACCEPT: set=1
2014-12-12 04:55:11 PST INFO ACCEPT: old origin=1
2014-12-12 04:55:11 PST INFO ACCEPT: new origin=2
2014-12-12 04:55:11 PST INFO ACCEPT: move set seq=5000006393
2014-12-12 04:55:11 PST INFO got parms ACCEPT_SET
Si vous rencontrez des problèmes à ce stade, vous pouvez revenir à une version plus ancienne. Après le retour en arrière, vous pouvez continuer avec l'ancienne version jusqu'à ce que votre application ou d'autres problèmes soient résolus. C'est le plan de restauration parfait sans perdre beaucoup de temps en cas de problèmes après le basculement..
-bash-4.1$ slonik switchback.slonik
switchback.slonik:8: Set 1 has been moved from Node 2 to Node 1
slavedb=# insert into foo values (5,'PG-Experts','Image3');
ERROR: Slony-I: Table foo is replicated and cannot be modified on a subscriber node - role=0
masterdb=# insert into foo values (5,'PG-Experts','Image3');
INSERT 0 1
slavedb=# select * from foo ;
id | name | image
----+----------------------+-------
1 | Raghav | test1
2 | Rao | test2
3 | Rags | test3
4 | PG-Experts | Image2
5 | PG-Experts | Image3
(5 rows)
Très beau…!!! N'est-ce pas la restauration exacte avec un minimum de temps d'arrêt ? Oui, c'est une commutation parfaite entre les nœuds sans manquer une transaction.
Journaux montrant le passage de l'abonné au nœud d'origine :
2014-12-12 04:58:45 PST CONFIG moveSet: set_id=1 old_origin=2 new_origin=1
2014-12-12 04:58:45 PST CONFIG storeListen: li_origin=2 li_receiver=1 li_provider=2
2014-12-12 04:58:45 PST CONFIG remoteWorkerThread_2: update provider configuration
2014-12-12 04:58:45 PST CONFIG remoteWorkerThread_2: helper thread for provider 2 terminated
2014-12-12 04:58:45 PST CONFIG remoteWorkerThread_2: disconnecting from data provider 2
2014-12-12 04:58:46 PST CONFIG storeListen: li_origin=2 li_receiver=1 li_provider=2
...
...
2014-12-12 04:58:47 PST INFO start processing ACCEPT_SET
2014-12-12 04:58:47 PST INFO ACCEPT: set=1
2014-12-12 04:58:47 PST INFO ACCEPT: old origin=2
2014-12-12 04:58:47 PST INFO ACCEPT: new origin=1
2014-12-12 04:58:47 PST INFO ACCEPT: move set seq=5000006403
2014-12-12 04:58:47 PST INFO got parms ACCEPT_SET
2014-12-12 04:58:48 PST CONFIG moveSet: set_id=1 old_origin=2 new_origin=1
À ce stade, vous avez peut-être remarqué qu'aucune des transactions n'est perdue lors de l'opération de basculement entre les versions de PostgreSQL. Le seul temps d'arrêt peut être votre application à démarrer/arrêter pour se connecter aux nœuds d'origine et d'abonné, mais alors que les nœuds d'origine/d'abonné ne sont jamais supprimés, ils sont simplement opérationnels.
N'oubliez pas que la méthode présentée ici n'est pas seulement utile pour les mises à niveau, mais c'est la même méthode dans Slony-I pour se déplacer entre les nœuds.
Merci pour votre patience :). J'espère que cet article vous aidera à mettre à niveau PostgreSQL avec un minimum de temps d'arrêt en utilisant Slony-I, y compris un plan de restauration approprié.
