MySQL master-slave replication and read-write separation configuration

Read-write separation and master-slave replication are important and necessary means to improve mysql performance, and must be used by large and medium-sized management systems or websites.
1. What is read-write separation and master-slave replication
Look at the picture first
As shown in the figure above, when web server 1/2/3 wants to write data, it sends a write request to the mysql db Master (master server) (that is, writes to the master). The server mysql DB Slave1 or 2 or 3 makes a read request. In this way, the workload of reading and writing on the same server is allocated to one station responsible for writing, and N stations responsible for reading (most websites have read requests far greater than write requests), thus realizing the load to a certain extent. Balance (if there are N slave servers, the master-slave proxy system will automatically assign a specific request from which slave server to read).
      Read-write separation is achieved by master-slave replication. That is, when a piece of data is written to the master server, the master server will write the write information to the binlog (binary log), and at the same time synchronize (or asynchronously or semi-synchronously) to the slave server. The slave server generates a relay-log (relay log) according to the binlog from the master server, and then the mysql server uses the relay-log information to write the data to the database.
      The advantage of doing this is not only to achieve responsible balance, but also to keep two real-time hot standby data binlog and relay-log for us. In the event of a server disaster, we can use them to restore data to any point in time.
 
2. Preparation
1. Install two mysql servers on linux (mysql at least 5.5 or above), and the two servers are preferably in the same computer room (so the master-slave replication through the intranet is much faster than the external network. If the web server is also The same computer room can also be accessed on the intranet, and there is no need to buy bandwidth from the ISP).
Assume the master's IP is 10.121.0.110 and the slave's IP is 10.121.0.220.
2. Turn off the firewalls of the two servers (configured later):
# service iptables stop (this is the method of closing centos6.5, please ask Du Niang for other systems)
3. If you have not created a database, do the following
(1) Log in to mysql on the main server
# mysql -uroot -p your password
(2) Create a database
mysql> create database test1;
mysql> create database test2;
(3) If there is already historical data, back up the historical data as a sql file and upload it to the main server, and run the following command
mysql> source /disk/test1.sql; ('/disk/test1.sql ' can be replaced with your own path)
 
3. Main server configuration
MySQL already provides perfect read-write separation and master-slave replication support, we only need to make the following settings.
1. Configure my.cnf
# vi /etc/my.cnf
(1) Remove the "#" sign before log-bin=mysql-bin. The meaning of this line is to allow mysql to use binlog, while opening the door to master-slave replication. This is the key of the key.
(2) If there are multiple databases, add the following lines:
binlog-do-db=database name 1
binlog-do-db=database name 2
binlog-do-db=database name 3
binlog-ignore-db=mysql (ignore the database used by mysql itself)
(3) Look at the number after the server-id and remember it. The server-id of the slave (slave server) cannot be the same as this value.
(4) View expire-log-day. Binlog expiration time, the default is 10 days. You can modify it according to the size of your hard disk space and the amount of data generated every day. If you have a cold backup, it is generally set to 2-3 days.
 
2. Operating the database
(1) Log in to mysql under the linux command line
# mysql -uroot -p (your root password)
(2) Create and authorize an account
mysql> GRANT REPLICATION SLAVE ON *.* TO 'slave_account'@'10.121.0.220' identified by '123456'
This sentence means that the slave server '10.121.0.220' is allowed to use the account and password 'slave-account' and '123456' to perform master-slave replication ('REPLICATION SLAVE') on all databases (*.*) of the master server.
(3) Restart mysql to make the above configuration take effect 
# etc/init.d/mysql restart or
# service mysql restart
(4) Check the binlog status of the main server
mysql> show master stauts;
Make a note of the values ​​under File and Position. For use when configuring the slave server.
Note: File: the file name of the current binlog, every time mysql is restarted, a new binlog file will be generated
      Position: the pointer position of the current binlog
 
3. Slave server configuration
1. Configure mysql.cnf
# vi /etc/my.cnf
(1) Modify server-id=2 (this value cannot be the same as the server-id of the master server. If there are multiple slave servers, the value will be extended)
(2) Add the following two lines:
relay-log-index=slave-relay-bin.index (index file of relay log)
relay-log=slave-relay-bin (file prefix for relay logs)
(3) Restart mysql to make the above configuration take effect
# /etc/init.d/mysql restart
(4) Login to mysql
# mysql -uroot -p your password
(5) Stop the master-slave replication service
mysql> stop slave
(6) Master-slave association configuration
mysql> change master to
master_host='10.121.0.110', #Master server IP
master_user=' slave_account  ', #The user of the master server accessing the slave server, that is, the account mentioned in the third sub-article 2 sub-article 2 above
master_password='123456', #The password for the master server to access the slave, that is, the password described in the third subsection 2 subsection 2 above
master_log_file='mysql-bin.000008', #The name of the binlog file starting from the master server, that is, the file in Figure 2
master_log_pos=107; #The starting position of the master server binlog, that is, the post in Figure 2
Each of the above lines is particularly important, and no single character is wrong.
(7) Start the slave service
mysql> start slave
(8) Check the status of the slave service to determine whether the slave service takes effect
mysql> show slave status\G; (G parameter is the vertical display result)
The following results will be displayed
                Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.0.110
                  Master_User: slave_account
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.00008
          Read_Master_Log_Pos: 107
               Relay_Log_File: slave-relay-bin.000002
                Relay_Log_Pos: 253
        Relay_Master_Log_File: mysql-bin.00008
             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: 264
              Relay_Log_Space: 409
              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: 1
 
If both Slave_IO_Running and Slave_SQL_Running show YES, it means that the read-write communication between the slave and the master is normal, and the active replication has been running, which means that our master-slave replication has been successfully set up. If a failure occurs, see the next section "Troubleshooting".
Then, you insert a piece of data on the master server to see if the corresponding database of the slave server has been updated accordingly. If so, you're done.
 
4. Permission configuration 
Although some mysql versions do not perform the following operations and may run normally, I still strongly recommend that you set them up. Otherwise, there must be security concerns.
1. Assign select, insert, update, delete permissions to the master
mysql>GRANT SELECT,INSERT,UPDATE,DELETE ON *.* TO 'Database account'@'WEB server IP' identified by 'password'.
Note that although the master is only responsible for writing, it must also have select permissions. The reason is that when using transactions, you need to query from the master, and the second is that commands such as update/delete need to use select permissions.
2. Assign select permission to the slave 
mysql> GRANT SELECT ON *.* TO 'database account'@'WEB server IP' identified by 'password';
This setting also has a disadvantage, that is, when the master is down, the read-write separation mechanism will actively transfer the write operation to the slave, and at this time, abnormal writing will occur. Therefore, it is up to you to choose which permissions to assign to the slave.
 
Five, firewall configuration
Just now we turned off the firewall for the convenience of debugging, but doing so is very insecure. In particular, the database server, the life of the relationship company, should not be underestimated.
The firewall of master-slave replication is better to set up. If you only have one web server, you only need to open two authorizations in the iptables of the master and slave servers. First execute the following command on the master server:
# iptables INPUT -s 10.121.0.220 -j ACCEPT (allow access from server)
# iptables INPUT -s 10.121.2.142 -j ACCEPT (allow web server access)
# service iptables save (save the above rules)
# service iptables restart (restart iptables)
In it, replace the first one with the main IP.
After setting, use show slave status on the slave to see if the master-slave replication is normal.
 
6. Some troubleshooting
During the setup process, the following faults may occur
(1) Slave_IO_Running: No
(2) Slave_IO_Running: Connect
(3)Last_IO_Error: error connecting to master '[email protected]:3306' - retry-time: 60  retries: 8640
In fact, the above faults are all caused by abnormal IO. Please check the following steps.
a. After configuring the master or slave my.cnf, whether to restart the mysql service. If the restart is not successful, you can use the reboot command to restart the server and try again
b. Whether the information filled in the step of change master is correct.
(4)Last_IO_Error: Fatal error: The slave I/O thread stops because master and slave have equal MySQL server ids; these ids must be different for replication to work (or the --replicate-same-server-id option must be used on slave but this does not always make sense; please check the manual before using it).
The above means that the master and the slave use the same server-id, enter my.cnf to check, correct it, and then restart the mysql service.
 
 

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=326315871&siteId=291194637