MariaDB : résoudre l'erreur 1062 (duplicate entry for key PRIMARY) lors de la réplication des bases de données

Si vous utilisez les fonctions de réplication de MySQL ou MariaDB, il peut arriver que votre slave bloque sur une instruction qui devrait avoir un identifiant unique mais que le serveur tente d'insérer deux fois.

Créer un serveur High Availability : la réplication des bases de données photo

Et quand c'est le cas, la réplication des données prend fin donc c'est un problème à corriger rapidement si vous voulez que votre système haute disponibilité perdure et soit vraiment efficace en cas de coup dur.

Identification du problème

Je me suis rendu compte du problème lorsque j'ai ajouté de nouvelles bases à répliquer : j'ai relancé la procédure d'installation, relancé les serveurs, ajouté les nouvelles positions, démarré les slaves.

On regarde le status du slave :

MariaDB [(none)]> SHOW SLAVE STATUS\G

Résultat :

*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 10.134.23.164
                  Master_User: replicator
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mariadb-bin.000210
          Read_Master_Log_Pos: 2753885
               Relay_Log_File: mysqld-relay-bin.000002
                Relay_Log_Pos: 103794
        Relay_Master_Log_File: mariadb-bin.000210
             Slave_IO_Running: Yes
            Slave_SQL_Running: No
              Replicate_Do_DB:
          Replicate_Ignore_DB:
           Replicate_Do_Table:
       Replicate_Ignore_Table:
      Replicate_Wild_Do_Table:
  Replicate_Wild_Ignore_Table:
                   Last_Errno: 1062
                   Last_Error: Error 'Duplicate entry '56-724' for key 'PRIMARY'' on query. Default database: 'frenchy'. Query: 'INSERT INTO `wp_term_relationships` (`object_id`, `term_taxonomy_id`) VALUES (56, 724)'
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 1563407
              Relay_Log_Space: 1296874
              Until_Condition: None
               Until_Log_File:
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File:
           Master_SSL_CA_Path:
              Master_SSL_Cert:
            Master_SSL_Cipher:
               Master_SSL_Key:
        Seconds_Behind_Master: NULL
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error:
               Last_SQL_Errno: 1062
               Last_SQL_Error: Error 'Duplicate entry '56-724' for key 'PRIMARY'' on query. Default database: 'frenchy'. Query: 'INSERT INTO `wp_term_relationships` (`object_id`, `term_taxonomy_id`) VALUES (56, 724)'
  Replicate_Ignore_Server_Ids:
             Master_Server_Id: 1
               Master_SSL_Crl:
           Master_SSL_Crlpath:
                   Using_Gtid: No
                  Gtid_IO_Pos:
      Replicate_Do_Domain_Ids:
  Replicate_Ignore_Domain_Ids:
                Parallel_Mode: conservative
1 row in set (0.00 sec)

Comme on peut le constater, plusieurs choses ne tournent pas rond et empêchent la synchronisation des données entre nos deux serveurs :

Slave_SQL_Running: No
Last_SQL_Errno: 1062
Last_SQL_Error: Error 'Duplicate entry '56-724' for key 'PRIMARY'' on query. Default database: 'frenchy'. Query: 'INSERT INTO `wp_term_relationships` (`object_id`, `term_taxonomy_id`) VALUES (56, 724)'

Solution : un RESET sur le slave

En me documentant sur le problème, j'ai lu pas mal de choses sur le net. Certains préfèrent cacher l'erreur, au risque de perdre des données. D'autres préfèrent tout effacer pour recommencer la réplication.

Aucune de ces "solutions" ne me conviennent donc nous allons procéder autrement. Comme l'erreur n'apparaît que sur le serveur BACKUP et non sur le serveur principal, c'est sur lui que nous travaillerons.

Sur le serveur BACKUP, dans MariaDB, on arrête notre slave :

MariaDB [(none)]> STOP SLAVE;
Query OK, 0 rows affected (0.01 sec)

On flush les privilèges et donc les utilisateurs connectés :

MariaDB [(none)]> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.00 sec)

On efface les fichiers logs de notre slave. C'est comme effacer une ardoise pour repartir sur des bases saines. Cela ne supprime aucune donnée - cf le manuel sur RESET :

MariaDB [(none)]> RESET SLAVE;
Query OK, 0 rows affected (0.00 sec)

Et on redémarre notre slave :

MariaDB [(none)]> START SLAVE;
Query OK, 0 rows affected (0.00 sec)

On vérifie de nouveau le status de notre slave :

MariaDB [(none)]> SHOW SLAVE STATUS\G

Résultat :

*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 10.134.23.164
                  Master_User: replicator
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mariadb-bin.000196
          Read_Master_Log_Pos: 77900062
               Relay_Log_File: mysqld-relay-bin.000002
                Relay_Log_Pos: 6318821
        Relay_Master_Log_File: mariadb-bin.000192
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB:
          Replicate_Ignore_DB:
           Replicate_Do_Table:
       Replicate_Ignore_Table:
      Replicate_Wild_Do_Table:
  Replicate_Wild_Ignore_Table:
                   Last_Errno: 0
                   Last_Error:
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 6318531
              Relay_Log_Space: 344030331
              Until_Condition: None
               Until_Log_File:
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File:
           Master_SSL_CA_Path:
              Master_SSL_Cert:
            Master_SSL_Cipher:
               Master_SSL_Key:
        Seconds_Behind_Master: 833890
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error:
               Last_SQL_Errno: 0
               Last_SQL_Error:
  Replicate_Ignore_Server_Ids:
             Master_Server_Id: 1
               Master_SSL_Crl:
           Master_SSL_Crlpath:
                   Using_Gtid: No
                  Gtid_IO_Pos:
      Replicate_Do_Domain_Ids:
  Replicate_Ignore_Domain_Ids:
                Parallel_Mode: conservative
1 row in set (0.00 sec)

Nous avons bien :

Slave_IO_Running: Yes
Slave_SQL_Running: Yes

Et voilà, plus d'erreur et une réplication active dans les deux sens.

Fear the Walking Dead saison 3

La saison 3 de Fear the Walking Dead a commencé sur AMC.

Fear the Walking Dead saison 3 photo

Travis, Madison et Alicia sont capturés par un groupe armé et emmenés dans un complexe militaire. Travis est séparé, enfermé dans un sous-sol, tandis que Madison et Alicia sont retenues captives dans un bureau.

Au sous-sol, Travis retrouve Nick et Luciana qui est blessée, avec d'autres prisonniers. Ils s'enfuient mais Travis est recapturé. Nick et Luciana passent par les égouts. Pendant ce temps, Madison et Alicia attaquent leur geôlier, Troy, et Madison empale son oeil avec une petite cuiller.

Lorsque les walkers arrivent dans le complexe, Travis, Luciana et Alicia prennent l'hélicoptère tandis que Madison et Nick sont obligés de partir en Jeep avec Troy.

Curieusement, j'ai accroché à cette saison, ce qui n'a jamais été le cas auparavant. C'est à croire que les scénaristes ont fait un travail d'écriture ce coup-ci: c'est un peu plus proche de la série mère, The Walking Dead, et un peu plus violent et rythmé - ce qui, il faut bien l'avouer, n'a pas été le cas lors des deux premières saisons fleuves.

J'attends de voir si la suite est du même acabit. Seize épisodes ont été prévus pour cette saison.

Lire la suite! »

Serveur dédié : mise à jour vers Debian 9 Stretch

Cette semaine, le système d'exploitation du serveur principal passe de Debian 8 Jessie à Debian 9 Stretch.

Serveur dédié : mise à jour vers Debian 9 Stretch photo

Mise à jour des paquets du système

La mise à jour s'est faite plutôt simplement pour la majeure partie des paquets :

apt update && apt upgrade

mais il a fallu s'y reprendre à plusieurs fois pour les paquets restants :

apt install <liste des paquets restants>

Changements dans la configuration

Quelques changements notables sont à noter.

Configuration apt

On vérifie que tous nos dépôts pointent bien vers la version Stretch:

nano /etc/apt/sources.list

On sauvegarde et on lance les mises à jour:

apt update && apt upgrade

Configuration SSH

La configuration SSH a été modifiée et certaines directives ne sont plus valables. Avant de redémarrer le serveur SSH ou de rebooter et de perdre tout accès au serveur SSH, assurez-vous que la configuration est correcte :

sshd -t

Résultats :

/etc/ssh/sshd_config line 25: Deprecated option KeyRegenerationInterval
/etc/ssh/sshd_config line 26: Deprecated option ServerKeyBits
/etc/ssh/sshd_config line 44: Deprecated option RhostsRSAAuthentication

Il ne vous reste plus qu'à éditer le fichier de configuration SSH:

nano /etc/ssh/sshd_config

J'ai désactivé les lignes qui posaient problème et ai rajouté de nouveaux protocoles de clé :

HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key

Sauvegardez le fichier puis lancez cette commande pour créer les couples de clés privées/publiques dans /etc/ssl:

ssh-keygen -A

Résultat:

ssh-keygen: generating new host keys: ECDSA ED25519

Vérifiez une dernière fois qu'il n'y a aucun problème avec le fichier de configuration SSH:

sshd -t

et redémarrez le service SSH:

service ssh restart

Configuration de Courier

C'est le bon moment de revoir la configuration IMAP et POP de Courier.

On commence par renouveler notre fichier Diffie-Hellman en 4096 bits:

cd /etc/courier
openssl dhparam -out dhparams4096.pem 4096

et on revoit la configuration de /etc/courier/imap-ssl :

SSLPORT=993

SSLADDRESS=0

SSLPIDFILE=/run/courier/imapd-ssl.pid

SSLLOGGEROPTS="-name=imapd-ssl"

IMAPDSSLSTART=YES

IMAPDSTARTTLS=YES

IMAP_TLS_REQUIRED=1

COURIERTLS=/usr/bin/couriertls

TLS_PROTOCOL=TLS1_2:TLS1_1:TLS1

TLS_STARTTLS_PROTOCOL=TLS1_2:TLS1_1:TLS1

TLS_CIPHER_LIST="ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS"

TLS_KX_LIST=ALL

TLS_COMPRESSION=ALL

TLS_CERTS=X509

TLS_DHCERTFILE=/etc/courier/dhparams4096.pem

TLS_CERTFILE=/etc/courier/skyminds-cert.pem

TLS_TRUSTCERTS=/etc/ssl/certs

TLS_VERIFYPEER=NONE

TLS_CACHEFILE=/var/lib/courier/couriersslcache
TLS_CACHESIZE=524288

MAILDIRPATH=Maildir

Le chemin de SSLPIDFILE a changé donc pensez à le vérifier.

Certificat TLS pour Courier

Depuis que j'utilise les certificats TLS de Let's Encrypt, il y a une petite modification a exécuter pour que le certificat s'applique aussi à notre serveur de mail : créer automatiquement un certificat pour Courier dès que notre certificat principal est généré.

On crée un script bash pour compiler notre clé privée et notre certificat Let's Encrypt :

nano /home/scripts/letsencrypt-skyminds-mailserver.sh

avec :

#!/bin/bash
cat /etc/letsencrypt/live/skyminds.net/privkey.pem /etc/letsencrypt/live/skyminds.net/fullchain.pem > /etc/courier/skyminds-cert.pem

et on édite notre fichier Let's Encrypt pour le renouvellement :

nano /etc/letsencrypt/renewal/skyminds.net.conf

et on ajoute la directive renew_hook avec notre nouveau script:

[renewalparams]
account = ...
renew_hook = /home/scripts/letsencrypt-skyminds-mailserver.sh

Il ne reste plus qu'à éditer la configuration IMAP:

nano /etc/courier/imapd-ssl

et y mettre :

TLS_CERTFILE=/etc/courier/skyminds-cert.pem

puis redémarrez le service:

service courier-imap-ssl restart

Voilà, il me semble que ce sont les principales modifications que j'ai effectué lors de la mise à jour vers Debian 9.

Pin It on Pinterest

Spelling error report

The following text will be sent to our editors: