Shulou(Shulou.com)06/02 Report--

Many novices are not very clear about how MYSQL explores the read-write separation architecture in non-Internet enterprises. In order to help you solve this problem, the following editor will explain it in detail. People with this need can come and learn. I hope you can get something.

The high availability and use of MYSQL are mostly based on the Internet, MHA,PXC, which are widely used in the Internet, and are used very well. Internet enterprises are full of "high-end talents" who modify the original code of MYSQL.

On the contrary, why traditional enterprises, financial enterprises use MYSQL, and let this database carry forward the lack of Phoenix hair water chestnut.

Throw out Internet companies dare to give money, dare to hire people, anything can be rebuffed in doing, in the basic idea of improvement. A lot of support and maintenance of the strength of operation and maintenance can not be ignored.

Traditional enterprises are far behind in this respect, so databases like MYSQL are not easy to use, plus the compactness of the business and the way of development, and so on bulabula. The use of the above enterprises in the architecture of MYSQL brings a lot of inconvenience to the operation and maintenance.

Personally, I think (and may need to continue to improve) that the architecture of MYSQL needed by traditional enterprises or financial enterprises is easy to maintain and use, but also to compromise some ways of developing traditional business.

You can use ORACLE RAC, Dataguard, SQL SERVER's Cluster, Always-on, etc., at least in read-write separation or highly intensive operations without giving you too embarrassing performance. MYSQL used to be master-slave replication, and to ensure the consistency of master-slave replication, in addition to using a "single tiger" such as semi-synchronization, and then a variety of development requirements, to support hundreds or even thousands of people on the Internet, the development team has the technical force to resolve those intensive operations. However, traditional enterprises do not have so much money to hire so many developers and operation and maintenance personnel.

A reliable MYSQL architecture is particularly important, and MGR, as a replication or highly available way of MYSQL, has been pushed away. Of course, there are problems, but at least he can give you, 1 data consistency 2 simple maintenance mode 3 compared with other ways, with reliable middleware, traditional developers can basically achieve the separation of reading and writing they want, as well as the FAILOVER that operators need, and transparent switching of applications.

That's a little practical. Here's a MYSQL high availability architecture with read-write separation.

In fact, it may not matter which middleware is used, but in order to better simplify the work of operation and maintenance, we can actually use DOCKER to containerize the middleware, which can reduce the workload of the FAILOVER of the middleware and save resources at the same time (the traffic of traditional enterprises is usually small). There is another estimate in the architecture that someone wants to challange, that is, why do you want to use two middleware? to be honest, you don't have to use one middleware, but the two middleware also consider traditional enterprise developers. You want him to completely take all the SELECT statements from the library, which is also a challenge for him, and there will be a lot of problems. Here are two middleware, that is, to provide a buffer for operation and development. If you want to write to the library, you should use a middleware. If you want to use it only in a read-only way, you can access another read-only middleware, which is relatively friendly to both developers and operators.

This can not only meet the traditional enterprise development and operation and maintenance of LEVEL, but also can be more simple batch customized deployment. At the same time, it is also a transparent switch for applications (standby-primary)

Some people may also ask why middleware is not reused, multiple sets of MGR using one middleware to do FAILOVER is not also OK, in fact, it is possible, but if you use DOCKER, it is actually better to separate, a set of MGR uses its own, so as to reduce coupling, problems are not large area, will only affect the relevant corresponding MGR.

1 normal state

2 primary node failover status

3 status after switching

The rest is the deployment of DOCKER middleware and the problem of DOCKER FAILOVER.

Is it helpful for you to read the above content? If you want to know more about the relevant knowledge or read more related articles, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.