mysql database synchronization

1. Main library:
a) Modify the configuration file my.cnf, and add the following configuration under mysqld
i.log-bin=mysql-bin //Use mysql-bin to record logs
ii.server_id=1
iii.binlog_do_db=repl //Required Backup database
iv.binlog_ignore_db=mysql //Exclude the backup database to avoid errors
v.log-slave-updates #This parameter must be added, otherwise the updated records will not be recorded in the binary file
vi.slave-skip -errors # is to skip the error and continue to perform the replication operation
b) Create an account for backup (in the main library)
i.grant replication slave on *.* to 'gl'@'192.168.80.112' identified by 'gl';
c) Restart the mysqld service (service mysqld restart), enter mysql to check the status of the master database
i. Enter the command show master status
ii. If the following appears, it means normal
iii.+------------ ------+------------+--------------+----------------- -+
iv.| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
v.+----------------------+----------+--------------+-- ----------------+
vi.| mysql-bin.000002 | 106 | repl | mysql |
vii.+--------------- ---+------------+--------------+-----------------+
2 .From the library:
a) Modify the configuration file my.cnf, and add the following configuration under mysqld
i.Server_id=2
b) Enter the mysql input command,
i.mysql> change master to
ii. -> master_host='192.168.80.113',
iii. -> master_user='gl',
iv. -> master_password='gl',
v. -> master_log_file='mysql-bin.000002',
vi. -> master_log_pos=106;
c) Start the backup process, enter start slave under mysql
Note: The master_log_file is the file for show master status of the main library, and the master_log_pos field is position
. When the above method is to create a new database, if the database runs for a period of time, it needs to be manually synchronized first. The specific steps are as follows :
1. Set the synchronization master #Same as above 
2. Create a mysql account as a synchronization account 
3. Lock all tables on the master server and prohibit continued data writing 
mysql>FLUSH TABLES WITH READ LOCK; 
         mysql> show master status; ???? ? ??????? //Record replication start breakpoint, you can also use show master status\G 
        mysql> show master status; 
        +-----------------+- ---------+--------------+------------------+ 
        | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | 
        +------------------+----------+--------------+- -----------------+ 
        | mysql-bin.000003 | 106 | backup | | 
        +-----------------+ ----------+--------------+------------------+ 
        //Record File: mysql-bin.000003 offset Position 106 
4. Pack and backup the main server data file 
  cd /var/lib/mysql 
  tat –cvf repl.tar repl //Package the database to be backed up 
  scp repl.tar 192.168.10.204:/var/lib/mysql? //Transfer the packaged database to the backup server 
5. Main Unlock the server table 
Execute the following command to unlock the read lock of the master server, and the master server can continue to update the data: 
mysql> UNLOCK TABLES; 
6. Set the synchronization slave //Same as above 3  7. Restore the master backup file cd /var/
on the slave server 
lib/mysql 
tar –xvf repl.tar  
8. To achieve synchronization under the slave server mysql command, 
if the view cannot be synchronized normally, the following operations are required: 
        mysql> slave stop;mysql> change master to 
mysql> master_host='10.10.0.244 ', 
mysql> master_user='backup', 
mysql> master_password='123456', 
mysql> master_log_file='mysql-bin.000003', //file on the master service      
mysql> master_log_pos=106; //pos on the master server 
mysql> slave start; 
use show slave status\G; to see the synchronization of the slave  server  Slave_IO_Running
: 
Yes  Write some data inside to test to see if the synchronization is successful.  I encountered several problems during construction: I searched on the Internet, and the details are as follows: 1. The mysql.host table does not exist, causing the mysqld service to fail to start. The solution is to execute the mysql_install_db command . Use show slave status\G Slave_IO_Running on the slave server, If it is No, it means that IO_THREAD is not started, please execute start slave io_thread Slave_SQL_Running is No , the replication error occurs, check the Last_error field to eliminate the error and execute start slave sql_thread to check that the Slave_IO_State field is empty // Replication does not start Connecting to master// No connection to master Waiting for master to send event//connected to the relevant commands on the master server: show master status
















show slave hosts
show logs
show binlog events
purge logs to 'log_name'
purge logs before 'date'
reset master (old version flush master)
set sql_log_bin=
Related commands on the slave server:
slave start
slave stop
SLAVE STOP IO_THREAD //This thread puts The log of the master segment is written to the local
SLAVE start IO_THREAD
SLAVE STOP SQL_THREAD //This thread applies the log written to the local database to the database
SLAVE start SQL_THREAD
reset slave
SET GLOBAL SQL_SLAVE_SKIP_COUNTER
load data from master
show slave status(SUPER,REPLICATION CLIENT)
CHANGE MASTER TO MASTER_HOST=, MASTER_PORT=,MASTER_USER=, MASTER_PASSWORD= //dynamically change the master information
PURGE MASTER [before 'date'] delete the logs that have been synchronized on the master side
6.3.1 Master synchronization thread state
The following lists the most common states in the Master Binlog Dump thread State field. If there is no Binlog Dump thread on the master, then the synchronization is not running.
That is to say, no slave is connected.
Sending binlog event to slave
event is composed of binary log, an event usually consists of update statement plus other information. The thread has read an event and is sending it to the slave.
Finished reading one binlog; switching to next binlog Finished reading one binlog
and is switching to the next one.
Has sent all binlog to slave; waiting for binlog to be updated
All unfinished update logs have been read and all sent to slave. It is idle, waiting to perform new update operations on the master to produce new events in
the , and then read them.
Waiting to finalize termination
The current thread is stopped, and this time is very short.
6.3.2 Slave's I/O thread state
The following lists the most common states in the Slave's I/O thread State field. Beginning with MySQL 4.1.1, this state
also appears in the Slave_IO_State field of the result of executing a SHOW SLAVE STATUS statement. This means that more information can be learned just by executing the SHOW SLAVE STATUS statement.
Connecting to master
The thread certificate attempts to connect to the master.
Checking master version
determines a short-lived state that occurs after connecting to the master.
Registering slave on master
determines a short-lived state that occurs after connecting to the master.
Requesting binlog dump
identifies a brief state that occurs after connecting to the master. The thread sends a request to the master telling it which binary to request and where to start.
Waiting to reconnect after a failed binlog dump request
If a binary log dump request fails (due to a disconnection), the thread enters this state while sleeping and reconnects periodically. The reconnection interval is
specified by the --master-connect-retry option.
Reconnecting after a failed binlog dump request
The thread is trying to reconnect to the master.
Waiting for master to send event
has connected to master and is waiting for it to send binary log. If the master is idle, this state may persist for a long time, and if it waits longer than slave_read_timeout seconds
, a timeout will occur. At this point, it will consider disconnecting and then try to reconnect.
Queueing master event to the relay log
has read an event and is copying it to the relay log for processing by the SQL thread.
Waiting to reconnect after a failed master event read
An error occurred while reading the log (due to disconnection). The thread sleeps master-connect-retry seconds before reconnecting.
Reconnecting after a failed master event read
is trying to reconnect to master. When the connection is established, the state becomes Waiting for master to send event.
Waiting for the slave SQL thread to free enough relay log space
The value of relay_log_space_limit is non-zero, and the sum of the relay log sizes exceeds this value. The I/O thread waits for the SQL thread to process the relay logs first and then delete them to free up enough space
.
Waiting for slave mutex on exit
The current thread is stopped, and this time is very short.
6.3.3 Slave's SQL thread state
The following lists the most common states in the Slave's SQL thread State field:
Reading event from the relay log
An event is read from the relay log for execution.
Has read all relay log; waiting for the slave I/O thread to update it
has processed all events in the relay log and is waiting for the I/O thread to write the updated log.
Waiting for slave mutex on exit
The current thread is stopped, and this time is very short.
--------------
Some common problems:
1. Problems starting from the library SLAVE
Due to some wrong operations, the CHANGE MASTER and SLAVE services cannot be started, and the system reports the following error:
******* **************************************************** ********
Could not initialize master info structure; more error messages can be found in the MySQL error log.
************************ ********************************************
Failed to initialize master info structure, MySQL error The log records more detailed error messages.
Solution:
1. Check the MySQL error log, such as: what is the last position of synchronization. In many cases, the service cannot be started because the synchronization recognized by mysql always stays on the previous position.
2. Check master.info and relay-log.info, master.info records MASTER related information, relay-log.info records current synchronization log information.
3. Stop the myslq service and delete master.info and relay-log.info.
4. Start the mysql service.
5. Re-CHANGE MASTER, restart the SLAVE service.
2. The master and slave cannot synchronize
show slave status; error: Error xxx dosn't exist
and show slave status\G:
Slave_SQL_Running: NO
Seconds_Behind_Master: NULL
Solution:
stop slave;
set global sql_slave_skip_counter =1 ;
start slave
; Master to synchronize mainly to see:
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Seconds_Behind_Master is 0, 0 is already synchronized
2, and some optimization and monitoring need to be done:
show full processlist; //View the current synchronization thread number of mysql
skip-name-resolve //Skip dns name query to help speed up connection and synchronization
max_connections=1000 //Increase the number of Mysql connections, (default 100)
max_connect_errors=100 //Increase the number of Mysql error connections, (default 10)
check the log some commands
1, show master status\G;
here is mainly to see Whether the files of log-bin are the same.
show slave status\G;
here is mainly to see:
Slave_IO_Running=Yes
Slave_SQL_Running=Yes
If both are Yes, the configuration is successful.
2. Enter show processlist\G on the master;
mysql> SHOW PROCESSLIST\G
***** ************************ 1. row ************************ **
Id: 2
User: root
Host: localhost:32931
db: NULL
Command: Binlog Dump
Time: 94
State: Has sent all binlog to slave; waiting for binlog to
be updated
Info: NULL
If Command: Binlog Dump appears, the configuration is successful.
stop slave #Stop synchronization
start slave #Start synchronization and start updating from the location where the log is terminated.
SET SQL_LOG_BIN=0|1 #Host-side operation, requires super permission, used to start and stop the log, start and stop at will, it will cause inconsistent data between the host and the slave, resulting in errors
SET GLOBAL SQL_SLAVE_SKIP_COUNTER=n # The client is running, used to skip a few An event that can only be executed when the synchronization process stops with an error.
RESET MASTER #Run on the host side, clear all logs, this command is the original FLUSH MASTER
RESET SLAVE #Run on the slave machine, clear the log synchronization position flag, and regenerate master.info
Although master.info is regenerated, it does not To use, it is best to restart the mysql process of the slave machine,
LOAD TABLE tblname FROM MASTER #Slave run, reread the data of the specified table from the host side, only one can be read at a time, limited by the timeout time, you need to adjust the timeout time. Executing this command requires the synchronization account to have reload and super permissions. And have select permission on the corresponding library. If the table is relatively large, increase the value of net_read_timeout and net_write_timeout
LOAD DATA FROM MASTER #Slave execution, re-read all data from the host side. Executing this command requires that the synchronization account has reload and super permissions. And have select permission on the corresponding library. If the table is large, increase the value of net_read_timeout and net_write_timeout
CHANGE MASTER TO master_def_list #Change some host settings online, multiple separated by commas, such as
CHANGE MASTER TO
MASTER_HOST='master2.mycompany.com',
MASTER_USER='replication',
MASTER_PASSWORD='bigs3cret'
MASTER_POS_WAIT() #Slave running
SHOW MASTER STATUS #The host is running, see the log export information
SHOW SLAVE HOSTS #The host is running, see the status of the connected slaves.
SHOW SLAVE STATUS (slave)
SHOW MASTER LOGS (master)
SHOW BINLOG EVENTS [ IN 'logname' ] [ FROM pos ] [ LIMIT [offset,] rows ]
PURGE [MASTER] LOGS TO 'logname' ; PURGE [MASTER] LOGS BEFORE ' date'
show binlog events; #View the contents of the main library binary log file:
Note:
1. The synchronization of the main and auxiliary libraries is mainly achieved through the binary log.
2. When starting the auxiliary library, you must first synchronize the data and delete the master.info file in the log directory. Because master.info records the information about the last connection to the main library, if it is not deleted, even if it is modified in my.cnf, it will not work. Because the information in the master.info file is read.
3. If multiple virtual machines are cloned, there will be an error with the same id even if the server_id is inconsistent.
Reference URL:
1.http://www.jb51.net/article/27221.htm
2.http://www .jb51.net/article/29818.htm