Master-slave replication cluster application of mysql database (4)

One: mysql master-slave replication

1.1: Overview of mysql master-slave replication

Master-slave replication (also known as AB replication) allows data from one MySQL database server (master server) to be replicated to one or more MySQL database servers (slave servers).

1.1.1: Advantages of master-slave replication:

1. Do hot backup of data.
   As a backup database, after the primary database server fails, you can switch to the secondary database to continue working to avoid data loss.
2. Read and write separation, so that the database can support greater concurrency (the main library is responsible for writing, and the slave library is responsible for reading)

1.2: The working principle of mysql master-slave replication

The database has a bin-log binary file that records all sql statements.

Two files + 3 threads:

1. The main library will generate a log dump thread to pass binlog to the slave library i/o thread;

2. Generate two threads from the library, one I/O thread and one SQL thread;

3. The i/o thread connects to the main library and requests the main library to send the update records in the binlog to the slave library.

   The I/O thread reads the updates sent by the binlog output thread (log dump thread) of the main library and copies these updates to the local file relay log (relay log) file;

4. The SQL thread will read the log in the relay log file and parse it into specific operations to achieve consistent master-slave operations and consistent final data;

1.3: Three types of mysql master-slave replication

There are three formats of binlog: Statement, Row, and Mixed.

• SQL statement-based replication (statement-based replication, SBR)

• Row-based replication (RBR)

• Mixed-based replication (MBR)

View the current log format:

MariaDB [(none)]> show variables like 'binlog_format';
+---------------+-----------+
| Variable_name | Value     |
+---------------+-----------+
| binlog_format | STATEMENT |
+---------------+-----------+
1 row in set (0.00 sec)

Online modification log format: (no demonstration)

mysql> set global binlog_format=mixed;
Query OK, 0 rows affected (0.00 sec)

mysql> show global variables like "binlog_format";
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| binlog_format | MIXED  |
+---------------+-------+
1 row in set (0.00 sec)

The advantages and disadvantages of the three replication modes:

1. STATMENT mode:
   every sql statement that will modify data will be recorded in binlog.

   Advantages: There is no need to record every SQL statement and every row of data changes, so the binlog log will be less, reducing disk IO and improving performance.

   Disadvantages: In some cases, the data in the master-slave will be inconsistent (such as sleep() function, last_insert_id(), and user-defined functions(udf), etc.)

2. Row-based replication:

   Instead of recording the context information of each SQL statement, it only needs to record which data has been modified and what the modification has become. (Do not record the sql execution process, only the results!)

   Advantages: There will be no problem that the invocation and triggering of stored procedures, functions, or triggers cannot be copied correctly under certain specific circumstances.

   Disadvantages: A large number of logs will be generated, especially when altering the table, the logs will skyrocket.

3. Mixed mode replication: the mixed use of the above two modes,

   General replication uses the STATEMENT mode to save the binlog. For operations that cannot be replicated in the STATEMENT mode, the ROW mode is used to save the binlog. MySQL will select the log saving method according to the executed SQL statement.

Two: mysql master-slave replication configuration

2.1: master configuration

Edit /etc/my.cnf

server-id=1
#开启binlog文件
log-bin=mysql-bin

Restart the service to take effect!

Create an account and authorize:

MariaDB [(none)]> GRANT all ON *.* TO 'slave'@'192.168.1.9' IDENTIFIED BY '123456';
Query OK, 0 rows affected (0.00 sec)
 
MariaDB [(none)]> flush privileges;
Query OK, 0 rows affected (0.00 sec)

View the status of the master node:
#Record the log file name and location, standby

MariaDB [(none)]> show master status;
+------------------+----------+--------------+---------------------------------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB                            |
+------------------+----------+--------------+---------------------------------------------+
| mysql-bin.000003 |      459 |              | information_schema,performance_schema,mysql |
+------------------+----------+--------------+---------------------------------------------+

2.2: Slave configuration

Edit /etc/my.cnf

server-id=2

Restart the service to take effect!

Close the copy function from the server

stop slave;

Configure the slave server and establish a connection with the master library.

MariaDB [(none)]> change master to master_host='192.168.1.8',master_user='slave',master_password='123456',master_log_file='mysql-bin.000003', master_log_pos=459;
Query OK, 0 rows affected (0.05 sec)

#开启复制功能！
MariaDB [(none)]> slave start;

Check the status of the copy function from the service

Slave_IO_Running: Yes
Slave_SQL_Running: Yes

ariaDB [(none)]> show slave status\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.1.8
                  Master_User: slave
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000003
          Read_Master_Log_Pos: 459
               Relay_Log_File: mariadb-relay-bin.000002
                Relay_Log_Pos: 529
        Relay_Master_Log_File: mysql-bin.000003
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes

2.3: Master-slave replication test

Experimental steps:
1: Create a database db1 on the master database
2: Log in to the slave database and use the command show databases; to check whether db1 exists
3: If it exists, the master-slave replication is ok!

Three: mysql mutual master-slave architecture

In fact, it is very simple to use the original slave library as the main library and the original master library as the slave library. According to the method of master-slave configuration, the master library was used as the slave library, and the slave library was configured as the master library.

Note: be sure to open the binlog file

log-bin=mysql-bin

Mutual master-slave verification:
1: Create a database db (130db, 131db) on each of the two nodes
2: show databases; check whether the db has been synchronized.