Mysql
 sql >> Database >  >> RDS >> Mysql

Come distribuire Percona Server per MySQL per un'elevata disponibilità

Percona Server per MySQL 8.0 offre una serie di soluzioni di clustering per un'elevata disponibilità pronte all'uso:

  • Master unico:
    • Replica asincrona
    • Replica semi sincrona
  • Multi-master:
    • Replica di gruppo
    • InnoDB Cluster (una combinazione di MySQL Router, MySQL Shell e Percona Server con Group Replication)

La soluzione più popolare, testata in battaglia e altamente scalabile è, ovviamente, la replica asincrona. In questo post del blog, implementeremo una configurazione di replica di Percona Server specifica per l'elevata disponibilità. Le istruzioni qui descritte si basano su CentOS 7.

Installazione del server Percona

Per un'elevata disponibilità, abbiamo bisogno di almeno due nodi in una semplice configurazione di replica master-slave:

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

I passaggi descritti in questa sezione devono essere eseguiti su tutti i nodi del database (db1 e db2). Inizieremo installando il pacchetto repository Percona:

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

L'ultima versione stabile a questo punto è Percona Server per MySQL 8.0, ma per impostazione predefinita, il pacchetto del repository è configurato solo fino alla versione 5.7. Il pacchetto percona-release contiene uno script che può abilitare repository aggiuntivi per i prodotti più recenti. Eseguiamo lo script e abilitiamo i repository 8.0:

$ percona-release setup ps80

Quindi installa l'ultimo Percona Server e Percona Xtrabackup:

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

In questo momento, dovresti avere installato un Percona Server per MySQL 8.0.21. Tutti i pacchetti di dipendenze verranno installati come pacchetti condivisi, condivisi e client. Possiamo quindi abilitare il servizio MySQL all'avvio e avviare il servizio:

$ systemctl enable mysql
$ systemctl start mysql

Una nuova password di root verrà generata durante il primo avvio. Dobbiamo recuperare prima le informazioni sulla password di root dal log degli errori MySQL (l'impostazione predefinita è /var/log/mysqld.log nei sistemi basati su 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

Come puoi vedere la password generata è "o%(_M>t1)R-P". Successivamente, è necessario eseguire un'attività post-installazione per proteggere l'installazione del server MySQL. Esegui il seguente comando:

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

La password di root generata scadrà immediatamente al primo accesso di root. Lo script di supporto sopra ci aiuta a configurare una nuova password di root MySQL, disabilitando l'accesso remoto per root, rimuovendo il database di test e gli utenti anonimi e anche ricaricando le tabelle dei privilegi.

Ora siamo pronti per configurare la funzionalità di alta disponibilità per Percona Server 8.0.

Replica semi sincrona

La replica semi sincrona rientra tra la replica asincrona e completamente sincrona. L'origine attende finché almeno una replica non ha ricevuto e registrato gli eventi, quindi esegue il commit della transazione. L'origine non attende che tutte le repliche confermino la ricezione e richiede solo un riconoscimento da parte delle repliche, non che gli eventi siano stati completamente eseguiti e sottoposti a commit sul lato della replica. La replica semi sincrona, quindi, garantisce che in caso di crash della sorgente, tutte le transazioni che ha commesso siano state trasmesse ad almeno una replica.

Per la migliore integrità della replica, scegli la replica semisincrona. Per configurarlo, sul primo nodo, db1 (192.168.0.61), aggiungere le seguenti righe all'interno di /etc/my.cnf (deve essere nella sezione [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

Sul secondo nodo, db2 (192.168.0.62), aggiungi le seguenti righe all'interno di /etc/my.cnf (deve essere nella sezione [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

Possiamo quindi procedere alla configurazione del collegamento di replica come descritto in "Impostazione del collegamento di replica" più in basso.

Replica asincrona

Per la replica asincrona, rimuovi semplicemente tutte le opzioni relative alla replica semisincrona e dovremmo essere a posto. Sul primo nodo, db1 (192.168.0.61), aggiungi le seguenti righe all'interno di /etc/my.cnf (deve essere nella sezione [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

Sul secondo nodo, db2 (192.168.0.62), aggiungi le seguenti righe all'interno di /etc/my.cnf (deve essere nella sezione [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

Possiamo quindi procedere alla configurazione del collegamento di replica come descritto in "Impostazione del collegamento di replica" in basso.

Impostazione del collegamento di replica

Sul master (db1), crea un utente slave e consenti all'utente di connettersi da tutti gli host in questa rete (usando % jolly):

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

Sullo slave (db2), reimpostare i log binari, configurare le credenziali di replica e avviare il processo di replica:

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;

Controlla lo stato della replica:

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:

Prestare attenzione al seguente stato importante per determinare se la replica è configurata correttamente e lo slave ha raggiunto il master:

  • Slave_IO_Running:Sì
  • Slave_SQL_Running:Sì
  • Seconds_Behind_Master:0

Se la replica semisincrona è abilitata, dovresti ottenere il seguente output sul master:

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

Durante lo slave, lo stato è il seguente:

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

Per la replica asincrona, la query precedente non restituirà nulla (set vuoto), perché i plug-in di replica semi-sincrona non sono abilitati. In un set di replica, è possibile avere un mix di replica host slave con replica asincrona e semisincrona.

Distribuzione di Percona Server per MySQL utilizzando ClusterControl

È praticamente facile distribuire una replica del server Percona master-slave con ClusterControl e, per impostazione predefinita, ClusterControl configurerà la distribuzione della replica con una replica asincrona. Prepara semplicemente i nodi che desideri distribuire e, in questo esempio, implementeremo un server Percona a tre nodi per MySQL 8.0 con replica master-slave. Con ClusterControl entra in scena, è necessario disporre di un nodo aggiuntivo per ClusterControl. Pertanto, la nostra configurazione si presenta così:

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

Sul server ClusterControl, installare ClusterControl utilizzando lo script del programma di installazione. Come root, esegui quanto segue:

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

Segui le istruzioni di installazione fino al termine. Quindi, apri un browser web e vai a http://{ClusterControl_IP_address}/clustercontrol  e crea un utente e una password amministratore predefiniti. Successivamente, è necessario configurare SSH senza password dal server ClusterControl a tutti i nodi del database. Come utente root, dobbiamo prima generare una chiave SSH:

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

Quindi, copia la chiave pubblica SSH creata su tutti i nodi del database:

$ 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

Ora siamo pronti per iniziare la distribuzione del cluster. Vai a ClusterControl -> Deploy -> MySQL Replication e specifica i dettagli richiesti come di seguito:

Quindi, fai clic su "Continua" per procedere al passaggio successivo in cui configuriamo la specifica di installazione di MySQL:

Scegli "Percona" per il fornitore e 8.0 come versione. Mantieni il resto come predefinito e inserisci la password di root di MySQL. Fare clic su "Continua" per procedere alla configurazione dell'host e della topologia:

Specificare l'indirizzo IP o il nome host degli host del database uno per uno e fare assicurati di ottenere le icone di spunta verdi dopo ogni inserimento. Ciò indica che ClusterControl è in grado di raggiungere gli host corrispondenti tramite SSH senza password con l'utente e la chiave SSH forniti come definito nel passaggio 1. Fare clic sul pulsante "Distribuisci" per avviare la distribuzione.

ClusterControl avvia quindi un processo di distribuzione in cui è possibile monitorare lo stato di avanzamento della distribuzione andando su ClusterControl -> Attività -> Lavori -> Crea cluster -> Dettagli processo completo, come mostrato nella schermata seguente:

Una volta completato il processo, dovresti vedere che il cluster è elencato nella Dashboard :

Ecco fatto. La distribuzione è ora completa.