“This is the 8th day of my participation in the Gwen Challenge.
What problem does master-slave synchronization solve?
The business scenario for most of our systems is to write less and read more in order to have as little impact as possible between reads and writes. Then we need to separate the data from reading and writing. Ensure that the write and read services are not affected.
How can reading and writing in a database be affected? First of all, the number of database connections and threads is limited, and database writes are much busier than multiple operations. If the data written is blocked, it is likely to cause a large number of read operations. Eventually the connection count and thread data run out, causing both read and write operations to time out.
Let’s take a look at the master-slave principle
We know that the master/slave synchronization between databases is mostly carried out through binLog logs. The biggest problem of binLog synchronization is that the network jitter or frequent changes of database tables will lead to the delay between the master and slave. If the problem of delay has the greatest impact on the query of the slave library, if you ensure that the master and slave delay scheme has the following three ways
The first way is to write and read the primary library simultaneously, and the secondary library acts as the backup library. This solution is suitable for scenarios with a small amount of data.
The second way is to add a layer of caching between the write library and the read library. If the write succeeds, the expired data is deleted from the cache. Re-cache data as it is read.
The third method and the second method have the disadvantage that if the data is hot data, if I perform delete operation, it will probably cause cache breakdown. Some business scenarios where the data is not up to date are acceptable. Deletion may cause the slave library to be suspended by a read request. You can do patches in the second way. Wouldn’t it be nice if we had an active cache update operation? So that’s our third way of looking at whether it’s better to listen to the binLog from the library and actively update the cache