Replication thread
MySQL replication is an asynchronous replication process, from one MySQL instace (we call it the master) to another MySQL instance (we call it the slave ). The entire replication process between the master and slave is mainly completed by three threads, two of which (SQL thread and IO thread) are on the slave side, and the other (IO thread) on the master side. To implement replication for MySQL, you must first enable the binary log (mysql-bin.xxxxxx) function on the master side, otherwise it cannot be implemented. The whole replication process is actually because slave obtains the log from the master end and then executes the operations recorded in the log in full order on itself. To enable binary log of MySQL, you can use the "-log-bin" parameter option during MySQL server startup, or use mysqld in the my. CNF configuration file.
The "Log-bin" parameter item is added to the parameter group (the parameter section marked by [mysqld. The basic process of MySQL replication is as follows: 1. the IO thread on the slave connects to the master and requests the log content after the specified location (or from the beginning) of the log file; 2. after the master receives a request from the slave Io thread, the IO thread responsible for replication reads the log information after the specified log location based on the request information and returns it to the slave Io thread. In addition to the information contained in the log, the returned information also includes the name of the binary log file on the master end and its location in the binary log; 3. after the slave Io thread receives the information, it writes the received log content to the end of the relay log file (mysql-relay-bin.xxxxxx) at the slave end in sequence, and record the file name and location of the bin-log on the master end to the master-info file, so that the next read can clearly show the High-Speed Master "I need to start from the location of a bin-log, please send it to me" 4. after the slave SQL thread detects the newly added content in the relay log, it will immediately parse the content in the log file into the executable query statements during actual execution on the master end, and execute these queries on your own. In this way, the same query is actually executed on the master and slave ends, so the data at both ends is exactly the same. In fact, in the old version, MySQL replication implementation on the slave end is not completed by collaboration between the SQL thread and the IO thread, instead, a single thread is used to complete all the work. However, MySQL engineers quickly discovered that there are great risks and performance problems in doing so, mainly as follows: First, if a single thread is used to achieve this independently, the replication of the master, binary log, and the parsing of these logs, and then the execution of this process into a serial process, the performance will naturally be greatly limited, replication latency in this architecture is naturally longer. Second, after the replication thread on the slave side obtains the binary log from the master side, it needs to parse the content, restore it to the original query executed by the master side, and then execute it on its own. In this process, the master end may have produced a lot of changes and generated a lot of binary log information. If the master-side storage system encounters an irreparable fault at this stage, all changes made at this stage will be lost forever and cannot be recovered. This potential risk is especially prominent when the slave side is under great pressure, because if
Slave is under great pressure. It takes longer to parse logs and apply these logs, and more data may be lost. Therefore, in the later transformation, in order to minimize this risk and improve the replication performance, the new version of MySQL will replace the replication on the slave end with two threads, that is, the SQL thread and IO thread mentioned above. Yahoo! was the first to propose this improvement solution! Jeremy zawodny, an engineer in the project ". This transformation not only solves the performance problem to a large extent, shortens the asynchronous delay time, but also reduces the potential data loss. Of course, even after two threads are switched to the current mode for collaborative processing, there is still the possibility of Slave Data latency and data loss. After all, this replication is asynchronous. As long as data changes are not in a transaction, these problems exist. To completely avoid these problems, you can only use the MySQL cluster to solve them. However, the MySQL cluster knows that when I write this part of the content, it is still a solution for the memory data base, that is, to load all the data, including indexes, to the memory, in this way, the memory requirements are very large, and the implementation of general popular applications is not too large. Of course, when talking with MySQL's CTO David, I learned that MySQL is constantly improving its cluster implementation. One of the major changes is to allow data not to be all
Load the index to the memory, but only load the index to the memory. I believe that after the transformation, the MySQL cluster will be more popular and more feasible.
