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

Sådan implementeres Percona Server til MySQL for høj tilgængelighed

Percona Server til MySQL 8.0 tilbyder en række klyngeløsninger til høj tilgængelighed direkte fra kassen:

  • Single-master:
    • Asynkron replikering
    • Semisynkron replikering
  • Multi-master:
    • Gruppereplikering
    • InnoDB Cluster (en kombination af MySQL Router, MySQL Shell og Percona Server med Group Replication)

Den mest populære, kamptestede og meget skalerbare løsning er naturligvis asynkron replikering. I dette blogindlæg vil vi implementere en Percona Server-replikeringsopsætning specifikt til høj tilgængelighed. Instruktionerne beskrevet her er baseret på CentOS 7.

Installation af Percona Server

For høj tilgængelighed har vi brug for mindst to noder i en simpel master-slave-replikeringsopsætning:

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

De trin, der er beskrevet i dette afsnit, skal udføres på alle databasenoder (db1 og db2). Vi starter med at installere Percona repository-pakken:

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

Den seneste stabile version på dette tidspunkt er Percona Server til MySQL 8.0, men som standard er repository-pakken kun konfigureret frem til version 5.7. Percona-release-pakken indeholder et script, der kan aktivere yderligere repositories til de nyere produkter. Lad os køre det script og aktiverede 8.0-lagre:

$ percona-release setup ps80

Installer derefter den seneste Percona Server og Percona Xtrabackup:

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

På dette tidspunkt bør du få installeret en Percona Server til MySQL 8.0.21. Alle afhængighedspakker vil blive installeret som shared-compat, shared og client-pakker. Vi kan derefter aktivere MySQL-tjenesten ved opstart og starte tjenesten:

$ systemctl enable mysql
$ systemctl start mysql

En ny root-adgangskode vil blive genereret under den første opstart. Vi skal først hente oplysninger om root-adgangskoden fra MySQL-fejlloggen (standard er /var/log/mysqld.log i RHEL-baserede systemer):

$ 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

Som du kan se er den genererede adgangskode "o%(_M>t1)R-P". Dernæst skal vi udføre en post-installationsopgave for at sikre MySQL-serverinstallationen. Kør følgende kommando:

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

Den genererede root-adgangskode vil blive udløbet umiddelbart efter det første root-login. Ovenstående hjælpescript hjælper os med at konfigurere en ny MySQL root-adgangskode, deaktivere fjernlogin for root, fjerne testdatabase og anonyme brugere og også genindlæse privilegietabellerne.

Vi er nu klar til at konfigurere høj tilgængelighedsfunktionen til Percona Server 8.0.

Semisynkron replikering

Semisynkron replikering falder mellem asynkron og fuldt synkron replikering. Kilden venter, indtil mindst én replika har modtaget og logget hændelserne, og begår derefter transaktionen. Kilden venter ikke på, at alle replikaer bekræfter modtagelsen, og det kræver kun en bekræftelse fra replikaerne, ikke at begivenhederne er blevet fuldt udført og begået på replikasiden. Semisynkron replikering garanterer derfor, at hvis kilden går ned, er alle de transaktioner, den har begået, blevet overført til mindst én replika.

For den bedste replikeringsintegritet skal du vælge semi-synkron replikering. For at konfigurere det, på den første node, db1 (192.168.0.61), tilføj følgende linjer inde i /etc/my.cnf (det skal være under [mysqld]-sektionen):

# 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

På den anden node, db2 (192.168.0.62), tilføj følgende linjer inde i /etc/my.cnf (det skal være under [mysqld]-sektionen):

# 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

Vi kan derefter fortsætte med at opsætte replikeringslinket som beskrevet i "Opsætning af replikeringslink" længere nede.

Asynkron replikering

For asynkron replikering skal du blot fjerne alle semi-synkron replikeringsrelaterede muligheder, og vi burde være gode. På den første node, db1 (192.168.0.61), tilføj følgende linjer inde i /etc/my.cnf (det skal være under [mysqld]-sektionen):

# 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

På den anden node, db2 (192.168.0.62), tilføj følgende linjer inde i /etc/my.cnf (det skal være under [mysqld]-sektionen):

# 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

Vi kan derefter fortsætte med at opsætte replikeringslinket som beskrevet i "Opsætning af replikeringslink" nedenfor.

Opsætning af replikeringslinket

På masteren (db1) skal du oprette en slavebruger og tillade brugeren at oprette forbindelse fra alle værter under dette netværk (ved hjælp af % 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.%';

På slaven (db2), nulstil de binære logfiler, konfigurer replikeringsoplysningerne og start replikeringsprocessen:

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;

Tjek replikeringsstatussen:

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:

Vær opmærksom på følgende vigtige status for at afgøre, om replikeringen er konfigureret korrekt, og slaven har indhentet masteren:

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

Hvis semi-synkron replikering er aktiveret, bør du få følgende output på masteren:

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

Mens du er på slaven, er status som nedenfor:

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

For asynkron replikering skal ovenstående forespørgsel ikke returnere noget (tomt sæt), fordi de semi-synkrone replikeringsplugins ikke er aktiveret. I ét replikeringssæt er det muligt at have en blanding af slaveværter, der replikerer med asynkron og semi-synkron replikering.

Deployering af Percona Server til MySQL ved hjælp af ClusterControl

Det er praktisk talt nemt at implementere en master-slave Percona Server-replikering med ClusterControl, og som standard vil ClusterControl konfigurere replikeringsimplementeringen med en asynkron replikering. Du skal blot forberede de noder, du vil implementere, og i dette eksempel skal vi installere en Percona-server med tre noder til MySQL 8.0 med master-slave-replikering. Når ClusterControl kommer ind i billedet, er vi forpligtet til at have en ekstra node til ClusterControl. Derfor ser vores opsætning sådan ud:

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

På ClusterControl-serveren skal du installere ClusterControl ved hjælp af installationsscriptet. Kør følgende som root:

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

Følg installationsinstruktionerne, indtil den er færdig. Åbn derefter en webbrowser og gå til http://{ClusterControl_IP_address}/clustercontrol og opret en standardadministratorbruger og -adgangskode. Dernæst skal vi konfigurere adgangskodefri SSH fra ClusterControl-serveren til alle databasenoder. Som root-bruger skal vi først generere en SSH-nøgle:

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

Kopier derefter den oprettede offentlige SSH-nøgle til alle databasenoder:

$ 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

Vi er nu klar til at starte klyngeimplementeringen. Gå til ClusterControl -> Implementer -> MySQL-replikering, og angiv de nødvendige detaljer som nedenfor:

Klik derefter på "Fortsæt" for at fortsætte til næste trin, hvor vi konfigurerer MySQL installationsspecifikationen:

Vælg "Percona" for leverandøren og 8.0 som version. Behold resten som standard, og indtast MySQL root-adgangskoden. Klik på "Fortsæt" for at fortsætte til værts- og topologikonfigurationen:

Angiv IP-adressen eller værtsnavnet på databaseværterne én efter én, og lav sikker på at du får det grønne flueben efter hver indsættelse. Dette indikerer, at ClusterControl er i stand til at nå de tilsvarende værter via adgangskodefri SSH med den angivne SSH-bruger og nøgle som defineret i trin 1. Klik på knappen "Deploy" for at starte implementeringen.

ClusterControl udløser derefter et implementeringsjob, hvor du kan overvåge implementeringsprocessen ved at gå til ClusterControl -> Aktivitet -> Jobs -> Opret klynge -> Fuld jobdetaljer, som vist på følgende skærmbillede:

Når processen er fuldført, bør du se, at klyngen er opført i Dashboardet :

Det var det. Udrulningen er nu afsluttet.


  1. Oracle ORA-12154 fejl på lokal IIS, men ikke med Visual Studio Development Server

  2. Sådan gemmer du IPv6-kompatibel adresse i en relationsdatabase

  3. Indsættelse af SQL Server-data i Salesforce.com

  4. Sådan kontrolleres brugerrettigheder i MySQL Workbench ved hjælp af GUI