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

Comment déployer Percona Server pour MySQL pour une haute disponibilité

Percona Server pour MySQL 8.0 offre un certain nombre de solutions de clustering pour une haute disponibilité prêtes à l'emploi :

  • Maître unique :
    • Réplication asynchrone
    • Réplication semi-synchrone
  • Multi-maître :
    • Réplication de groupe
    • InnoDB Cluster (une combinaison de MySQL Router, MySQL Shell et Percona Server avec réplication de groupe)

La solution la plus populaire, la plus éprouvée et la plus évolutive est, bien sûr, la réplication asynchrone. Dans cet article de blog, nous allons déployer une configuration de réplication Percona Server spécifiquement pour la haute disponibilité. Les instructions décrites ici sont basées sur CentOS 7.

Installation du serveur Percona

Pour une haute disponibilité, nous avons besoin d'au moins deux nœuds dans une configuration simple de réplication maître-esclave :

  • db1 - maître (192.168.0.61)
  • db2 - esclave (192.168.0.62)

Les étapes décrites dans cette section doivent être effectuées sur tous les nœuds de base de données (db1 et db2). Nous allons commencer par installer le package de référentiel Percona :

$ yum -y install https://repo.percona.com/yum/percona-release-latest.noarch.rpm

La dernière version stable à ce stade est Percona Server pour MySQL 8.0, mais par défaut, le package de référentiel n'est configuré que jusqu'à la version 5.7. Le package percona-release contient un script qui peut activer des référentiels supplémentaires pour les nouveaux produits. Exécutons ce script et activons les référentiels 8.0 :

$ percona-release setup ps80

Installez ensuite les derniers Percona Server et Percona Xtrabackup :

$ yum -y install percona-server-server percona-xtrabackup-80

En ce moment, vous devriez installer un serveur Percona pour MySQL 8.0.21. Tous les packages de dépendance seront installés comme les packages partagés, partagés et clients. Nous pouvons ensuite activer le service MySQL au démarrage et démarrer le service :

$ systemctl enable mysql
$ systemctl start mysql

Un nouveau mot de passe root sera généré lors du premier démarrage. Nous devons d'abord récupérer les informations du mot de passe root à partir du journal des erreurs MySQL (la valeur par défaut est /var/log/mysqld.log dans les systèmes basés sur RHEL) :

$ cat /var/log/mysqld.log | grep temporary
2020-11-06T04:53:07.402040Z 6 [Note] [MY-010454] [Server] A temporary password is generated for [email protected]: o%(_M>t1)R-P

Comme vous pouvez le voir, le mot de passe généré est "o%(_M>t1)R-P". Ensuite, nous devons effectuer une tâche post-installation pour sécuriser l'installation du serveur MySQL. Exécutez la commande suivante :

$ mysql_secure_installation

Securing the MySQL server deployment.

Enter password for user root:

The existing password for the user account root has expired. Please set a new password.


New password:
Re-enter new password:

The 'validate_password' component is installed on the server.
The subsequent steps will run with the existing configuration
of the component.

Using existing password for root.


Estimated strength of the password: 100
Change the password for root ? ((Press y|Y for Yes, any other key for No) : y

New password:

Re-enter new password:

Estimated strength of the password: 100

Do you wish to continue with the password provided?(Press y|Y for Yes, any other key for No) : y

By default, a MySQL installation has an anonymous user,
allowing anyone to log into MySQL without having to have
a user account created for them. This is intended only for
testing, and to make the installation go a bit smoother.

You should remove them before moving into a production
environment.

Remove anonymous users? (Press y|Y for Yes, any other key for No) : y
Success.

Normally, root should only be allowed to connect from
'localhost'. This ensures that someone cannot guess at
the root password from the network.

Disallow root login remotely? (Press y|Y for Yes, any other key for No) : y
Success.

By default, MySQL comes with a database named 'test' that
anyone can access. This is also intended only for testing,
and should be removed before moving into a production
environment.

Remove test database and access to it? (Press y|Y for Yes, any other key for No) : y
 - Dropping test database...
Success.

 - Removing privileges on test database...
Success.

Reloading the privilege tables will ensure that all changes
made so far will take effect immediately.

Reload privilege tables now? (Press y|Y for Yes, any other key for No) : y
Success.

All done!

Le mot de passe root généré expirera immédiatement lors de la première connexion root. Le script d'aide ci-dessus nous aide à configurer un nouveau mot de passe root MySQL, à désactiver la connexion à distance pour root, à supprimer la base de données de test et les utilisateurs anonymes et à recharger également les tables de privilèges.

Nous sommes maintenant prêts à configurer la fonctionnalité de haute disponibilité pour Percona Server 8.0.

Réplication semi-synchrone

La réplication semi-synchrone se situe entre la réplication asynchrone et entièrement synchrone. La source attend qu'au moins un réplica ait reçu et consigné les événements, puis valide la transaction. La source n'attend pas que toutes les répliques accusent réception, et elle ne nécessite qu'un accusé de réception de la part des répliques, et non que les événements aient été entièrement exécutés et validés côté réplique. La réplication semi-synchrone garantit donc que si la source plante, toutes les transactions qu'elle a validées ont été transmises à au moins une réplique.

Pour une intégrité de réplication optimale, choisissez la réplication semi-synchrone. Pour le configurer, sur le premier nœud, db1 (192.168.0.61), ajoutez les lignes suivantes dans /etc/my.cnf (il doit être sous la section [mysqld]) :

# Compatibility
default-authentication-plugin = mysql_native_password

# Replication
server_id = 61 # must be distinct on all nodes in the cluster
binlog_format = ROW
log_bin = binlog
log_slave_updates = 1
gtid_mode = ON
enforce_gtid_consistency = 1
binlog_expire_logs_seconds = 604800 # 7 days
sync_binlog = 1
report_host = 192.168.0.61 # IP address of this host
read_only = OFF # Set ON on slave
super_read_only = OFF # Set ON on slave

# Replication safety
master_info_repository = TABLE
relay_log_info_repository = TABLE
relay_log_recovery = ON

# Semi-sync
plugin_load_add = rpl_semi_sync_master=semisync_master.so
plugin_load_add = rpl_semi_sync_slave=semisync_slave.so
rpl_semi_sync_master_enabled = ON
rpl_semi_sync_master_timeout = 1000
rpl_semi_sync_slave_enabled = ON

Sur le deuxième nœud, db2 (192.168.0.62), ajoutez les lignes suivantes dans /etc/my.cnf (cela doit être sous la section [mysqld]) :

# Compatibility
default-authentication-plugin = mysql_native_password

# Replication
server_id = 62 # must be distinct on all nodes in the cluster
binlog_format = ROW
log_bin = binlog
log_slave_updates = 1
gtid_mode = ON
enforce_gtid_consistency = 1
binlog_expire_logs_seconds = 604800 # 7 days
sync_binlog = 1
report_host = 192.168.0.62 # IP address of this host
read_only = ON # Set ON on slave
super_read_only = ON # Set ON on slave

# Replication safety
master_info_repository = TABLE
relay_log_info_repository = TABLE
relay_log_recovery = ON

# Semi-sync
plugin_load_add = rpl_semi_sync_master=semisync_master.so
plugin_load_add = rpl_semi_sync_slave=semisync_slave.so
rpl_semi_sync_master_enabled = ON
rpl_semi_sync_master_timeout = 1000
rpl_semi_sync_slave_enabled = ON

Nous pouvons ensuite procéder à la configuration du lien de réplication comme décrit dans la section "Configuration du lien de réplication" plus bas.

Réplication asynchrone

Pour la réplication asynchrone, supprimez simplement toutes les options liées à la réplication semi-synchrone et nous devrions être bons. Sur le premier nœud, db1 (192.168.0.61), ajoutez les lignes suivantes dans /etc/my.cnf (cela doit être sous la section [mysqld]) :

# Compatibility
default-authentication-plugin = mysql_native_password

# Replication
server_id = 61 # must be distinct on all nodes in the cluster
binlog_format = ROW
log_bin = binlog
log_slave_updates = 1
gtid_mode = ON
enforce_gtid_consistency = 1
binlog_expire_logs_seconds = 604800 # 7 days
sync_binlog = 1
report_host = 192.168.0.61 # IP address of this host
read_only = OFF # Set ON on slave
super_read_only = OFF # Set ON on slave

# Replication safety
master_info_repository = TABLE
relay_log_info_repository = TABLE
relay_log_recovery = ON

Sur le deuxième nœud, db2 (192.168.0.62), ajoutez les lignes suivantes dans /etc/my.cnf (cela doit être sous la section [mysqld]) :

# Compatibility
default-authentication-plugin = mysql_native_password

# Replication
server_id = 62 # must be distinct on all nodes in the cluster
binlog_format = ROW
log_bin = binlog
log_slave_updates = 1
gtid_mode = ON
enforce_gtid_consistency = 1
binlog_expire_logs_seconds = 604800 # 7 days
sync_binlog = 1
report_host = 192.168.0.62 # IP address of this host
read_only = ON # Set ON on slave
super_read_only = ON # Set ON on slave

# Replication safety
master_info_repository = TABLE
relay_log_info_repository = TABLE
relay_log_recovery = ON

Nous pouvons ensuite procéder à la configuration du lien de réplication comme décrit dans la section "Configuration du lien de réplication" ci-dessous.

Configuration du lien de réplication

Sur le maître (db1), créez un utilisateur esclave et autorisez l'utilisateur à se connecter à partir de tous les hôtes sous ce réseau (en utilisant % joker) :

mysql> CREATE USER 'slave'@'192.168.0.%' IDENTIFIED WITH mysql_native_password BY '[email protected]&9';
mysql> GRANT REPLICATION SLAVE ON *.* TO 'slave'@'192.168.0.%';

Sur l'esclave (db2), réinitialisez les journaux binaires, configurez les identifiants de réplication et démarrez le processus de réplication :

mysql> RESET MASTER;
mysql> CHANGE MASTER TO MASTER_HOST = '192.168.0.61', MASTER_USER = 'slave', MASTER_PASSWORD = '[email protected]&9', MASTER_AUTO_POSITION = 1;
mysql> START SLAVE;

Vérifiez l'état de la réplication :

mysql> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.0.61
                  Master_User: slave
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: binlog.000008
          Read_Master_Log_Pos: 912
               Relay_Log_File: db2-relay-bin.000007
                Relay_Log_Pos: 1081
        Relay_Master_Log_File: binlog.000008
             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: 912
              Relay_Log_Space: 1500
              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: 0
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: 66
                  Master_UUID: f60cf793-1feb-11eb-af72-5254008afee6
             Master_Info_File: mysql.slave_master_info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
           Master_Retry_Count: 86400
                  Master_Bind:
      Last_IO_Error_Timestamp:
     Last_SQL_Error_Timestamp:
               Master_SSL_Crl:
           Master_SSL_Crlpath:
           Retrieved_Gtid_Set: f60cf793-1feb-11eb-af72-5254008afee6:5-7
            Executed_Gtid_Set: f60cf793-1feb-11eb-af72-5254008afee6:1-7
                Auto_Position: 1
         Replicate_Rewrite_DB:
                 Channel_Name:
           Master_TLS_Version:
       Master_public_key_path:
        Get_master_public_key: 0
            Network_Namespace:

Faites attention au statut important suivant pour déterminer si la réplication est correctement configurée et si l'esclave a rattrapé le maître :

  • Slave_IO_Running :Oui
  • Slave_SQL_Running :Oui
  • Seconds_Behind_Master :0

Si la réplication semi-synchrone est activée, vous devriez obtenir la sortie suivante sur le maître :

mysql> SHOW STATUS LIKE '%semi%status';
+-----------------------------+-------+
| Variable_name               | Value |
+-----------------------------+-------+
| Rpl_semi_sync_master_status | ON    |
| Rpl_semi_sync_slave_status  | OFF   |
+-----------------------------+-------+

Lorsque vous êtes sur l'esclave, l'état est comme ci-dessous :

mysql> SHOW STATUS LIKE '%semi%status';
+-----------------------------+-------+
| Variable_name               | Value |
+-----------------------------+-------+
| Rpl_semi_sync_master_status | OFF   |
| Rpl_semi_sync_slave_status  | ON    |
+-----------------------------+-------+

Pour la réplication asynchrone, la requête ci-dessus ne renverra rien (ensemble vide), car les plugins de réplication semi-synchrone ne sont pas activés. Dans un ensemble de réplication, il est possible d'avoir un mélange d'hôtes esclaves répliquant avec une réplication asynchrone et semi-synchrone.

Déployer Percona Server pour MySQL à l'aide de ClusterControl

Il est pratiquement facile de déployer une réplication maître-esclave Percona Server avec ClusterControl, et par défaut, ClusterControl configurera le déploiement de la réplication avec une réplication asynchrone. Préparez simplement les nœuds que vous souhaitez déployer, et dans cet exemple, nous allons déployer un serveur Percona à trois nœuds pour MySQL 8.0 avec réplication maître-esclave. Avec l'arrivée de ClusterControl, nous devons disposer d'un nœud supplémentaire pour ClusterControl. Par conséquent, notre configuration ressemble à ceci :

  • ClusterControl – cc (192.168.0.19)
  • Maître - db1 (192.168.0.61)
  • Esclave - db2 (192.168.0.62)
  • Esclave - db3 (192.168.0.63)

Sur le serveur ClusterControl, installez ClusterControl à l'aide du script d'installation. En tant que root, exécutez ce qui suit :

$ wget http://severalnines.com/downloads/cmon/install-cc
$ chmod 755 install-cc
$ ./install-cc

Suivez les instructions d'installation jusqu'à la fin. Ensuite, ouvrez un navigateur Web et accédez à http://{ClusterControl_IP_address}/clustercontrol et créez un utilisateur et un mot de passe administrateur par défaut. Ensuite, nous devons configurer SSH sans mot de passe depuis le serveur ClusterControl vers tous les nœuds de la base de données. En tant qu'utilisateur root, nous devons d'abord générer une clé SSH :

$ whoami
root
$ ssh-keygen -t rsa # press Enter on all prompts

Ensuite, copiez la clé publique SSH créée sur tous les nœuds de la base de données :

$ ssh-copy-id -i ~/.ssh/id_rsa [email protected] # db1
$ ssh-copy-id -i ~/.ssh/id_rsa [email protected] # db2
$ ssh-copy-id -i ~/.ssh/id_rsa [email protected] # db3

Nous sommes maintenant prêts à démarrer le déploiement du cluster. Allez dans ClusterControl -> Deploy -> MySQL Replication et spécifiez les détails requis comme ci-dessous :

Ensuite, cliquez sur "Continuer" pour passer à l'étape suivante où nous configurons la spécification d'installation de MySQL :

Choisissez "Percona" pour le fournisseur et 8.0 comme version. Conservez le reste par défaut et entrez le mot de passe root MySQL. Cliquez sur "Continuer" pour procéder à la configuration de l'hôte et de la topologie :

Spécifiez l'adresse IP ou le nom d'hôte des hôtes de la base de données un par un et faites assurez-vous d'obtenir les icônes de coche verte après chaque insertion. Cela indique que ClusterControl est en mesure d'atteindre les hôtes correspondants via SSH sans mot de passe avec l'utilisateur et la clé SSH fournis, tels que définis à l'étape 1. Cliquez sur le bouton "Déployer" pour démarrer le déploiement.

ClusterControl déclenche ensuite une tâche de déploiement où vous pouvez surveiller la progression du déploiement en accédant à ClusterControl -> Activité -> Tâches -> Créer un cluster -> Détails complets de la tâche, comme illustré dans la capture d'écran suivante :

Une fois le processus terminé, vous devriez voir que le cluster est répertorié dans le tableau de bord :

C'est tout. Le déploiement est maintenant terminé.