preface
MySQL summary of the knowledge of a mind map to share with you
Copy the overview
Mysql’s built-in replication capabilities are the foundation for building large, high-performance applications. The data of Mysql is distributed to multiple systems. This distribution mechanism is realized by copying the data of a host of Mysql to other hosts and performing it again. One server acts as the master server and one or more other servers act as slave servers during replication. The master server writes updates to the binary log file and maintains an index of the file to track the log cycle. These logs record updates sent to the slave server. When a slave connects to the master, it informs the master of the last successful update read by the slave in the log. The slave server receives any updates that have occurred since then, then blocks and waits for the master server to notify of new updates.
Note that when you replicate, all updates to the replicated tables must be made on the master server. Otherwise, you must be careful to avoid conflicts between user updates to tables on the master server and updates to tables on the slave server.
Replication types supported by Mysql
1. Statement-based replication: SQL statements that are executed on the primary server are executed on the secondary server. MySQL uses statement-based replication by default, which is efficient. Row-based replication is automatically selected when it is found to be impossible to replicate exactly.
2. Line-based replication: Copy changes over instead of executing commands on a slave server. Supported as of Mysql5.0.
3. Mixed replication: statement-based replication is used by default. If statement-based replication cannot be exact, row-based replication is used.
Copy the problem solved
MySQL replication technology has the following features:
1. Data Distribution
2. Load balancing
3. Backup (Backups)
4. High availability and failover
How replication works
Overall, there are three steps to replication:
1. The master logs changes to the binary log. These logs are called binary log events.
2. Slave copies the master binary log events to its relay log.
3. Slave reworks events in the trunk log to change the data that reflects itself.
The following diagram illustrates the replication process:
1. The first part of the process is for the master to record binary logs. Before each transaction updates the data, the master logs these changes in the second log. MySQL writes transactions serially to the binary log, even though the statements in the transaction are executed across. After the event is written to the binary log, the master notifies the storage engine to commit the transaction.
2. The next step is for the slave to copy the master’s binary log to its own relay log. First, slave starts a worker thread — the I/O thread. The I/O thread opens a normal connection on the master and starts the binlog dump process. The Binlog dump process reads events from the master’s binary logs. If it has followed the master, it sleeps and waits for the master to generate new events. The I/O thread writes these events to the relay log.
3.SQL slave threads process the last step of the process. The SQL thread reads the events from the slave log and replays the events to update the slave data to match the data in the master. As long as the thread is consistent with the I/O thread, the relay log is usually in the OS cache, so the overhead of the relay log is minimal.
4. In addition, there is also a worker thread in the master: as with other MySQL connections, opening a connection in the master causes the master to start a thread. The replication process has one important limitation — replication is serialized on the slave, which means that parallel updates on the master cannot be performed in parallel on the slave.
Primary/secondary replication configuration
There are two MySQL database servers: Master and slave. Master is the Master server and slave is the slave server. In the initial state, the data information in Master and slave is the same. Synchronize data between the master and slave for backup.
Key points:
The medium responsible for transferring the various changes between the master and slave servers is the binary change log of the master server, which records the various changes that need to be transferred to the slave server. Therefore, binary logging must be enabled on the primary server. The slave server must have permissions that allow it to connect to the master server and request that the binary change log be transferred to it.
Environment:
1. The version of the Master and slave MySQL databases is 5.0.18
2.IP address: 10.100.0.100
Creating a Replication Account
1. Create a backup account in the Master database: each slave connects to the Master using the standard MySQL username and password. The user performing the REPLICATION operation is granted REPLICATION SLAVE. Usernames and passwords are stored in a text file called master.info
The command is as follows:
Mysql > GRANT REPLICATION SLAVE,RELOAD,SUPER ON *.* TO backup@ '10.100.0.200' IDENTIFIED BY '1234';Copy the codeCreate a backup account and allow login only from 10.100.0.200 with password 1234.
If the mysql version is different from the old password algorithm, you can set:
Set the password for 'backup' @ '10.100.0.200 = old_password (' 1234')Copy the codeCopy the data
(This step is not necessary if you have completely new mysql master/slave server installed. Because the newly installed master and slave have the same data.
Shut down the Master server and copy the data in the Master server to the B server to synchronize the data in the Master and slave servers. Make sure that no write operations are performed on the Master and slave servers until all Settings are complete. Ensure that the data in the two databases must be the same.
Configure the master
Next configure the master, including turning on binary logging and specifying a unique Servr ID. For example, add the following values to the configuration file:
Server-id =1 log-bin=mysql-bin server-id: indicates the ID of primary server A. log-bin: indicates the binary change daily valueCopy the codeRestart the master and run SHOW master STATUS. The following output is displayed:
Configuration of slave
The Slave configuration is similar to that of the master. You also need to restart the Slave MySQL. As follows:
Log_bin = mysql-bin server_id = 2 relay_log = mysql-relay-bin log_slave_updates = 1 read_only = 1 #server_id: Mandatory and unique.Copy the codelog_bin
It is not necessary for slave to enable binary log bin_log. However, it must be enabled in some cases. For example, if slave is the master of another slave, bin_log must be enabled. Here, we have binary logging turned on, and the naming of the display (the default name is hostname, but there are problems if the hostname changes).
relay_log
Configure relay logging, log_slave_updates means that slave writes replication events to its binary log (see how useful this is later). Some people enable binary logging for their slave without setting log_slave_updates, and then check to see if the slave data has changed. This is a configuration error.
read_only
Use read_only whenever possible, which prevents data from changing (except for special threads). However, read_ONLY is not very useful, especially if you need to create tables on your slave.
Start the slave
The next step is to have the slave connect to the master and start redoing the events in the master binary log. You should not do this with a configuration file, but instead use the CHANGE MASTER TO statement, which completely replaces the modification TO the configuration file, and it can specify a different MASTER for the slave without stopping the server. As follows:
mysql> CHANGE MASTER TO MASTER_HOST='server1',
-> MASTER_USER='repl',
-> MASTER_PASSWORD='p4ssword',
-> MASTER_LOG_FILE='mysql-bin.000001',
-> MASTER_LOG_POS=0;
Copy the codeThe value of MASTER_LOG_POS is 0 because it is where the log starts.
You can check whether the SLAVE is set correctly by using the SHOW SLAVE STATUS statement:
mysql> SHOW SLAVE STATUS\G *************************** 1. row ***************************
Slave_IO_State: Master_Host: server1 Master_User: repl Master_Port: 3306 Connect_Retry: 60 Master_Log_File: mysql-bin.000001 Read_Master_Log_Pos: 4 Relay_Log_File: mysql-relay-bin.000001 Relay_Log_Pos: 4 Relay_Master_Log_File: mysql-bin.000001 Slave_IO_Running: No Slave_SQL_Running: No ... omitted... Seconds_Behind_Master: NULLCopy the codeSlave_IO_State, Slave_IO_Running, and Slave_SQL_Running are No, indicating that slave has not started the replication process. The log position is 4 instead of 0 because 0 is just the start of the log file, not the log position. In fact, the location of the first event that MySQL knows is 4.
To start copying, you can run:
mysql> START SLAVE;
Copy the codeRun SHOW SLAVE STATUS to view the output:
mysql> SHOW SLAVE STATUS\G *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: server1 Master_User: repl Master_Port: 3306 Connect_Retry: 60 Master_Log_File: mysql-bin.000001 Read_Master_Log_Pos: 164 Relay_Log_File: mysql-relay-bin.000001 Relay_Log_Pos: 164 Relay_Master_Log_File: mysql-bin.000001 Slave_IO_Running: Yes Slave_SQL_Running: Yes ... omitted... Seconds_Behind_Master: 0Copy the codeHere is mainly to see:
1.Slave_IO_Running=Yes
2.Slave_SQL_Running=Yes
The SLAVE I/O and SQL threads are already running, and Seconds_Behind_Master is no longer NULL. The location of the log is increased, which means that some events are fetched and executed. If you make changes on the master, you can see changes in the location of various log files on the slave, as well as changes in the data in the database.
You can view the status of threads on master and slave. On the master, you can see the connection created by the SLAVE I/O thread:
Type show processList \G on master;
mysql> show processlist \G
*************************** 1. row ***************************
Id: 1
User: root
Host: localhost:2096
db: test
Command: Query
Time: 0
State: NULL
Info: show processlist
*************************** 2. row ***************************
Id: 2
User: repl
Host: localhost:2144
db: NULL
Command: Binlog Dump
Time: 1838
State: Has sent all binlog to slave; waiting for binlog to be updated
Info: NULL
2 rows in set (0.00 sec)
Copy the codeLine 2 is the connection that handles the SLAVE I/O thread.
Run this statement on the slave server:
mysql> show processlist \G
*************************** 1. row ***************************
Id: 1
User: system user
Host:
db: NULL
Command: Connect
Time: 2291
State: Waiting for master to send event
Info: NULL
*************************** 2. row ***************************
Id: 2
User: system user
Host:
db: NULL
Command: Connect
Time: 1852
State: Has read all relay log; waiting for the slave I/O thread to update it
Info: NULL
*************************** 3. row ***************************
Id: 5
User: root
Host: localhost:2152
db: test
Command: Query
Time: 0
State: NULL
Info: show processlist
3 rows in set (0.00 sec)
Copy the codeLine 1 is the I/O thread state, and line 2 is the SQL thread state.
Add a slave server
If the master has been running for a long time and you want to synchronize data to the newly installed slave, even if it does not have the master’s data. At this point, there are several ways to make a slave start from another service, for example, copy data from the master, clone data from another slave, and start a slave from the most recent backup. To synchronize the Slave and master, you need three things:
(1) A snapshot of the data at the master point in time;
(2)master the current log file and the byte offset when the snapshot was generated. These two values are called log file coordinate, because they determine the location of a binary log, and you can use the SHOW MASTER STATUS command to figure out the coordinate of the log file;
(3) Master binary log file.
You can clone a slave in the following ways
(1) Cold copy
Stop master and copy master files to slave. Then restart the master. The disadvantages are obvious.
(2) Warm copy
If you only use MyISAM tables, you can use mysqlHotCopy even if the server is running.
(3) use the mysqldump
<1> Lock table: if you do not already lock the table, you should lock the table to prevent other connections from modifying the database, otherwise, you can get inconsistent data. As follows:
Using mysqldump to get a snapshot of the data can be divided into the following steps:
mysql> FLUSH TABLES WITH READ LOCK;
Copy the code<2> Create a dump of the database you want to replicate on another connection with mysqldump:
shell> mysqldump --all-databases --lock-all-tables >dbdump.db
Copy the code<3> Release the lock on the table.
mysql> UNLOCK TABLES;
Copy the codeLearn more about replication
Having covered some of the basics of replication, let’s take a closer look at replication.
Statement-based Replication
MySQL 5.0 and earlier only supported statement-based replication (also known as logical replication, logical replication), which is not common in databases. The master records the query that changes the data. The slave then reads the event from the slave slave log and executes it. These SQL statements are the same as those executed by the master.
The advantage of this approach is the simplicity of implementation. In addition, statement-based replication of binary logs can be well compressed and log data is small and bandwidth intensive – for example, a query updating gigabytes of data requires only a few dozen bytes of binary logs. Mysqlbinlog is handy for statement-based log processing.
However, statement-based replication is not as simple as it seems, because some query statements depend on specific conditions for the master; for example, the master and slave may have different times. So, MySQL binary logs are formatted not just for queries, but also for metadata information, such as the current timestamp. Even so, some statements, such as the CURRENT USER function, do not copy correctly. In addition, stored procedures and triggers are an issue.
Another problem is that statement-based replication must be serialized. This requires a lot of special code, configuration, such as InnoDB’s next-key lock, etc. Not all storage engines support statement-based replication.
Record Based Replication (ROW-based Replication)
MySQL adds record-based replication, recording changes to the actual data in a binary log, similar to how some other DBMSS are implemented. There are advantages and disadvantages to this approach. The advantage is that it can work correctly with any statement, and some statements are more efficient. The main drawback is that binary logs can be large and unintuitive, so you can’t use mysqlbinlog to view binary logs.
Record-based copying works more efficiently for some statements, such as:
mysql> INSERT INTO summary_table(col1, col2, sum_col3)
-> SELECT col1, col2, sum(col3)
-> FROM enormous_table
-> GROUP BY col1, col2;
Copy the codeSuppose there are only three unique col1 and COL2 combinations, but the query scans many rows of the original table and returns only three records. At this point, record-based replication is more efficient.
On the other hand, statement-based replication is more efficient with the following statements:
mysql> UPDATE enormous_table SET col1 = 0;
Copy the codeRecord-based replication can be very expensive at this point. Since neither approach works well in all cases, MySQL 5.1 supports dynamic exchange before statement-based replication and record-based replication. You can control this by setting the session variable binlog_format.
Copy the related files
In addition to binary and relay log files, there are other copy-related files. As follows:
(1)mysql-bin.index
Once binary logging is enabled on the server, a file with the same name as the binary log file but ending with.index is generated. It is used to track which binary log files exist on disk. MySQL uses it to locate binary log files. It reads as follows (on my machine) :
(2)mysql-relay-bin.index
The function of this file is similar to that of mysql-bin.index, but it is for relay logs, not binary logs. As follows:
.\mysql-02-relay-bin.000017
.\mysql-02-relay-bin.000018
Copy the code(3)master.info
Save information about the master. Do not delete it; otherwise, the slave cannot connect to the master after it restarts. It reads as follows (on my machine) :
The I/O thread updates the master.info file with the following content (on my machine) :
.\mysql-02-relay-bin.000019
254
mysql-01-bin.000010
286
0
52813
Copy the code(4)relay-log.info
Contains information about current binary logs and trunk logs of the slave.
Sends replication events to other slaves
When setting log_slave_updates, you can have your slave act as the master of another slave. At this point, the slave writes the events executed by the SQL thread into its own binary log, which its slave can then retrieve and execute. As follows:
Replication Filters
Replication filtering allows you to copy only a portion of the server’s data. There are two types of replication filtering: filtering binary log events on the master; Filter events in the trunk log on the slave. As follows:
Common topologies for replication
The architecture of replication has the following basic principles:
(1) Each slave can have only one master;
(2) Each slave can only have a unique server ID;
(3) Each master can have many slaves;
(4) If you set log_slave_updates, the slave can be the master of another slave, thereby spreading out the master updates.
MySQL does not support Multimaster Replication — that is, a slave can have multiple masters. However, with a few simple combinations, we can build flexible and powerful replication architectures.
Single master and multiple slaves
A replication system consisting of one master and one slave is the simplest case. The slaves do not communicate with each other, but only with the master.
In actual application scenarios, more than 90% of MySQL replication is a Master replication to one or more slaves. It is mainly used as a cheap database-side expansion solution for applications with heavy read pressure. As long as the pressure on the Master and Slave is not too high (especially on the Slave side), the latency of asynchronous replication is usually very small. Especially since the Slave replication mode is changed to two threads, the delay problem on the Slave side is reduced. The benefit is that, for applications with non-critical data real-time requirements, only cheap PCServer is needed to expand the number of slaves and spread the read pressure to multiple Slave machines, so as to solve the database side read performance bottleneck by spreading the read pressure of a single database server. After all, in most database applications, the read pressure is much greater than the write pressure. This has largely solved the database bottleneck problem of many small and medium-sized websites, and even some large websites are using similar solutions to solve the database bottleneck.
As follows:
If the write operation is small and the read operation is very short, this structure can be adopted. You can distribute reads to other slaves to reduce the stress on the master. However, when the number of slaves increases to a certain level, the load of slaves on the master and network bandwidth becomes a serious problem.
This structure is simple, but it is flexible enough to meet most application requirements. Some suggestions:
(1) Different slaves perform different functions (such as using different indexes or storage engines);
(2) Use a slave as the standby master, and only replicate;
(3) Use a remote slave for disaster recovery;
As you probably know, it is possible to copy multiple Slave nodes from one Master node. One might wonder, can a Slave node be copied from multiple Master nodes? At least for now, MySQL can’t do that, and it’s not clear if it will.
MySQL does not support the architecture of a Slave node replicating from multiple Master nodes. This is mainly to avoid conflicts between multiple data sources, resulting in data inconsistency. However, I heard that related patch has been developed to enable MySQL to support a Slave node to replicate from multiple Master nodes as data sources, which is exactly the benefit brought by the open source nature of MySQL.
Active mode
Master-Master(Master-Master in Active-Active Mode)
Master-master The two replication servers are both masters and slaves of the other server. In this way, changes made by either party are replicated to the other party’s database.
Some readers may be concerned about this. After setting up the replication environment, won’t it cause a loop of replication between two MySQL servers? MySQL has already thought of this, so the current MySQL server id is recorded in MySQL BinaryLog, and this parameter must be specified when we set up MySQLReplication. The server id ratio of the Master and Slave must be inconsistent for MySQLReplication to be set up successfully.
Once you have the server-ID value, it is easy for MySQL to determine which MySQLServer a change was originally made from, so it is easy to avoid circular replication. Also, if we do not turn on the Slave’s BinaryLog option (–log-slave-update), MySQL will not record the changes to the BinaryLog during the replication process, let alone worry about the possibility of circular replication. Figure: Active master-master replication has some special uses. For example, both geographically distributed parts need their own writable copies of data. The biggest problem with this structure is update conflict. Suppose a table has only one row (column) of data with the value 1, if both servers execute the following statement simultaneously:
Mysql > UPDATE TBL SET col=col + 1; Mysql > UPDATE TBL SET col=col * 2;Copy the codeSo what is this going to be? One server is 4 and the other is 3, however, this does not generate an error.
In fact, MySQL does not support Multimaster Replication, which is supported by some other DBMSS. This is a major limitation of MySQL’s Replication capabilities (the difficulty with multi-master is resolving update conflicts), but if you have such a need, You can take MySQL Cluster and combine Cluster with Replication to build a powerful high-performance database platform. However, there are other ways to simulate this multi-master server replication.
This is a variation of the master-master structure. It avoids the disadvantages of M-M. In fact, it is a fault-tolerant and highly available system. The difference is that one of the services can only be read-only. As shown in figure:
Cascading replication architecture Master — Slaves — Slaves
In some application scenarios, there may be a large difference in read/write pressure. The read pressure is particularly high. A Master may need 10 or more slaves to support the read pressure. The Master will be more difficult, because only the SlaveIO thread is connected, so the pressure of writing is slightly higher, the Master will consume more resources because of the replication, it is easy to cause the replication delay.
How to solve this situation? In this case, we can take advantage of MySQL’s ability to record BinaryLog information on the Slave side of the replication changes, by turning on the -log-slave-update option. Then, use secondary (or more) levels of replication to reduce the stress on the Master side. That is, we first replicate from the Master through a few MySQL machines, which we will call the primary Slave cluster, and then the other slaves replicate from the primary Slave cluster. The slaves that replicate from the first level are what I call the second level Slave cluster. We can go down and add more levels of replication if needed. In this way, we can easily control the number of slaves attached to each MySQL. This is what I call the master-slaves architecture
This architecture of multi-level concurrent replication easily solves the risk that the Master end will become a bottleneck due to too many slaves. The following figure shows the Replication architecture for multi-tiered concurrent Replication.
Of course, if possible, I would prefer to recommend splitting the solution into multiple Replication clusters
The above bottlenecks. After all, slaves did not reduce the amount of write, and all slaves still applied virtually all data change operations without reducing any write IO. On the contrary, the more slaves there are, the more IO will be written in the whole cluster. We don’t have a very obvious sense of it, just because it is spread across multiple machines, so it is not easy to show it.
In addition, by increasing the cascade level of replication, the same change will have to pass through more MySQL to be transmitted to the Slave at the bottom level, which may also cause the risk of a longer delay.
It would have been much better if we had split the cluster, which of course requires more complex technology and application architecture.
Master-master with Slaves The advantage of this structure is that it provides redundancy. Geographically distributed replication structure, it does not have the problem of single node failure, and it can also put read-intensive requests on the slave.
Cascaded Replication does solve the problem that the Master becomes a bottleneck due to too many slaves, but it does not solve the problem that Replication may be rebuilt if manual maintenance or failover occurs due to exceptions. This naturally leads to the Replication architecture of DualMaster and cascading Replication, which I call master-Master-Slaves
Compared to the master-Abolition-Slaves architecture, the difference is simply that the first level Slave cluster is replaced by a separate Master as the standby Master and then replicated from this standby Master to a Slave cluster.
The biggest advantage of the combined architecture of DualMaster and cascading Replication is that the Master Master’s write operations are not affected by the Replication of the Slave cluster, and the Master Master’s need to switch is basically free of Replication Replication. However, the downside of this architecture is that the Slave Master can become a bottleneck because if the Slave cluster is large, the Slave Master can become a bottleneck due to excessive SlaveIO thread requests.
Of course, if the standby Master does not provide any read services, the possibility of bottlenecks is not very high. If the bottleneck occurs, cascaded replication can be carried out after the standby Master to set up a multi-layer Slave cluster. Of course, the more levels of cascading replication, the more significant the data delay may occur in the Slave cluster. Therefore, before using multi-tiered cascading replication, you need to evaluate the impact of data delay on the application system.
Common problems with replication
A wrong
Change master caused by:
Last_IO_Error: error connecting to master 'repl1@IP:3306' - retry-time: 60 retries
Copy the codeError 2
Stopping the slave process without unlocking it:
mysql> stop slave;
ERROR 1192 (HY000): Can't execute the given command because you have active locked tables or an active transaction
Copy the codeError of three
Change master without stopping the slave process
Mysql > change master to master_host= 'IP', master_user='USER', master_password='PASSWD', master_log_file='mysql-bin.000001',master_log_pos=106; ERROR 1198 (HY000): This operation cannot be performed with a running slave; run STOP SLAVE firstCopy the codeError four
The server ID of user A and user B is the same:
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). # check server-id mysql> show variables like 'server_id'; Mysql > set global server_id=2; Mysql > slave start; mysql> slave start;Copy the codeError five
After changing master, check the slave status. Slave_IO_running is still NO
Slave_IO_running changes to Yes after the mysql process restarts
Error 6
Client requested master to start replication from position > file size
The read binlog position from the library is greater than the current binglog value of the main library
This problem is usually caused by the restart of the master library. The default sync_binlog parameter of the master library is 1000, that is, the data of the master library is cached to 1000 and then fsynced to the binlog file on the disk.
When the master library is restarted, the slave library reads the master library directly and re-pulls the binlog at the previous location, but the master library does not fsync the last binlog, so it returns an error 1236.
It is recommended to set sync_binlog to 1, that is, every transaction is immediately written to the binlog file.
1. Check the slave status in the slave library:
The offset is 4063315
2, check mysql-bin.001574 offset in primary library
mysqlbinlog mysql-bin.001574 > ./mysql-bin.001574.bak
tail -10 ./mysql-bin.001574.bak
Copy the codeThe last few lines of the mysql-bin.001574 file show that the last offset is 4059237. The offset of 4063315 from the library is much larger than the offset of 4059237 from the main library, which is caused by sync_binlog=1000.
3. Reset salve
mysql> stop slave;
mysql> change master to master_log_file='mysql-bin.001574' ,master_log_pos=4059237;
mysql> start slave;
Copy the codeError of seven
Data synchronization is abnormal
First: Delete a record on the master, but not on the slave.
Last_Error: Could not execute Delete_rows event on table market_edu.tl_player_task; Can't find record in 'tl_player_task', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log mysql-bin.002094, end_log_pos 286434186
Copy the codeSolution: An error was reported because the master wanted to delete a record, but the slave could not find it. In this case, the master deleted the record, so the slave can directly skip. Available commands:
stop slave;
set global sql_slave_skip_counter=1;
start slave;
Copy the codeSecond: primary key duplication. The slave already has the record, and the master inserts the same record.
Last_SQL_Error: Could not execute Write_rows event on table hcy.t1;
Duplicate entry '2' for key 'PRIMARY',
Error_code: 1062;
handler error HA_ERR_FOUND_DUPP_KEY; the event's master log mysql-bin.000006, end_log_pos 924
Copy the codeSolution: Delete duplicate primary keys on slave.
Third: update a record on the master, but cannot find it on the slave, and the data is lost.
Last_SQL_Error: Could not execute Update_rows event on table hcy.t1;
Can't find record in 't1',
Error_code: 1032;
handler error HA_ERR_KEY_NOT_FOUND; the event's master log mysql-bin.000010, end_log_pos 263
Copy the codeSolution: Replace the lost data on the slave and skip the error report.
insert into t1 values (2,'BTV'); stop slave ; set global sql_slave_skip_counter=1; start slave;Copy the codeThe last
I have arranged a: MySQL related information documents and knowledge map, Java systematic information, (including Java core knowledge points, interview topics and the latest Internet real questions in 20 years, e-books, etc.) friends who need to pay attention to the public number [procedure Yuan Small wan] can be obtained.