Slony, réplication des données par trigger

Magazine
Marque
GNU/Linux Magazine
HS n°
Numéro
44
Mois de parution
octobre 2009
Spécialité(s)


Résumé

Il existe en gros trois façons de répliquer une base de données : répliquer les changements des fichiers (c'est ce que propose le Log Shipping, ainsi que DRBD), répliquer les instructions (c'est ce que propose pgpool) et répliquer les changements de données. Ce dernier cas est proposé par trois outils, dont Slony.


Body

1. Un peu de théorie

Slony est un outil de réplication asynchrone pour un maître/plusieurs esclaves. Bien que ces derniers ne sont pas limités, il est généralement prudent de ne pas dépasser 12 nœuds.

Pour répliquer les données, il suffit que le moteur soit capable d'appeler une fonction personnalisée quand une donnée est insérée, modifiée ou supprimée. Or, cette capacité, tout moteur sérieux de bases de données l'a : cela s'appelle un trigger. PostgreSQL en dispose depuis bien longtemps, le système est rodé. Cependant, le trigger ne pourra pas envoyer les données sur un autre serveur. Il pourra par contre enregistrer les modifications dans une table qui sera surveillée par un démon qui lui enverra les données sur le serveur esclave. Il est à noter que les esclaves seront aussi munies de triggers qui empêcheront dans ce cas toute modification. En effet, les esclaves sont en lecture seule.

Première limitation notable : PostgreSQL ne proposant pas de triggers sur les modifications de schéma, et n'acceptant pas l'ajout de triggers sur les catalogues système, il n'est pas possible de répliquer les changements dans la structure de la base. Les opérations comme l'ajout d'une colonne, l'ajout ou la suppression d'une table sont toujours possibles, mais ne sont pas répliquées automatiquement.

Slony a tout un vocabulaire particulier que nous allons passer tout de suite en revue, histoire de discuter avec les bons termes. Un nœud est un serveur. Il peut être maître ou esclave d'un ou plusieurs sets. Un set est un ensemble cohérent de tables et de séquences, seuls objets que Slony sait répliquer. En effet, une fonction ou une vue ne se répliquent pas. Ils sont créés à un instant t et ne seront pas modifiés par la suite. S'ils le sont, c'est une modification de la structure de la base et ce n'est donc pas pris en compte automatiquement par Slony. Le cas des index est un peu particulier dans le sens où la modification des données des tables va modifier les données des index... mais c'est géré par PostgreSQL. Slony n'a rien à faire pour que cela fonctionne, que cela soit sur le maître ou sur les esclaves. Pour en revenir au set, il s'agit donc d'un ensemble cohérent de tables et de séquences, ayant un nœud maître et un ou plusieurs nœuds esclaves. Cette notion de set permet de définir un nœud A maître du set s1 et esclave du set s2 sur la même base de données. Autre terme important : l'abonnement. Il est généralement dit qu'un nœud s'abonne aux modifications des données réalisées pour un certain set. Cela se voit très nettement lors de la mise en place de Slony : nous créons le set sur un nœud (qui en sera donc le maître, au moins temporairement), puis nous abonnons un nœud à un set (ce nœud sera dans ce cas esclave).

Toutes les informations spécifiques à Slony sont stockées dans un schéma de la base de données à répliquer. Ce schéma contient des tables et des vues permettant de connaître la liste des objets répliqués, de savoir qui est le maître d'un set particulier, de connaître le lag de la réplication entre différents nœuds.

L'installation consiste donc simplement à ajouter quelques objets dans la base de données, dont des triggers, et à exécuter un démon d'envoi des données. C'est ce que nous allons mettre en pratique immédiatement.

2. Récapitulatif des pré-requis

- Avoir une clé primaire sur chaque table à répliquer (cette clé est nécessaire pour pouvoir identifier chaque ligne de façon certaine).

- Ne pas utiliser l'ordre SQL TRUNCATE (instruction SQL permettant de vider très rapidement le contenu d'une table, beaucoup plus rapidement que ne le ferait un DELETE sur la table complète).

- Ne pas modifier fréquemment le schéma de la base de données répliquée.

3. Mise en pratique rapide

Considérons un serveur debian1 qui sera le maître et un serveur debian2 qui sera l'esclave. Nous allons créer une base sur debian1 avec un schéma assez simple composé de deux tables, chacune ayant une séquence.

Créons donc cette petite base :

debian1:~# su – postgres

postgres@debian1:~$ createdb base1

postgres@debian1:~$ psql base1

Bienvenue dans psql 8.3.7, l'interface interactive de PostgreSQL.

Saisissez:

    \copyright pour les termes de distribution

    \h pour l'aide-mémoire des commandes SQL

    \? pour l'aide-mémoire des commandes psql

    \g ou point-virgule en fin d'instruction pour exécuter la requête

    \q pour quitter

base1=# CREATE TABLE t1 (id serial PRIMARY KEY, texte text);

NOTICE: CREATE TABLE / PRIMARY KEY créera un index implicite « t1_pkey » pour la table « t1 »

CREATE TABLE

base1=# CREATE TABLE t2 (id serial PRIMARY KEY, texte text, autre boolean);

NOTICE: CREATE TABLE / PRIMARY KEY créera un index implicite « t2_pkey » pour la table « t2 »

CREATE TABLE

base1=# INSERT INTO t1 (texte) SELECT 'Ligne '||i::integer FROM generate_series(1, 100000) AS i;

INSERT 0 100000

base1=# INSERT INTO t2 (texte, autre)

base1-# SELECT 'LIGNE '||i::integer, true FROM generate_series(1, 10000) AS i;

INSERT 0 10000

base1=# INSERT INTO t2 (texte, autre)

base1-# SELECT 'LIGNE '||(i+10000)::integer, false FROM generate_series(1, 10000) AS i;

INSERT 0 10000

Voilà. Nous avons donc notre base à répliquer avec Slony.

Commençons par installer les paquets. Il existe deux paquets pour Slony, dont un dépendant de la version de PostgreSQL.

postgres@debian1:~$ exit

logout

debian1:~# aptitude install slony1-bin postgresql-8.3-slony1

[… messages d'installation …]

Les mêmes paquets sont à installer sur le serveur debian2. Comme vous le voyez, nous avons installé les paquets pour PostgreSQL 8.3. En effet, il n'y a pas encore de paquet Debian pour la version 8.4 au moment de l'écriture de cet article.

Nous allons ensuite créer un utilisateur PostgreSQL slony. Les connexions effectuées par les démons et les outils Slony passeront par cet utilisateur. C'est un moyen simple et efficace pour déterminer qui fait quoi sur les bases.

debian1:~# su – postgres

postgres@debian1:~$ createuser -sP base1

Saisissez le mot de passe pour le nouveau rôle :

Saisissez-le à nouveau :

L'option -s indique que l'utilisateur sera en fait un superutilisateur. L'option -P demande l'ajout immédiat d'un mot de passe.

Le même utilisateur doit être créé sur debian2. Le mot de passe peut ne pas être le même.

Ceci fait, nous devons nous assurer que l'utilisateur slony puisse se connecter sur la base base1 sur debian1 et sur debian2. En fait, par facilité, nous allons nous assurer que tous les utilisateurs PostgreSQL puissent se connecter à toutes les bases de données de ces deux serveurs. Pour cela, nous allons modifier le fichier de configuration des connexions. Ce fichier a pour nom pg_hba.conf et se trouve dans le répertoire /etc/postgresql/8.3/main sous Debian. Nous allons dans notre cas ajouter les trois lignes suivantes :

# Connexions Slony

host    all          all          192.168.0.7/32         md5

host    all          all          192.168.0.10/32        md5

Si vous avez déjà modifié ce fichier, il est fort possible qu'ajouter les lignes à la fin du fichier ne donne pas le résultat escompté. En effet, PostgreSQL identifie la méthode d'authentification pour un client grâce à quatre données : sa méthode de connexion (socket Unix ou TCP/IP), la base, le nom de l'utilisateur et l'adresse IP du client (dans le cas d'une connexion TCP/IP). Ces quatre données peuvent correspondre à plusieurs lignes du fichier pg_hba.conf. Dans ce cas, PostgreSQL sélectionne la première ligne par ordre d'apparition dans le fichier correspondant à ces quatre données. Donc, si vous l'avez déjà modifié, il est préférable d'ouvrir le fichier avec un éditeur de texte et de le modifier manuellement.

Ainsi, nous autorisons la connexion des utilisateurs postgres et slony (seuls utilisateurs actuellement créés). Seul l'utilisateur slony dispose ici d'un mot de passe. Or, la connexion se fait par mot de passe, chiffré en md5 dans la communication entre le serveur et le client. Nous allons donc ajouter un mot de passe à l'utilisateur PostgreSQL postgres :

postgres@debian1:~$ psql -q postgres

postgres=# ALTER USER postgres PASSWORD 'postgres';

L'option -q permet, entre autres, d'éviter le message de bienvenue. J'ai mis ici comme mot de passe postgres, car ça simplifie les tests. Un mot de passe en production doit suivre des règles beaucoup plus draconiennes pour s'assurer de la sécurité des données.

Ensuite, toujours dans le but de se connecter d'un serveur à un autre, nous devons modifier, dans le fichier /etc/postgresql/8.3/main/postgresql.conf, le paramètre listen_addresses. Ce dernier vaut par défaut localhost, ce qui fait qu'il n'écoute que sur la boucle locale. Nous allons le mettre à « * » pour qu'il écoute sur chaque interface réseau. Ceci fait, il faut redémarrer PostgreSQL :

debian1:~# /etc/init.d/postgresql-8.3 restart

Restarting PostgreSQL 8.3 database server: main

À partir de debian1, testons la connexion vers debian1 :

postgres@debian1:~$ psql -h debian1 -U slony -l

Mot de passe pour l'utilisateur slony : [... saisie du mot de passe ...]

       Liste des bases de données

     Nom      | Propriétaire | Encodage

--------------+--------------+-----------

base1        | postgres     | UTF8

postgres     | postgres     | UTF8

template0    | postgres     | UTF8

template1    | postgres     | UTF8

L'option -h indique le nom de l'hôte où se connecter, l'option -U précise le nom d'utilisateur PostgreQL à prendre en compte pour la connexion. L'option -l demande le renvoi de la liste des bases. C'est un moyen simple, non interactif pour savoir si nous avons réussi à nous connecter. Ce qui est bien le cas.

Testons la connexion vers debian2 :

postgres@debian1:~$ psql -h debian2 -U slony -l

Mot de passe pour l'utilisateur slony : [... saisie du mot de passe ...]

       Liste des bases de données

     Nom      | Propriétaire | Encodage

--------------+--------------+-----------

postgres     | postgres     | UTF8

template0    | postgres     | UTF8

template1    | postgres     | UTF8

Cela fonctionne. Il faut évidemment configurer debian2 de la même façon et s'assurer que la connexion fonctionne bien.

Nous allons créer un fichier .pgpass dans le répertoire personnel de l'utilisateur Unix postgres pour ne plus avoir à saisir de mot de passe.

postgres@debian1:~$ cat <<_EOF_ >> ~/.pgpass

> 192.168.0.7:5432:*:slony:slony

> 192.168.0.10:5432:*:slony:slony

> _EOF_

Pour que les outils puissent utiliser ce fichier, nous devons ne le rendre lisible et modifiable que par son utilisateur :

postgres@debian1:~$ chmod 600 ~/.pgpass

Maintenant, nous pouvons préparer la base du serveur esclave. Nous allons simplement recréer le schéma de la base maître, mais nous n'y placerons pas les données.

postgres@debian1:~$ createdb -h debian2 base1

Mot de passe :

postgres@debian1:~$ pg_dump -h debian1 -s base1 | psql -h debian2

Mot de passe :

Mot de passe :

SET

SET

SET

SET

SET

SET

SET

SET

CREATE TABLE

ALTER TABLE

CREATE SEQUENCE

ALTER TABLE

ALTER SEQUENCE

CREATE TABLE

ALTER TABLE

CREATE SEQUENCE

ALTER TABLE

ALTER SEQUENCE

ALTER TABLE

ALTER TABLE

ALTER TABLE

REVOKE

REVOKE

GRANT

GRANT

L'option -s de l'outil pg_dump permet de ne récupérer que les requêtes SQL de création du schéma. Nous avons bien un mot de passe à saisir, car nous nous connectons en tant qu'utilisateur postgres. Ce dernier n'est pas indiqué dans le fichier .pgpass, donc la demande de mot de passe se fait. La première et la deuxième demandes concernent l'utilisateur postgres sur debian1, alors que la troisième demande concerne l'utilisateur postgres sur debian2. J'ai donné à la base esclave le même nom, mais j'aurais très bien pu en mettre un autre.

Nous devons aussi activer l'utilisation du langage PL/pgsql dans la base base1 de debian1 et de debian2 :

postgres@debian1:~$ createlang -h debian1 plpgsql base1

Mot de passe :

postgres@debian1:~$ createlang -h debian2 plpgsql base1

Mot de passe :

Ce langage est nécessaire pour que Slony puisse installer les procédures stockées qu'il utilisera.

Il nous faut ensuite configurer les nœuds, les sets, bref toute la configuration de Slony. Pour cette fois, nous allons tout faire manuellement. Donc, nous allons écrire un script Slonik. Slonik est un interpréteur de commandes très particulières dont vous trouverez la référence sur la documentation de Slony. Il faut savoir qu'il y a toujours deux parties dans un script Slonik : le préambule (sorte de partie déclarative du nom du cluster et des nœuds en présence), puis les instructions à exécuter. Voici le script que nous allons exécuter :

#--

# PREAMBULE

#--

# définit le nom du schéma que Slony utilise pour stocker ses données

cluster name = replication;

# spécification des DSN permettant d'accéder à chaque serveur

node 1 admin conninfo = 'dbname=base1 host=debian1 user=slony';

node 2 admin conninfo = 'dbname=base1 host=debian2 user=slony';

#--

# INSTRUCTIONS DE MISE EN PLACE DE LA REPLICATION

#--

# préparation du cluster

init cluster (id=1, comment = 'noeud 1, debian1');

# creation du set

create set (id=1, origin=1, comment='notre premier set');

# ajout des deux tables au set

set add table (set id=1, origin=1, id=1, fully qualified name = 'public.t1', comment='table t1');

set add table (set id=1, origin=1, id=2, fully qualified name = 'public.t2', comment='table t2');

# ajout des deux sequences au set

set add sequence (set id=1, origin=1, id=1, fully qualified name = 'public.t1_id_seq',

comment='séquence de la table t1');

set add sequence (set id=1, origin=1, id=2, fully qualified name = 'public.t2_id_seq',

comment='séquence de la table t2');

# création du deuxieme noeud

store node (id=2, comment = 'noeud 2, debian2', event node=1);

# enregistrement des chemins entre les deux noeuds

store path (server = 1, client = 2, conninfo='dbname=base1 host=debian1 user=slony');

store path (server = 2, client = 1, conninfo='dbname=base1 host=debian2 user=slony');

Le préambule définit donc le nom du cluster et le moyen pour se connecter sur les deux futurs nœuds. Ensuite, nous allons initialiser le cluster (instruction init cluster), ce qui aura trois effets visibles : la création du schéma _replication (d'après le nom du cluster) dans la base de données base1, l'ajout des tables et vues spécifiques de Slony dans ce schéma et la création du premier nœud. Ensuite, nous créons un set vide, nous lui ajoutons les deux tables et les deux séquences à répliquer pour notre base. À noter le paramètre origin indiquant le nœud maître pour le set. Nous créons le deuxième nœud (qui correspondra au serveur debian2) et nous enregistrons tous les chemins possibles pour aller d'un nœud à un autre.

Il faut donc stocker ce texte dans un fichier que nous allons fournir à l'interpréteur Slonik :

postgres@debian1:~$ cat mep.slonik | slonik

Aucun message d'erreur, tout va bien. Attention, si vous avez des messages d'erreurs, la partie du script qui a pu s'exécuter avec succès a pu ajouter le schéma de réplication. Dans ce cas, une fois l'erreur corrigée dans le script Slonik, vous devez supprimer le schéma avant de recommencer la commande ci-dessus.

Avant de lancer les démons Slony, nous allons les configurer. Il nous suffit de copier le fichier exemple et de le personnaliser pour prendre en compte notre contexte :

debian1:~$ gunzip -c /usr/share/doc/slony1/slon.conf-sample.gz > /etc/slony1/slon.conf

debian1:~$ vi /etc/slony1/slon.conf

Deux paramètres sont à configurer. C'est évidemment un minimum et je vous conseille fortement de jeter un œil aux différents paramètres disponibles une fois qu'une première réplication fonctionne.

Les deux paramètres sont cluster_name, qui doit être décommenté et passé à replication, et conn_info, qui doit aussi être décommenté et passé à host=debian1 port=5432 dbname=base1 user=slony.

Nous pouvons maintenant lancer le démon du serveur debian1 en tant qu'utilisateur postgres :

postgres@debian1:~$ slon -f /etc/slony1/slon.conf &>slon.log

L'option -f permet de préciser le fichier de configuration à utiliser. La suite de la commande redirige toutes les traces vers le fichier slon.log. Maintenant que ceci est fait, le démon doit être en cours d'exécution.

Il est nécessaire de faire la même configuration sur debian2 pour aussi exécuter le démon sur ce nœud. Par contre, le paramètre conn_info aura une configuration légèrement différente : host=debian2 port=5432 dbname=base1 user=slony. Cela étant fait, il ne reste plus qu'à le lancer de la même façon que pour debian1.

Si vous regardez le fichier de traces sur l'un comme sur l'autre serveur, vous verrez qu'il est très verbeux. Vous verrez aussi de nombreuses opérations de synchronisation. Pour l'instant, elles sont sans intérêt. Nous avons déclaré un set, mais nous n'avons indiqué aucun esclave (le nœud du serveur qui sera esclave est déclaré, mais pas le fait que ce dernier est abonné aux modifications du set1). Profitons-en pour regarder le contenu de base1 sur le serveur debian2 :

postgres@debian1:~$ psql -q base1

base1=# SELECT count(*) FROM t1;

count

-------

     0

(1 ligne)

base1=# SELECT count(*) FROM t1;

count

-------

     0

(1 ligne)

C'est normal. Nous n'avons restauré que le schéma, pas les données et debian2 n'est toujours pas abonné aux modifications du set dont debian1 est le maître.

Abonnons debian2. Nous devons de nouveau créer un petit script Slonik.

#--

# PREAMBULE

#--

# définit le nom du schéma que Slony utilise pour stocker ses données

cluster name = replication;

# spécification des DSN permettant d'accéder à chaque serveur

node 1 admin conninfo = 'dbname=base1 host=debian1 user=slony';

node 2 admin conninfo = 'dbname=base1 host=debian2 user=slony';

#--

# INSTRUCTIONS D'ABONNEMENT DU NOEUD 2 AU SET 1

#--

# abonnement du noeud 2

subscribe set (id=1, provider=1, receiver=2, forward = yes);

Le préambule est toujours là. La seule différence réside dans l'instruction subscribe set. Cette instruction permet d'ajouter dans le schéma _replication l'information que le nœud 1 (provider, soit un fournisseur de données) a comme nouvel abonné le nœud 2 (receiver, donc le récepteur des données). Exécutons ce script :

postgres@debian1:~$ cat mer.slonik | slonik

Là aussi, aucun message d'erreur, tout va bien. Regardons ce qui vient de se passer au niveau du nœud 2 :

base1=# SELECT count(*) FROM t1;

count

--------

100000

(1 ligne)

base1=# SELECT count(*) FROM t1;

count

-------

20000

(1 ligne)

Eh voilà, nos données sont répliquées. Faisons quelques actions sur debian1 et vérifions que debian2 est bien mis à jour.

postgres@debian1:~$ psql -q base1

base1=# INSERT INTO t1 (texte) VALUES ('un texte') RETURNING id, texte;

   id   |     texte

-------------------------

100001 | un super texte

(1 ligne)

INSERT 0 1

Vérifions l'insertion sur debian2 :

postgres@debian2:~$ psql -q base1

base1=# SELECT * FROM t1 WHERE id=100001;

   id   |     texte

-------------------------

100001 | un super texte

(1 ligne)

Les modifications et les suppressions sont aussi possibles sur debian1, et seront aussitôt répliquées sur debian2.

« aussitôt » est certainement un peu simpliste. Vous pourrez constater un certain délai dans la mise à jour du serveur esclave. C'est tout à fait logique. Slony est une réplication asynchrone. Il ne faut donc pas s'attendre à ce que les données soient immédiatement transmises. Le délai de réplication des données dépend d'un paramètre qu'il sera possible de modifier suivant les besoins. En fait, cela s'avèrera soit suffisant, soit handicapant.

Notez par contre qu'il est impossible de modifier des données sur l'esclave :

postgres@debian2:~$ psql -q base1

base1=# INSERT INTO t1 (texte) VALUES ('un autre texte');

ERREUR: Slony-I: Table t1 is replicated and cannot be modified on a subscribed node

Le message d'erreur est clair : la table t1 est répliquée et ne peut donc pas être modifiée à partir d'un nœud abonné.

Voyons maintenant les limites de Slony. Bien que vous ayez la possibilité d'utiliser l'instruction COPY (qui déclenche en fait le trigger INSERT), l'instruction TRUNCATE ne déclenche aucun trigger. Seule la version 8.4 le fait. Testons cela :

postgres@debian1:~$ psql -q base1

base1=# TRUNCATE t1;

TRUNCATE TABLE

base1=# SELECT count(*) FROM t1;

count

-------

     0

(1 ligne)

base1=# \q

postgres@debian2:~$ psql -q -h debian2 base1

base1=# SELECT count(*) FROM t1;

count

--------

100001

(1 ligne)

La table t1 de debian1 est vide alors que la table t1 de debian2 contient un grand nombre de lignes. Il faut donc oublier TRUNCATE lorsque vous utilisez Slony.

Maintenant, ajoutons une colonne à la table t1 de debian1 :

postgres@debian1:~$ psql -q base1

base1=# ALTER TABLE t2 ADD COLUMN test boolean;

ALTER TABLE

base1=# INSERT INTO t2 (texte, autre, test) VALUES ('yop', true, false);

INSERT 0 1

base1=# SELECT * FROM t2 WHERE texte='yop';

   id | texte | autre | test

-------------------------------

20001 | yop   | t     | f

(1 ligne)

base1=# \q

postgres@debian2:~$ psql -q -h debian2 base1

base1=# SELECT * FROM t2 WHERE texte='yop';

(0 lignes)

base1=# \d t2

                         Table « public.t2 »

Colonne | Type   |                  Modificateurs

---------+---------+-------------------------------------------------

id      | integer | not null default nextval('t2_id_seq'::regclass)

texte   | text    |

autre   | boolean |

Index :

    « t2_pkey » PRIMARY KEY, btree (id)

Il n'y a pas la nouvelle colonne. Il n'y a pas non plus la nouvelle ligne. Il faut ajouter la nouvelle colonne aux esclaves, manuellement :

postgres@debian2:~$ psql -q base1

base1=# ALTER TABLE t2 ADD COLUMN test boolean;

ALTER TABLE

base1=# SELECT * FROM t2 WHERE texte='yop';

   id | texte | autre | test

-------------------------------

20001 | yop   | t     | f

(1 ligne)

Eh voilà !

4. Le schéma de réplication

Maintenant que Slony est fonctionnel et qu'on a vu ses limitations, jetons un œil au schéma de Slony.

postgres@debian1:~$ psql -q base1

base1=# \dn

         Liste des schémas

        Nom         | Propriétaire

--------------------+---------------

_replication       | slony

information_schema | guillaume

pg_catalog         | guillaume

pg_toast           | guillaume

pg_toast_temp_1    | guillaume

public             | guillaume

(5 lignes)

Il y a bien un schéma _replication. Il a été créé par l'instruction Slonik init cluster. Son propriétaire est donc l'utilisateur slony, étant donné que toute connexion des démons et outils Slony se fait avec cet utilisateur. Cette dernière a aussi ajouté quelques tables, vues et séquences.

base1=# SET search_path TO _replication;

base1=# \d

glmf=# \d

                     Liste des relations

    Schéma    |            Nom             |   Type   | Propriétaire

--------------+----------------------------+----------+--------------

_replication | sl_action_seq              | séquence | slony

_replication | sl_archive_counter         | table    | slony

_replication | sl_config_lock             | table    | slony

_replication | sl_confirm                 | table    | slony

_replication | sl_event                   | table    | slony

_replication | sl_event_seq               | séquence | slony

_replication | sl_listen                  | table    | slony

_replication | sl_local_node_id           | séquence | slony

_replication | sl_log_1                   | table    | slony

_replication | sl_log_2                   | vue      | slony

_replication | sl_log_status              | séquence | slony

_replication | sl_node                    | table    | slony

_replication | sl_nodelock                | table    | slony

_replication | sl_nodelock_nl_conncnt_seq | séquence | slony

_replication | sl_path                    | table    | slony

_replication | sl_registry                | table    | slony

_replication | sl_rowid_seq               | séquence | slony

_replication | sl_seqlastvalue            | vue      | slony

_replication | sl_seqlog                  | table    | slony

_replication | sl_sequence                | table    | slony

_replication | sl_set                     | table    | slony

_replication | sl_setsync                 | table    | slony

_replication | sl_status                  | vue      | slony

_replication | sl_subscribe               | table    | slony

_replication | sl_table                   | table    | slony

_replication | sl_trigger                 | table    | slony

(26 lignes)

Le tableau 1liste les tables et vues importantes du schéma de réplication.

 

Table/Vue

Commentaires

sl_node

liste des nœuds

sl_path

liste des chemins entre les différents nœuds

sl_set

liste des sets

sl_subscribe

liste des abonnements

sl_table

liste des tables ajoutées aux différents sets

sl_sequence

liste des séquences ajoutées aux différents sets

sl_log1 et sl_log2

liste des modifications pour chaque paire nœud/set

sl_status

statut de la réplication

Tableau 1 : Liste des tables et vues importantes du schéma de Slony

Il y a bien plus à voir dans ce schéma. Le lecteur curieux pourra regarder le contenu de ce schéma, ce qui lui donnera une meilleure compréhension du fonctionnement de Slony.

5. Comment se faciliter la vie ?

Comme pour le Log Shipping, certains utilisateurs ont préféré écrire des outils pour faciliter l'utilisation de Slony.

5.1 Les outils altperl

Ce sont des scripts écrits en Perl par la communauté. Ils sont fournis avec les paquets Slony déjà installés.

Ils ont principalement pour but d'avoir à se passer de l'écriture des scripts Slonik, au prix de la modification d'un fichier de configuration.

slonik_build_env est un peu particulier dans le sens où il ne prépare pas un script Slonik, mais aide à la configuration. Voici un exemple de son utilisation :

postgres@debian1:~$ slonik_build_env -node debian1:base1:slony -node debian2:base1:slony

&add_node(host => 'debian1', dbname => 'base1', port =>5432,

        user=>'slony', password=>'', node=>1 );

&add_node(host => 'debian2', dbname => 'base1', port =>5432,

        user=>'slony', password=>'', node=>2 , parent=>1);

@KEYEDTABLES=(

        "public.t1",

        "public.t2",

);

@SEQUENCES=(

        "public.t1_id_seq",

        "public.t2_id_seq",

);

Étrangement, cela ne génère pas une sortie compatible directement avec le fichier de configuration. Il est généralement conseillé de concaténer cette sortie à la fin du fichier de configuration, puis d'éditer le fichier ainsi obtenu. Le très gros intérêt de ce script est de récupérer la liste des tables. Dans notre exemple précédent, le fichier de configuration est très simple à faire, car il n'y a que deux tables. Avec une base bien plus conséquente de plusieurs centaines de tables, c'est clairement une autre affaire et une automatisation, même partielle, est bien agréable.

Les scripts slonik_init_cluster, slonik_create_set, slonik_subscribe_set permettent la mise en place de la réplication. Si nous devions refaire la réplication précédente avec les outils Slonik, cela donnerait ceci.

Le fichier de configuration /etc/slony1/slon_tools.conf est le suivant :

if ($ENV{"SLONYNODES"}) {

    require $ENV{"SLONYNODES"};

} else {

    $CLUSTER_NAME = 'replication';

    $LOGDIR = '/var/log/slony1';

    # $SYNC_CHECK_INTERVAL = 1000;

    $MASTERNODE = 1;

    add_node(node     => 1,

             host     => 'debian1',

             dbname   => 'base1',

             port     => 5432,

             user     => 'slony',

             password => 'slony');

    add_node(node     => 2,

             host     => 'debian2',

             dbname   => 'base1',

             port     => 5432,

             user     => 'slony',

             password => 'slony');

}

$SLONY_SETS = {

    "set1" => {

        "set_id" => 1,

        # "origin" => 1,

        # foldCase => 0,

        "table_id"    => 1,

        "sequence_id" => 1,

        "pkeyedtables" => [

                           'public.t1',

                           'public.t2',

                           ],

        "sequences" => ['public.t1_id_seq',

                        'public.t2_id_seq',

                        ],

    },

};

if ($ENV{"SLONYSET"}) {

    require $ENV{"SLONYSET"};

}

# Please do not add or change anything below this point.

1;

Ensuite, initialisons le cluster. En lançant la commande seule, elle affiche le résultat du script Slonik demandé :

postgres@debian1:~$ slonik_init_cluster

# INIT CLUSTER

cluster name = replication;

node 1 admin conninfo='host=debian1 dbname=base1 user=slony port=5432 password=slony';

node 2 admin conninfo='host=debian2 dbname=base1 user=slony port=5432 password=slony';

  init cluster (id = 1, comment = 'Node 1 - base1@debian1');

# STORE NODE

  store node (id = 2, event node = 1, comment = 'Node 2 - base1@debian2');

  echo 'Set up replication nodes';

# STORE PATH

  echo 'Next: configure paths for each node/origin';

  store path (server = 1, client = 2, conninfo = 'host=debian1 dbname=base1 user=slony port=5432 password=slony');

  store path (server = 2, client = 1, conninfo = 'host=debian2 dbname=base1 user=slony port=5432 password=slony');

  echo 'Replication nodes prepared';

  echo 'Please start a slon replication daemon for each node';

En dehors de quelques instructions echo supplémentaires, nous retrouvons le préambule et les instructions de préparation du cluster : init cluster, store node, store path. Maintenant, exécutons-le :

postgres@debian1:~$ slonik_init_cluster | slonik

<stdin>:10: Set up replication nodes

<stdin>:13: Next: configure paths for each node/origin

<stdin>:16: Replication nodes prepared

<stdin>:17: Please start a slon replication daemon for each node

À partir de ce moment, nous pouvons déjà lancer les démons sur chaque nœud. Cela se fait exactement de la même façon que précédemment :

postgres@debian1:~$ slon -f /etc/slony1/slon.conf &>slon.log

et

postgres@debian2:~$ slon -f /etc/slony1/slon.conf &>slon.log

Ensuite, nous pouvons créer le set grâce au script slonik_create_set à qui nous passons un seul argument, le numéro du set à créer :

postgres@debian1:~$ slonik_create_set 1 | slonik

<stdin>:16: Subscription set 1 created

<stdin>:17: Adding tables to the subscription set

<stdin>:21: Add primary keyed table public.t1

<stdin>:25: Add primary keyed table public.t2

<stdin>:28: Adding sequences to the subscription set

<stdin>:32: Add sequence public.t1_id_seq

<stdin>:36: Add sequence public.t2_id_seq

<stdin>:37: All tables added

Et enfin, abonnons le nœud 2 au set 1 :

postgres@debian1:~$ slonik_subscribe_set 1 2 | slonik

<stdin>:10: Subscribed nodes to set 1

Et c'est terminé. La réplication fonctionne.

D'autres scripts existent, par exemple ceux de suppression/désinstallation (slonik_drop_node, slonik_drop_set, slonik_drop_table, slonik_uninstall_nodes, slonik_unsubscribe_set), ceux de bascule (slonik_move_set, slonik_failover, dont nous reparlerons un peu plus tard), ainsi que divers autres (slonik_print_preamble, slonik_merge_sets).

Le seul dont nous allons parler tout de suite est slonik_execute_script. Ce script est intéressant, car il va permettre d'exécuter un script SQL sur les différents nœuds. C'est donc un moyen propre pour mettre à jour le schéma d'une base. Testons sur l'ajout d'une colonne à t1 :

postgres@debian1:~$ slonik_execute_script 1 -c "ALTER TABLE t1 ADD COLUMN nouvellecolonne integer;" | slonik

DDL script consisting of 2 SQL statements

DDL Statement 0: (0,50) [ALTER TABLE t1 ADD COLUMN nouvellecolonne integer;]

DDL Statement 1: (50,52) []

Complete DDL Event...

DDL submission to initial node - PGRES_TUPLES_OK

postgres@debian1:~$ psql -h debian1 -U slony -c "\d t1" base1

                             Table « public.t1 »

     Colonne     | Type   |                  Modificateurs

-----------------+---------+-------------------------------------------------

id              | integer | not null default nextval('t1_id_seq'::regclass)

texte           | text    |

nouvellecolonne | integer |

Index :

    « t1_pkey » PRIMARY KEY, btree (id)

Triggers :

    _replication_logtrigger_1 AFTER INSERT OR DELETE OR UPDATE ON t1 FOR EACH ROW EXECUTE PROCEDURE _replication.logtrigger('_replication', '1', 'kvv')

postgres@debian1:~$ psql -h debian2 -U slony -c "\d t1" base1

                             Table « public.t1 »

     Colonne     | Type   |                  Modificateurs

-----------------+---------+-------------------------------------------------

id              | integer | not null default nextval('t1_id_seq'::regclass)

texte           | text    |

nouvellecolonne | integer |

Index :

    « t1_pkey » PRIMARY KEY, btree (id)

Triggers :

    _replication_denyaccess_1 BEFORE INSERT OR DELETE OR UPDATE ON t1 FOR EACH ROW EXECUTE PROCEDURE _replication.denyaccess('_replication')

La nouvelle colonne se trouve bien dans la table t1 pour les deux serveurs.

Ce qu'il faut retenir des outils AltPerl, c'est qu'ils nous évitent d'avoir à se transformer en expert du langage Slonik. Même s'il est toujours intéressant de vérifier le script Slonik avant de l'exécuter, une simple lecture permettra de s'assurer de son bon fonctionnement.

5.2 Le paquet slony_ctl

Développé pour ses besoins par Stéphane Schildknecht, de la société Dalibo, ce paquet a pour but de simplifier encore plus la mise en place d'une réplication. Exécuter deux scripts bash suffit à lancer la réplication.

Reprenons notre exemple et mettons en place une réplication Slony à partir de cet outil. Commençons par récupérer cet outil sur pgfoundry.org, la forge de PostgreSQL :

postgres@debian1:~$ wget -q http://pgfoundry.org/frs/download.php/2253/slony1-ctl-1.1.4.tar.gz

Nous allons le déballer et le configurer :

postgres@debian1:~$ tar xfz slony1-ctl-1.1.4.tar.gz

postgres@debian1:~$ cd slony1-ctl/slony-ctl

Il existe ici deux répertoires : etc contient les fichiers de configuration, outils contient tous les scripts bash. Allons dans etc. Le premier fichier à configurer est bases.h :

#INSTANCE       NODE    BASE            HOST            PORT

replibase1      1       base1           debian1         5432

replibase1      2       base1           debian2         5432

Ce fichier contient la liste des nœuds. Il indique l'instance de réplication, le numéro du nœud, le nom de la base, celui de l'hôte et enfin le numéro de port TCP/IP. Ici, nous avons deux nœuds, donc deux lignes.

Le second fichier à configurer est relations.h. Il précise la relation entre chaque nœud pour chaque instance :

#INSTANCE   SET     MAITRE ESCLAVE

replibase1 1       1       2

Ici, nous indiquons que le nœud 1 est le fournisseur des données pour le nœud 2 dans le cadre du set1 pour l'instance replibase1.

Le dernier fichier contient des informations plus générales, comme l'emplacement des différents exécutables, fichiers de configuration, etc. Il s'appelle slony_include.h et voici son contenu dans notre cas :

# Configuration file for slony1-ctl

# Path to PG install_dir

PG=/usr

# Path to slony1 install dir

SL_PATH=/usr

SLON_CTL=/var/lib/postgresql/slony1-ctl/slony-ctl

SLON_BIN=${SL_PATH}/bin

SLON_TOOLS=${SL_PATH}/outils

SLON_ETC=$SLON_CTL/etc

SLON_OUTILS=$SLON_CTL/outils

SLON_LOG=$SLON_CTL/logs

SLON_TEMP=/tmp

SLONY_USER=slony

#SLONY_PWD=mypass

# Some binaries

slon_exec=${SLON_BIN}/slon

slonik_exec=${SLON_BIN}/slonik

psql_exec=$PG/bin/psql

pgdump_exec=$PG/bin/pg_dump

Le répertoire des traces n'existe pas, il faut le créer soi-même :

postgres@debian1:~/slony1-ctl/slony-ctl/etc$ cd ..

postgres@debian1:~/slony1-ctl/slony-ctl$ mkdir logs

Maintenant, nous allons utiliser le premier script base. Ce script va vérifier un certain nombre de points et créer un fichier de réplication qui sera exécuté par le second script.

postgres@debian1:~/slony1-ctl/slony-ctl$ cd outils

postgres@debian1:~/slony1-ctl/slony-ctl/outils$ ./01_create_init.sh -c replibase1

Création des fichiers de préambule

Création du fichier d'initialisation de la réplication des bases de replibase1

OK

Le OK indique que tout s'est bien passé. Le fichier /tmp/replibase1.slon a été créé. Le lire explique un peu comment fonctionne slony1-ctl. Lançons la réplication :

postgres@debian1:~/slony1-ctl/slony-ctl/outils$ ./02_exec_init.sh -c replibase1

Démarrage réplication replibase1...                                            

OK

Et voilà. Difficile de faire plus simple.

Vérifions que tout fonctionne :

postgres@debian1:~/slony1-ctl/slony-ctl/outils$ psql -q -h debian2 base1

Mot de passe :                                                       

base1=# select count(*) from t1;

count                          

--------                        

100000                         

(1 ligne)                       

base1=# select count(*) from t2;

count                          

-------                         

20000                          

(1 ligne)                       

base1=# \q

postgres@debian1:~/slony1-ctl/slony-ctl/outils$ psql -q -h debian1 base1

Mot de passe :                                                       

base1=# insert into t2 (texte, autre) values ('yop', true);

INSERT 0 1                                                 

base1=# \q                                                 

postgres@debian1:~/slony1-ctl/slony-ctl/outils$ psql -q -h debian2 base1

base1=# select count(*) from t2;

count

-------

20001

(1 ligne)

L'outil est encore jeune, il reste encore quelques améliorations possibles pour en faire un produit mature. Néanmoins, la base est bonne et rend la mise en place de la réplication d'une base avec Slony extrêmement simple. De plus, il est facilement personnalisable étant donné qu'il s'agit de simples scripts bash.

6. Comment surveiller la réplication ?

Dans une réplication Slony, il est nécessaire de surveiller deux choses :

- que les données sont bien répliquées ;

- que le schéma ne change pas.

Pour le premier, nous allons pouvoir nous aider d'une vue Slony appelée sl_status. Cette vue peut nous donner un grand nombre d'informations :

postgres@debian1:~$ psql -q base1

base1=# \x

base1=# SELECT * FROM _replication.sl_status;

-[RECORD 1]----------------------------------------------------

st_origin                 | 1

st_received               | 2

st_last_event             | 1454

st_last_event_ts          | 2009-08-12 17:28:54.284162

st_last_received          | 1454

st_last_received_ts       | 2009-08-12 16:42:43.070423

st_last_received_event_ts | 2009-08-12 17:28:54.284162

st_lag_num_events         | 0

st_lag_time               | 00:00:06.284245

Voici le descriptif de chaque colonne :

- st_origin est l'identifiant du nœud origine (le maître) ;

- st_received est l'identifiant du nœud abonné (l'esclave) ;

- st_last_event est l'identifiant du dernier événement survenu ;

- st_last_event_ts est l'horodatage du dernier événement survenu ;

- st_last_received est l'identifiant du dernier événement reçu ;

- st_last_received_ts est l'horodatage du dernier événement reçu ;

- st_last_received_event_ts est l'horodatage du dernier événement reçu ;

- st_lag_num_events est le lag en nombre d'événements (autrement dit st_last_receivedst_last_event) ;

- st_lag_time est le lag en heures/minutes/secondes (autrement dit l'heure actuelle – st_last_received_event_ts).

Les colonnes les plus intéressantes sont donc les deux dernières, le but étant d'avoir le lag minimum possible. Généralement, le nombre st_lag_num_events devra se trouver à 0 ou à 1. Plus il est petit, et plus les données sont synchronisées. Si les deux serveurs sont de plus en plus désynchronisés, il va falloir trouver la raison de ce problème et, pour cela, les traces sont votre meilleur ami.

Pour s'assurer que le schéma ne change pas, vous pouvez utiliser un outil comme check_postgres. Écrit par Greg Sabino Mulane, autre grand nom dans le monde PostgreSQL et Perl, de la société End Point Corporation, ce script Perl est principalement conçu pour s'intégrer à un système Nagios, voire à un système MRTG. Il est capable de réaliser différentes actions. Celle qui nous intéresse ici est same_schema. Cette action est capable de vérifier les différences de schéma entre deux bases de données. Testons cela rapidement :

postgres@debian1:~$ wget -q http://bucardo.org/check_postgres/check_postgres.pl

postgres@debian1:~$ chmod +x check_postgres.pl

postgres@debian1:~$ ./check_postgres.pl --action same_schema \

> --host debian1--dbname base1 --dbuser slony \

> --host2 debian2 --dbname2 base1 --dbuser2 slony \

> --warning "notriger=replication"

POSTGRES_SAME_SCHEMA OK: DB "base1" (host:debian1 => debian2) Les bases de données ont les mêmes éléments | time=0.20

Modifions base1 pour qu'il y ait une différence. Nous allons par exemple ajouter une table t3, ajouter un index à t2 et une colonne à t1 :

postgres@debian1:~$ psql -q base1                                      

base1=# ALTER TABLE t1 ADD COLUMN pascool varchar(255);

base1=# CREATE INDEX beurk ON t2(autre);

base1=# CREATE TABLE t3(id serial, contenu text);

NOTICE: CREATE TABLE créera des séquences implicites « t3_id_seq » pour la colonne serial « t3.id »

base1=#\q

postgres@debian1:~$ ./check_postgres.pl --action same_schema \

> --host debian1 --dbname base1 --dbuser slony \

> --host2 debian2 --dbname2 base1 --dbuser2 slony \

> --warning "notriger=replication" \

> --verbose

POSTGRES_SAME_SCHEMA CRITICAL: DB "base1" (host:debian1 => debian2) Les bases de données sont différentes. éléments différents : 7 | time=0.17

Table in 1 but not 2: public.t3

Sequence in 1 but not 2: public.t3_id_seq

Trigger in 1 but not 2: _replication_logtrigger_1

Trigger in 1 but not 2: _replication_logtrigger_2

Trigger in 2 but not 1: _replication_denyaccess_1

Trigger in 2 but not 1: _replication_denyaccess_2

Table "public.t1" on 1 has column "pascool", but 2 does not.

Notez l'option –verbose permettant d'obtenir les objets, chacun sur une ligne.

En exécutant ce script régulièrement (soit par Nagios, soit par un cron), vous pourrez être averti d'une différence de schéma pouvant être un souci pour votre réplication.

7. Comment basculer le maître ?

Il est possible de faire un switchover comme un failover avec Slony.

Ces deux opérations passent par des instructions Slonik bien qu'il soit possible de passer par des outils plus évolués.

slonik_move_set permettra de faire un switchover alors que slonik_failover, comme son nom l'indique, fera un failover.

Du côté slony1-ctl, il faut utiliser 82_exec_switch.sh pour le switchover et 92_exec_fail.sh pour le failover. Prenons un exemple pour cet outil. Disons que nous voulons basculer le maître sur le nœud 2 bien que le 1 soit toujours vivant :

postgres@debian1:~/slony1-ctl/slony-ctl/outils$ ./82_exec_switch.sh -c replibase1 -f 1 -b 2

Bascule de replibase1 : 1 vers 2...

OK

postgres@debian1:~/slony1-ctl/slony-ctl/outils$ psql -q -h debian1 base1

base1=# INSERT INTO t2 (texte, autre) VALUES ('yop2', false);

ERREUR: Slony-I: Table t1 is replicated and cannot be modified on a subscribed node

base1=# \q

postgres@debian1:~/slony1-ctl/slony-ctl/outils$ psql -q -h debian2 base1

base1=# INSERT INTO t2 (texte, autre) VALUES ('yop2', false);

base1=# SELECT * FROM t2 WHERE texte='yop2';

   id | texte | autre

-----------------------

20002 | yop2 | f     

(1 ligne)

base1=# \q

postgres@debian1:~/slony1-ctl/slony-ctl/outils$ psql -q -h debian1 base1

base1=# SELECT * FROM t2 WHERE texte='yop2';

   id | texte | autre

-----------------------

20002 | yop2 | f     

(1 ligne)

La bascule est bien faite. Il n'est plus possible de modifier la base sur debian1, et les modifications sur debian2 sont répliquées sur debian1.

Faisons maintenant un failover sur debian1. Commençons par arrêter debian2 (un simple shutdown -h now suffit). Puis, retournons sur debian1 et utilisons les scripts AltPerl :

postgres@debian1:~$ ssh debian2

ssh: connect to host debian2 port 22: No route to host

Nous ne pouvons plus nous connecter sur debian2. Nous devons donc basculer le service en urgence sur debian1.

postgres@debian1:~/slony1-ctl/slony-ctl/outils$ psql -q -h debian1 base1

base1=# INSERT INTO t2 (texte, autre) VALUES ('yop2', false);

ERREUR: Slony-I: Table t1 is replicated and cannot be modified on a subscribed node

base1=# \q

Ce dernier se considère toujours comme un nœud esclave. Lançons dès maintenant le script Slonik de bascule pour failover :

postgres@debian1:~/slony1-ctl/slony-ctl/outils$ cd

postgres@debian1:~$ slonik_failover 2 1 | slonik

<stdin>:4: NOTICE: failed node has no direct receivers – move now

<stdin>:10: Replication sets originating on 2 failed over to 1

postgres@debian1:~$ psql -q -h debian1 base1

base1=# INSERT INTO t2 (texte, autre) VALUES ('yop2', false);

INSERT 0 1

Parfait, le serveur debian1 est maître dès maintenant.

8. Petit récapitulatif

Avantages majeurs :

- simple à mettre en place, mais un peu complexe à appréhender/maîtriser ;

- très grande granularité ;

- les esclaves en lecture seule ;

- mise à jour de PostgreSQL rapide et avec le moins possible d'arrêts de production.

Inconvénients majeurs :

- pas de réplication automatique des objets ;

- pas de réplication du TRUNCATE avant la 8.4 ;

- une documentation qui, bien que complète, laisse à désirer.

Conclusion

Slony est un outil très intéressant. Il est fiable. Son gros souci est le travail qu'il demande à l'administrateur. Le moindre oubli d'une table à déclarer, et les données de cette table ne sont pas disponibles sur les esclaves. De plus, certains problèmes, relevant plutôt du détail que d'un problème de conception, entachent cet outil. Il mériterait certainement que ses développeurs s'attachent un peu plus à supprimer les petits détails qui le rendent encore un peu rugueux.

Heureusement, il existe quelques outils qui facilitent la vie, lors de son installation, comme lors de la surveillance de la réplication.

 



Article rédigé par

Par le(s) même(s) auteur(s)

Supervision d’une instance PostgreSQL

Magazine
Marque
Linux Pratique
Numéro
142
Mois de parution
mars 2024
Spécialité(s)
Résumé

Maintenant que nous sommes rassurés suite à l’installation de solutions de sauvegarde [1], il est temps de s’occuper de la supervision de notre instance. Il existe différents types d’outils, certains en ligne de commandes, certains graphiques (généralement une application web), certains font de la rétro-analyse alors que d’autres font de la supervision en direct. Encore une fois avec PostgreSQL, les outils sont nombreux et la difficulté vient principalement du choix offert.

Les derniers articles Premiums

Les derniers articles Premium

PostgreSQL au centre de votre SI avec PostgREST

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Dans un système d’information, il devient de plus en plus important d’avoir la possibilité d’échanger des données entre applications. Ce passage au stade de l’interopérabilité est généralement confié à des services web autorisant la mise en œuvre d’un couplage faible entre composants. C’est justement ce que permet de faire PostgREST pour les bases de données PostgreSQL.

La place de l’Intelligence Artificielle dans les entreprises

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

L’intelligence artificielle est en train de redéfinir le paysage professionnel. De l’automatisation des tâches répétitives à la cybersécurité, en passant par l’analyse des données, l’IA s’immisce dans tous les aspects de l’entreprise moderne. Toutefois, cette révolution technologique soulève des questions éthiques et sociétales, notamment sur l’avenir des emplois. Cet article se penche sur l’évolution de l’IA, ses applications variées, et les enjeux qu’elle engendre dans le monde du travail.

Petit guide d’outils open source pour le télétravail

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Ah le Covid ! Si en cette période de nombreux cas resurgissent, ce n’est rien comparé aux vagues que nous avons connues en 2020 et 2021. Ce fléau a contraint une large partie de la population à faire ce que tout le monde connaît sous le nom de télétravail. Nous avons dû changer nos habitudes et avons dû apprendre à utiliser de nombreux outils collaboratifs, de visioconférence, etc., dont tout le monde n’était pas habitué. Dans cet article, nous passons en revue quelques outils open source utiles pour le travail à la maison. En effet, pour les adeptes du costume en haut et du pyjama en bas, la communauté open source s’est démenée pour proposer des alternatives aux outils propriétaires et payants.

Sécurisez vos applications web : comment Symfony vous protège des menaces courantes

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Les frameworks tels que Symfony ont bouleversé le développement web en apportant une structure solide et des outils performants. Malgré ces qualités, nous pouvons découvrir d’innombrables vulnérabilités. Cet article met le doigt sur les failles de sécurité les plus fréquentes qui affectent même les environnements les plus robustes. De l’injection de requêtes à distance à l’exécution de scripts malveillants, découvrez comment ces failles peuvent mettre en péril vos applications et, surtout, comment vous en prémunir.

Les listes de lecture

9 article(s) - ajoutée le 01/07/2020
Vous désirez apprendre le langage Python, mais ne savez pas trop par où commencer ? Cette liste de lecture vous permettra de faire vos premiers pas en découvrant l'écosystème de Python et en écrivant de petits scripts.
11 article(s) - ajoutée le 01/07/2020
La base de tout programme effectuant une tâche un tant soit peu complexe est un algorithme, une méthode permettant de manipuler des données pour obtenir un résultat attendu. Dans cette liste, vous pourrez découvrir quelques spécimens d'algorithmes.
10 article(s) - ajoutée le 01/07/2020
À quoi bon se targuer de posséder des pétaoctets de données si l'on est incapable d'analyser ces dernières ? Cette liste vous aidera à "faire parler" vos données.
Voir les 125 listes de lecture

Abonnez-vous maintenant

et profitez de tous les contenus en illimité

Je découvre les offres

Déjà abonné ? Connectez-vous