Mysql
 sql >> Base de données >  >> RDS >> Mysql

Contrôles de santé importants pour vos serveurs MySQL Source-Replica

Dans une configuration haute disponibilité (HA) source-réplica MySQL, il est important de surveiller en permanence l'état des serveurs source et réplica afin de pouvoir détecter les problèmes potentiels et prendre des mesures correctives . Dans cet article de blog, nous expliquons quelques contrôles de santé de base que vous pouvez effectuer sur vos nœuds source et réplica MySQL pour vous assurer que votre configuration est saine. Le programme ou le script de surveillance doit alerter le cadre de haute disponibilité en cas d'échec de l'un des contrôles de santé, permettant au cadre de haute disponibilité de prendre des mesures correctives afin d'assurer la disponibilité du service.

Vérifications de l'état du serveur source MySQL

Nous vous recommandons d'exécuter votre programme ou vos scripts de surveillance des sources MySQL à intervalles fréquents. En supposant que le script de surveillance s'exécute sur le même serveur que votre serveur MySQL, vous pouvez vérifier les éléments suivants :

  1. Assurez-vous que le service MySQL est en cours d'exécution

    Cela peut être fait à l'aide d'une commande simple comme :

    > pgrep mysqld

    OU

    >service mysqld status
  2. Assurez-vous que vous pouvez vous connecter à MySQL et effectuer une requête simple

    Nous recommandons d'avoir un court délai d'attente pour ces commandes afin que vous puissiez détecter rapidement si MySQL ne répond pas. Cela peut être réalisé à partir d'un appel comme :

    /usr/bin/timeout 5 mysql -u testuser -ptestpswd -e 'select * from mysql.test’

    Assurez-vous d'examiner la valeur de sortie de la commande ci-dessus :

    Valeur de sortie =0 ⇒ Succès

    Valeur de sortie =1 ⇒ Échec

    Exit-value=124 ⇒ Timeout

    Si la commande expire, cela signifie que le service MySQL n'est pas assez réactif. Nous vous conseillons de réessayer après un certain temps afin d'éviter les faux résultats négatifs. Si le code de sortie indique un échec, le code de retour de MySQL nous indiquera la raison de l'échec. Un exemple d'échec est l'erreur "Trop de connexions" de MySQL qui se produit si le nombre de connexions au serveur dépasse votre valeur de configuration "max_connections".

  3. Assurez-vous que la source MySQL s'exécute en mode lecture-écriture

    Vous pouvez utiliser la commande suivante pour vous assurer que la source MySQL s'exécute en mode lecture-écriture :

    /usr/bin/timeout 5 mysql -u testuser -ptestpswd -e "SELECT @@global.read_only"

    La source est censée être toujours exécutée en mode lecture-écriture, et par conséquent, la valeur de read_only doit être "OFF".

    Il est également possible d'associer cette étape à l'étape 2, et au lieu de faire la requête test 'select * from mysql.test, nous pouvons simplement faire la requête pour obtenir le read_only valeur.

Bilans de santé importants pour vos serveurs MySQL Source-ReplicaClick To Tweet

Vérifications de l'état du serveur de réplication MySQL

Vous pouvez exécuter la surveillance de vos répliques MySQL à une fréquence moindre par rapport à la source, car elles ne gèrent pas les écritures de données. Les trois premières étapes de la vérification de l'état de votre instance dupliquée peuvent être identiques à celles de la source, sauf que nous devons nous assurer que l'instance dupliquée s'exécute en mode lecture seule :la valeur de la variable read_only doit être "ON" à l'étape 3. .

En outre, nous pouvons effectuer davantage de vérifications sur le réplica pour nous assurer que son état de réplication est sain, par exemple :

  1. Le réplica est configuré pour répliquer à partir de la bonne source.

  2. La connexion du réplica à la source est saine.

  3. Le réplica est capable d'appliquer les événements source qu'il a reçus.

Il est possible de vérifier tout ce qui précède à l'aide de la commande "show replica status". Par exemple :

mysql> show replica status \G;

*************************** 1. row ***************************

Replica_IO_State: Waiting for source to send event

Source_Host: 172.31.17.43

Source_User: repl_user

Source_Port: 3306

Connect_Retry: 10

Source_Log_File: mysql-bin.000001

Read_Source_Log_Pos: 7510

Relay_Log_File: relay-log.000006

Relay_Log_Pos: 414

Relay_Source_Log_File: mysql-bin.000001

Replica_IO_Running: Yes

Replica_SQL_Running: Yes

******************Truncated*********************************
  • La valeur Source_Host indique que le serveur source est configuré pour la réplication.

  • Pour la valeur Replica_IO_Running, "Oui" indique que le réplica s'est connecté à la source et reçoit le flux de réplication.

  • Pour la valeur Replica_SQL_Running, "Oui" indique que l'applicateur du réplica est en cours d'exécution et capable d'appliquer tous les événements reçus de la source.

Dans cet article de blog, nous avons discuté de quelques vérifications simples qui peuvent détecter s'il existe des problèmes de base dans vos serveurs source et réplique MySQL. En général, le mécanisme de détection des défaillances dans une configuration à haute disponibilité est un sujet complexe et nécessite un cadre de haute disponibilité robuste à travers lequel la surveillance de la vérification de l'état doit être mise en œuvre. Vous pouvez en savoir plus sur les détails de notre cadre de haute disponibilité dans notre article de blog sur le cadre de haute disponibilité MySQL expliqué – Partie I :Introduction.