Documentation Slony-I 2.0.3 -

Administration Slony-I

23. Mise à jour de Slony-I

Lorsqu'on met à jour Slony-I™, chaque nœud du cluster doit être mis à jour simultanément, en utilisant la commande SLONIK UPDATE FUNCTIONS(7) de slonik(1).

Cela nécessite un arrêt temporaire de la réplication, mais cela n'implique pas obligatoirement une coupure de service au niveau des applications qui utilisent le cluster.

La procédure correcte est la suivante :

Toute cette opération est relativement sûre : s'il y a une incohérence entre les versions des composants, le slon(1) refusera de démarrer, ce qui constitue une protection contre les corruptions.

Vous devez vous assurer que la bibliothèque C contenant les fonctions trigger SPI ont été copiées à la bonne place lors de la compilation de PostgreSQL™. Il existe de multiples approches pour cela :

La partie la plus compliquée consiste à s'assurer que la bibliothèque C contenant les fonctions SPI est copiée au bon endroit lors de la compilation de PostgreSQL™ ; la manière la plus simple et la plus sûre de faire cela consiste à avoir deux versions compilées de PostgreSQL™, une pour chaque version de Slony-I™, puis d'éteindre le serveur et de le relancer avec la « nouvelle » version compilée ; cette approche implique une courte coupure de service sur chaque nœud.

Si cette approche est réputée plus simple et plus rapide, rien ne vous empêche de mettre en place avec précaution les composants Slony-I™ pour écraser l'ancienne version comme décrit dans l'étape d'installation. Ceci peut ne pas fonctionner sous Windows si Windows pose un verrou sur les fichiers qui sont utilisés.

Exécuter make install pour installer les nouveaux composants Slony-I™ au dessus des anciens.

Si vous compilez Slony-I™ sur le système sur où il sera déployé et que vous compilez à partir des sources, écraser l'ancienne version avec la nouvelle se fait simplement avec make install. Il n'est pas nécessaire de relancer la base de donnée, il faut juste arrêter les processus Slony-I™, exécuter le script UPDATE FUNCTIONS et démarrer les nouveaux processus slon(1).

Malheureusement, cette approche nécessite un environnement de compilation sur le serveur où la mise à jour sera déployée. Ceci n'est pas forcément compatible avec la volonté d'utiliser des binaires communs à PostgreSQL™ et Slony-I™ sur l'ensemble des nœuds.

Compiler à nouveau PostgreSQL™ et Slony-I™

Avec cette approche, l'ancienne version de PostgreSQL™ accompagnée des anciens composants Slony-I™ est conservée après la bascule vers une nouvelle version de PostgreSQL™ accompagnée des nouveaux composants Slony-I™. Afin de basculer vers la nouvelle version de Slony-I™, vous devez redémarrer le serveur postmaster, ce qui implique l'interruption des applications. afin que le serveur soit informé de l'emplacement des nouveaux composants.

23.1. Problème avec TABLE ADD KEY dans Slony-I 2.0

Généralement, les mises à jour de versions Slony-I™ ne nécessitent pas de porter une attention particulière au réplicat existant, c'est-à-dire que vous pouvez simplement arrêter les s, mettre en place les binaires, lancer SLONIK UPDATE FUNCTIONS(7) sur chaque nœud et redémarrer slon(1). Les modifications de schéma étant uniquement sur le schéma du cluster, SLONIK UPDATE FUNCTIONS(7) est capable de réaliser toutes les altérations. Avec la version 2, cela change s'il existe des tables qui utilisaient SLONIK TABLE ADD KEY(7). La version 2 ne supporte pas la colonne « extra », et « réparer » le schéma pour obtenir une clé primaire correcte n'est pas dans les attributions de SLONIK UPDATE FUNCTIONS(7).

Lorsque qu'on met à jour depuis une version 1.0.x, 1.1.x ou 1.2.x vers une version 2, il est nécessaire de supprimer toute clé primaire gérée par Slony-I™.

On peut identifier les tables concernées avec la requête SQL suivante : SELECT n.nspname, c.relname FROM pg_class c, pg_namespace n WHERE c.oid in (SELECT attrelid FROM pg_attribute WHERE attname LIKE '_Slony-I_%rowID' and not attisdropped) and reltype &lt&gt 0 and n.oid = c.relnamespace order by n.nspname, c.relname;

L'approche la plus simple pour rectifier l'état de ces tables est la suivante :

  • Retirer la table de la réplication avec la commande slonik(1) SLONIK SET DROP TABLE(7)

    Ceci ne supprime pas les colonnes créées par Slony-I™.

  • Sur chaque nœud, exécutez un script SQL pour modifier la table et supprimez les colonnes additionnelles.

    ALTER TABLE nom_table DROP COLUMN "_Slony-I_cluster-rowID";

    Ceci doit être exécuté sur chaque nœud. Selon votre préférence, vous pouvez utiliser SLONIK EXECUTE SCRIPT(7) pour cela.

    Si la table est une table massivement mise à jour, sachez que cette modification posera un verrou exclusif sur la table. Elle ne détiendra pas ce verrou très longtemps ; supprimer une colonne est une opération assez rapide car cela se contente de marquer la colonne comme supprimée. Cela ne nécessite pas de réécrire toute la table. Les lignes qui ont une valeur dans cette colonne continueront à avoir cette valeur. Pour les nouvelles lignes, la valeur sera NULL, et les requêtes ignoreront cette colonne. L'espace occupé par ces colonnes sera récupéré lorsque les lignes seront mises à jour.

    Notez qu'à cette étape de la procédure, cette table n'est pas répliquée. Si une erreur a lieu, la réplication à cet instant n'apporte aucune protection sur cette table. C'est dommage mais inévitable.

  • Assurez-vous que la table possède un candidat éligible pour une clé primaire, c'est-à-dire un ensemble de colonnes NOT NULL et UNIQUE.

    Les différents cas possibles font que les développeurs n'ont pas fait d'efforts pour automatiser cette procédure.

    • Si la table est petite, il peut être parfaitement raisonnable d'ajouter une nouvelle colonne (notez que cela doit être fait sur chaque nœud !), lui assigner une une nouvelle séquence et la déclarer comme clé primaire.

      S'il n'y a que quelques lignes, cela ne prend qu'une fraction de seconde et avec de la chance, cela n'aura pas d'impact sur l'application.

      Même si la table est relativement large, alors qu'elle n'est pas accédée fréquemment par l'application, alors le verrouillage de la table provoqué par ALTER TABLE n'entraînera pas d'inconvénients.

    • Si la table est large, qu'elle est vitale et fortement utilisée par l'application, alors il peut être nécessaire de prévoir une coupure de service de l'application afin d'accomplir les modifications, ce qui vous laissera un peu vulnérable tant que la procédure ne sera pas complétée.

      Si une coupure de service est problématique, alors la mise à jour vers Slony-I™ version 2 devra être planifiée avec soin...

  • Créez un nouvel ensemble de réplication (SLONIK CREATE SET(7) et ajoutez à nouveau la table dans cet ensemble (SLONIK SET ADD TABLE(7)).

    S'il existe plusieurs tables, elles peuvent être gérées via un ensemble de réplication unique.

  • Abonnez l'ensemble de réplication (SLONIK SUBSCRIBE SET(7)) pour tous les nœuds désirés.

  • Une fois que l'abonnement est complété, fusionnez les ensembles de réplications si nécessaire (SLONIK MERGE SET(7)).

Cette approche devrait fonctionner pour les tables qui sont relativement petites ou rarement utilisées. D'autre part, si la table est large et massivement utilisée, une autre approche pourrait être nécessaire, c'est-à-dire créer votre propre séquence, et « promouvoir » l'ancienne colonne générée par Slony-I™ dans une colonne « réelle » au sein du schéma de votre base de données. Les grandes lignes de cette procédure sont les suivantes :

  • Ajouter une séquence qui assigne des valeurs à la colonne.

    Les étapes d'installation incluent les commandes SQL CREATE SEQUENCE, SELECT SETVAL() (pour définir une valeur de séquence assez haute pour refléter les valeurs utilisées dans la table), le SLONIK CREATE SET(7) de Slonik (pour créer un ensemble de réplication dans lequel on placera la séquence), le SLONIK SET ADD SEQUENCE(7) de Slonik (pour placer la séquence dans l'ensemble de réplication), le SLONIK SUBSCRIBE SET(7) de Slonik (pour définir les abonnements de ce nouvel ensemble de réplication).

  • Attachez la séquence à la colonne dans la table.

    Ceci implique les commandes ALTER TABLE ALTER COLUMN, qui doivent être exécutées via la commande Slonik SLONIK EXECUTE SCRIPT(7).

  • Renommez la colonne _Slony-I_@CLUSTERNAME@_rowID afin que Slony-I™ ne considère pas qu'elle est sous son contrôle.

    Ceci implique les commandes ALTER TABLE ALTER COLUMN, qui doivent être exécutées via la commande Slonik SLONIK EXECUTE SCRIPT(7).

    Notez que ces deux modifications peuvent être accomplies au sein d'une requête SLONIK EXECUTE SCRIPT(7) unique.

23.2. Nouvelle gestion des triggers dans Slony-I Version 2

Un des changements majeurs de Slony-I™ est que l'activation et la désactivation des triggers et règles (« rules ») se fait maintenant entièrement en SQL, supporté par PostgreSQL™ 8.3+, plutôt que via des modifications directes dans le catalogue système.

Cela implique que les utilisateurs de Slony-I™ doivent étudier la syntaxe PostgreSQL™ pour ALTER TABLE car c'est ainsi qu'ils accompliront ce qu'ils accomplissait précédemment via les commandes SLONIK STORE TRIGGER(7) et SLONIK DROP TRIGGER(7).

23.3. Mettre à jour en version 2

La version 2 est vraiment différente des versions précédentes, supprimant le support des versions de PostgreSQL™ antérieures à la 8.3 car la version 8.3 a ajouté la notion de « rôle de réplication », éliminant du coup d'avoir recours à des modifications du catalogue système ainsi que du type de données xxid pas complètement supporté.

Grâce au remplacement du type xxid par un type XID natif en 8.3, la commande slonik(1) SLONIK UPDATE FUNCTIONS(7) n'est pas adéquate pour mettre à jour d'une ancienne version de Slony-I™ à la version 2.

En version 2.0.2, nous avons ajouté une nouvelle option à SLONIK SUBSCRIBE SET(7), OMIT COPY, qui permet de prendre une approche alternative pour la mise à jour. Cette approche revient à :

  • Désinstaller l'ancienne version de Slony-I™.

    Quand Slony-I™ se désinstalle, les corruptions des catalogues sont corrigées.

  • Installer Slony-I™ version 2

  • Réabonner les nœuds avec l'option OMIT COPY

[Avertissement]

Avertissement

Cela représente un gros risque. Durant le processus de mise à jour, Slony-I™ n'est pas installé et si une application met à jour l'une ou l'autre base de données, le ré-abonnement, omettant de copier les données, se finira avec des données non synchronisées.

L'administrateur doit être très attentif car Slony-I™ ne dispose d'aucun moyen pour s'assurer de l'intégrité des données lors de ce processus.

Le processus suivant est suggéré pour s'assurer d'avoir une mise à jour aussi sûre que possible, étant donné les risques évoqués ci-dessus.

  • Utiliser Section 21.10, « slonikconfdump.sh » pour générer un script slonik(1) de création du cluster de réplication.

    Assurez-vous de vérifier les instructions SLONIK ADMIN CONNINFO(7), car les valeurs sont récupérées de la configuration du PATH, qui ne sont pas forcément convenables pour exécuter slonik(1).

    Cette étape peut se faire avant la mise hors ligne de l'application.

  • Détermine les triggers qui ont la configuration SLONIK STORE TRIGGER(7) sur les nœuds abonnés.

    Comme indiqué sur Section 11, « Gestion des triggers Slony-I », la gestion a changé fondamentalement entre Slony-I™ 1.2 et 2.0.

    En général, il faut lancer une requête sur la table sl_table de chaque nœud et, pour chaque trigger trouvé dans sl_table, il est généralement approprié de configurer un script indiquant soit ENABLE REPLICA TRIGGER soit ENABLE ALWAYS TRIGGER pour ces triggers.

    Cette étape peut se faire avant la mise hors ligne de l'application.

  • Mettre hors ligne l'application le temps de la mise à jour pour qu'aucune modification ne puisse venir de l'utilisation de l'application.

  • Pour vous assurer que les applications ne feront pas de modifications, il pourrait être approprié d'empêcher les connexions en modifiant le fichier de configuration pg_hba.conf.

  • Assurez-vous que la réplication est synchrone, en examinant la vue sl_status et toute donnée de l'application qui serait appropriée.

  • Arrêter les processus slon(1).

  • Désinstaller l'ancienne version de Slony-I™ de la base de données.

    Ceci implique d'exécuter un script slonik(1) qui exécute SLONIK UNINSTALL NODE(7) sur chaque nœud du cluster.

  • Assurer vous que les nouveaux exécutables Slony-I™ sont en place.

    Une méthode simple de le faire est d'avoir les anciens et les nouveaux exécutables dans des répertoires différents, de stopper postmaster, de pointer vers le bon répertoire, et de relancer postmaster.

  • Lancer le script qui reconfigure la réplication générée précédemment.

    Ce script devrait être divisé en deux parties à exécuter séparément :

    • En premier, configurer les nœuds, les chemins, les ensembles, et ainsi de suite.

    • Maintenant, lancer les processus slon(1).

    • Enfin, exécuter la portion qui lance SLONIK SUBSCRIBE SET(7).

    Diviser le script Section 21.10, « slonikconfdump.sh » comme décrit ci-dessus est laissé en exercice au lecteur.

  • Si des triggers doivent être activés sur les nœuds abonnés, c'est le bon moment pour le faire.

  • Maintenant, le cluster est nouveau disponible et fonctionnel, prêt à être reconfiguré pour que les applications puissent de nouveau y accéder.

PrécédentSupport du partitionnement Niveau supérieurSommaire slonikSuivant