Mysql
 sql >> Datenbank >  >> RDS >> Mysql

So stellen Sie Percona Server für MySQL für Hochverfügbarkeit bereit

Percona Server für MySQL 8.0 bietet eine Reihe von Clustering-Lösungen für hohe Verfügbarkeit, die sofort einsatzbereit sind:

  • Einzelmaster:
    • Asynchrone Replikation
    • Semisynchrone Replikation
  • Multimaster:
    • Gruppenreplikation
    • InnoDB Cluster (eine Kombination aus MySQL Router, MySQL Shell und Percona Server mit Gruppenreplikation)

Die beliebteste, kampferprobte und hochgradig skalierbare Lösung ist natürlich die asynchrone Replikation. In diesem Blog-Beitrag werden wir ein Percona Server-Replikations-Setup speziell für Hochverfügbarkeit bereitstellen. Die hier beschriebene Anleitung basiert auf CentOS 7.

Percona-Server installieren

Für hohe Verfügbarkeit benötigen wir mindestens zwei Knoten in einer einfachen Master-Slave-Replikationseinrichtung:

  • db1 - master (192.168.0.61)
  • db2 - Slave (192.168.0.62)

Die in diesem Abschnitt beschriebenen Schritte sollten auf allen Datenbankknoten (db1 und db2) durchgeführt werden. Wir beginnen mit der Installation des Percona-Repository-Pakets:

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

Zu diesem Zeitpunkt ist die neueste stabile Version Percona Server für MySQL 8.0, aber standardmäßig ist das Repository-Paket nur bis Version 5.7 konfiguriert. Das Paket percona-release enthält ein Skript, das zusätzliche Repositories für die neueren Produkte aktivieren kann. Lassen Sie uns dieses Skript ausführen und 8.0-Repositories aktivieren:

$ percona-release setup ps80

Installieren Sie dann den neusten Percona Server und Percona Xtrabackup:

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

Zum jetzigen Zeitpunkt sollten Sie einen Percona-Server für MySQL 8.0.21 installiert bekommen. Alle Abhängigkeitspakete werden wie Shared-Compat-, Shared- und Client-Pakete installiert. Wir können dann den MySQL-Dienst beim Start aktivieren und den Dienst starten:

$ systemctl enable mysql
$ systemctl start mysql

Beim ersten Start wird ein neues Root-Passwort generiert. Wir müssen zuerst die Root-Passwort-Informationen aus dem MySQL-Fehlerprotokoll abrufen (Standard ist /var/log/mysqld.log in RHEL-basierten Systemen):

$ 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

Wie Sie sehen können, lautet das generierte Passwort "o%(_M>t1)R-P". Als nächstes müssen wir eine Aufgabe nach der Installation durchführen, um die Installation des MySQL-Servers zu sichern. Führen Sie den folgenden Befehl aus:

$ 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!

Das generierte Root-Passwort läuft sofort nach der ersten Root-Anmeldung ab. Das obige Hilfsskript hilft uns, ein neues MySQL-Root-Passwort zu konfigurieren, die Remote-Anmeldung für Root zu deaktivieren, die Testdatenbank und anonyme Benutzer zu entfernen und auch die Berechtigungstabellen neu zu laden.

Wir sind jetzt bereit, die Hochverfügbarkeitsfunktion für Percona Server 8.0 zu konfigurieren.

Semisynchrone Replikation

Die halbsynchrone Replikation liegt zwischen der asynchronen und der vollständig synchronen Replikation. Die Quelle wartet, bis mindestens ein Replikat die Ereignisse empfangen und protokolliert hat, und schreibt dann die Transaktion fest. Die Quelle wartet nicht darauf, dass alle Replikate den Empfang bestätigen, und sie benötigt nur eine Bestätigung von den Replikaten, nicht dass die Ereignisse vollständig ausgeführt und auf der Replikatseite festgeschrieben wurden. Die halbsynchrone Replikation garantiert daher, dass bei einem Absturz der Quelle alle von ihr festgeschriebenen Transaktionen an mindestens eine Replik übertragen wurden.

Wählen Sie für die beste Replikationsintegrität die halbsynchrone Replikation. Um es zu konfigurieren, fügen Sie auf dem ersten Knoten, db1 (192.168.0.61), die folgenden Zeilen in /etc/my.cnf ein (muss sich im Abschnitt [mysqld] befinden):

# 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

Fügen Sie auf dem zweiten Knoten, db2 (192.168.0.62), die folgenden Zeilen in /etc/my.cnf ein (muss sich im Abschnitt [mysqld] befinden):

# 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

Wir können dann mit der Einrichtung des Replikationslinks fortfahren, wie weiter unten im Abschnitt "Replikationslink einrichten" beschrieben.

Asynchrone Replikation

Entfernen Sie für die asynchrone Replikation einfach alle Optionen im Zusammenhang mit der halbsynchronen Replikation, und wir sollten gut sein. Fügen Sie auf dem ersten Knoten, db1 (192.168.0.61), die folgenden Zeilen in /etc/my.cnf hinzu (muss sich im Abschnitt [mysqld] befinden):

# 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

Fügen Sie auf dem zweiten Knoten, db2 (192.168.0.62), die folgenden Zeilen in /etc/my.cnf ein (muss sich im Abschnitt [mysqld] befinden):

# 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

Wir können dann mit der Einrichtung des Replikationslinks fortfahren, wie unten im Abschnitt "Replikationslink einrichten" beschrieben.

Einrichten des Replikationslinks

Erstellen Sie auf dem Master (db1) einen Slave-Benutzer und erlauben Sie dem Benutzer, sich von allen Hosts in diesem Netzwerk zu verbinden (mit %-Wildcard):

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.%';

Setzen Sie auf dem Slave (db2) die Binärprotokolle zurück, konfigurieren Sie die Anmeldedaten für die Replikation und starten Sie den Replikationsprozess:

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;

Überprüfen Sie den Replikationsstatus:

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:

Achten Sie auf den folgenden wichtigen Status, um festzustellen, ob die Replikation korrekt konfiguriert ist und der Slave den Master eingeholt hat:

  • Slave_IO_Running:Ja
  • Slave_SQL_Running:Ja
  • Seconds_Behind_Master:0

Wenn die halbsynchrone Replikation aktiviert ist, sollten Sie die folgende Ausgabe auf dem Master erhalten:

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

Auf dem Slave ist der Status wie folgt:

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

Für die asynchrone Replikation soll die obige Abfrage nichts zurückgeben (leere Menge), da die Plugins für die halbsynchrone Replikation nicht aktiviert sind. In einem Replikationssatz ist es möglich, eine Mischung aus Slave-Hosts zu haben, die mit asynchroner und halbsynchroner Replikation replizieren.

Bereitstellen von Percona Server für MySQL mit ClusterControl

Es ist praktisch einfach, eine Master-Slave-Percona-Server-Replikation mit ClusterControl bereitzustellen, und standardmäßig konfiguriert ClusterControl die Replikationsbereitstellung mit einer asynchronen Replikation. Bereiten Sie einfach die Knoten vor, die Sie bereitstellen möchten, und in diesem Beispiel werden wir einen Percona-Server mit drei Knoten für MySQL 8.0 mit Master-Slave-Replikation bereitstellen. Da ClusterControl ins Spiel kommt, benötigen wir einen zusätzlichen Knoten für ClusterControl. Daher sieht unser Setup so aus:

  • ClusterControl - cc (192.168.0.19)
  • Master - db1 (192.168.0.61)
  • Slave - db2 (192.168.0.62)
  • Slave - db3 (192.168.0.63)

Installieren Sie ClusterControl auf dem ClusterControl-Server mithilfe des Installationsskripts. Führen Sie als root Folgendes aus:

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

Folgen Sie den Installationsanweisungen bis zum Abschluss. Öffnen Sie dann einen Webbrowser und gehen Sie zu http://{ClusterControl_IP_address}/clustercontrol  und erstellen Sie einen Standard-Admin-Benutzer und ein Passwort. Als nächstes müssen wir passwortloses SSH vom ClusterControl-Server zu allen Datenbankknoten einrichten. Als Root-Benutzer müssen wir zuerst einen SSH-Schlüssel generieren:

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

Kopieren Sie dann den erstellten öffentlichen SSH-Schlüssel auf alle Datenbankknoten:

$ 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

Wir können jetzt mit der Clusterbereitstellung beginnen. Gehen Sie zu ClusterControl -> Deploy -> MySQL Replication und geben Sie die erforderlichen Details wie folgt an:

Klicken Sie dann auf „Weiter“, um mit dem nächsten Schritt fortzufahren, in dem wir konfigurieren die MySQL-Installationsspezifikation:

Wählen Sie "Percona" als Anbieter und 8.0 als Version. Behalten Sie den Rest als Standard bei und geben Sie das MySQL-Root-Passwort ein. Klicken Sie auf „Weiter“, um mit der Host- und Topologiekonfiguration fortzufahren:

Geben Sie nacheinander die IP-Adresse oder den Hostnamen der Datenbankhosts an und erstellen Sie Stellen Sie sicher, dass Sie nach jedem Einfügen die grünen Häkchen-Symbole erhalten. Dies zeigt an, dass ClusterControl die entsprechenden Hosts über passwortloses SSH mit dem bereitgestellten SSH-Benutzer und -Schlüssel erreichen kann, wie in Schritt 1 definiert. Klicken Sie auf die Schaltfläche „Bereitstellen“, um die Bereitstellung zu starten.

ClusterControl löst dann einen Bereitstellungsjob aus, bei dem Sie den Bereitstellungsfortschritt überwachen können, indem Sie zu ClusterControl -> Aktivität -> Jobs -> Cluster erstellen -> Vollständige Jobdetails gehen, wie im folgenden Screenshot gezeigt:

Sobald der Vorgang abgeschlossen ist, sollte der Cluster im Dashboard aufgeführt sein :

Das war's. Die Bereitstellung ist nun abgeschlossen.