Adding a Kunpeng Node to the Primary/Secondary Replication

Configure the Kunpeng node as the secondary MySQL database server and add it to the existing primary/secondary replication architecture.

Configure the primary database.

mysql -uroot -p -S /data/mysql/run/mysql.sock

/usr/bin/mysql -uroot -p -S /data/mysql/run/mysql.sock

Optional: If the replication user is not created, create one for the primary database and grant the user the replication slave permission. If the replication user has been set, skip this step.

         
              create user 'replicate'@'%' identified with caching_sha2_password by '123456';
grant replication slave on *.* to 'replicate'@'%';
flush privileges;

Optional: Check the created replication user.
```
select User from mysql.user;
```

Configure the synchronization mode of the primary database.
1. Log in to the primary database.
```
mysql -uroot -p -S /data/mysql/run/mysql.sock
```
1. Configure the synchronization mode.
  1. Query the GITD configuration.
```
show variables like '%gtid_mode%';
```
    If the query result contains gtid_mode=ON, skip 2.b. Otherwise, perform 2.b to configure GTID.
  2. Configure the synchronization mode to GTID.
```
set global enforce_gtid_consistency='on';
set global gtid_mode='off_permissive';
set global gtid_mode='on_permissive';
set global gtid_mode='on';
show variables like '%gtid_mode%';
```
1. Query the status of the primary database.
```
show master status;
```
  Record the status information of the primary database, especially values of File and Position, which are required for configuring the secondary database.

Optional: Configure the Kunpeng secondary database.

If MySQL primary/secondary replication has been deployed on the x86 server by referring to (Optional) Deploying MySQL Primary/Secondary Replication on x86 Servers in this document, the original replication user can be used directly. In this case, skip this step. Otherwise, create a replication user by following this step.

mysql -uroot -p123456 -S /data/mysql/run/mysql.sock

Optional: If the replication user is not created, create one (user name: replicate; password: 123456) for the secondary database and grant the user the replication slave permission. If the replication user has been set, skip this step.

         
              create user 'replicate'@'%' identified with caching_sha2_password by '123456';
grant replication slave on *.* to 'replicate'@'%';
flush privileges;

Configure the synchronization mode of the secondary database.

mysql -uroot -p123456 -S /data/mysql/run/mysql.sock

Configure the synchronization mode to GTID.

set global enforce_gtid_consistency='on';
set global gtid_mode='off_permissive';
set global gtid_mode='on_permissive';
set global gtid_mode='on';
show variables like '%gtid_mode%';

Establish the primary/secondary relationship between the Kunpeng node and the primary database.
1. Log in to the secondary database.
```
mysql -uroot -p123456 -S /data/mysql/run/mysql.sock
```
1. Establish the primary/secondary relationship.
  Use the recorded primary database information to configure the secondary database to connect to the primary database.
```
change master to master_host='192.168.0.1',master_port=3306,master_user='replicate',master_password='123456',master_auto_position=1, get_master_public_key=1;
```
  192.168.0.1 is the IP address of the primary database server. Change it based on the actual IP address.
Start the Kunpeng secondary database replication.
1. Log in to MySQL and run the following SQL statement to start the replication process of the secondary database:
```
start slave;
```
  If the following error is reported, reset the secondary database configurations and restart it. For details, see "Error 1872" Is Displayed When a Kunpeng Node Is Added to the Primary/Secondary Replication Deployment.
```
mysql> start slave;
ERROR 1872 (HY000): Replica failed to initialize applier metadata structure from the repository
```
1. Query the status of the secondary database.
  Check the status of the secondary database to ensure that the replication is running.
```
show slave status\G;
```
  In the command output, if the values of Slave_IO_Running and Slave_SQL_Running are both Yes, the secondary database is started successfully.
  - Slave_IO_Running: Yes indicates that the I/O thread between the secondary and primary databases is running and replication can be performed properly.
  - Slave_SQL_Running: Yes indicates that the SQL execution thread of the secondary database is running.
Log in to the primary database and check the status of the secondary database.
```
show slave hosts;
```
If the values of Server_id, Host, and Master_id are the same as those in Table 3, the deployment is successful.

Parent topic: Adding a Kunpeng Node to the Primary/Secondary Replication