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

When I talked about the status and development of MySQL and Oracle at QCon and Gdevops Guangzhou last year, I briefly summarized the next common misconception: using MySQL as Oracle, or using Oracle as MySQL.

There are so many cases around us that many people who rely heavily on Oracle think MySQL is too weak, and MySQL people think Oracle's solution scalability is not good enough. In fact, we can look at it from several dimensions. Today, we will focus on some technical points of MySQL.

MySQL's high availability, if extended, can be considered from three dimensions, application layer, database layer, system layer (including network layer). Assuming that the database level has been able to do the best, the data level can maintain access to data services. From the network level, we need DNS support to meet the high availability of two levels, one is DNS high availability in the same computer room (or the same computer room), and the other is DNS high availability across computer rooms (across regions). From the perspective of database business demands and network planning, DNS used is not for external services, so it can be understood that it is the role of local DNS. In this way, We do not need to deliberately maintain VIP switching, the network layer or middleware layer is strong enough, we only need to pay special attention to the availability of database services and data consistency.

If you look at the upper level, it is the application level. In fact, the application accesses the database service using the domain name. He doesn't need to know what the corresponding IP is at all. Just like we visit Google, we only need to know that it is google.com. If there is a high availability at the network level to ensure that a DNS takes effect policy, such as 10 seconds, 1 minute, etc., then the transformation required at the application layer is a short connection or an application reconnection mechanism, because there is no doubt that there will be a layer of cache at the application end, and long connections are easy to appear "lost in the past state".

Therefore, a relatively complete solution should be the system layer, network layer, database layer and application layer to work together to ensure a basic high availability solution.

If you want to achieve more complex high availability, for example, it is not limited to disaster recovery, do double-active and multi-active, etc., in fact, the complexity of the entire architecture will be much higher.

Let me start by giving you some ideas about MySQL high availability scenarios.

As you know, MHA is a highly available solution that MySQL DBAs like very much, because it is really very classic, I looked at the implementation of the code, the logic part is very perfect, and many of the points we did not consider were verified at the code level. Therefore, MHA is a very mature solution, which has grown up in various application scenarios. If it is an earlier version of the use of MHA is a standard action, we know that there are some changes in the later MHA, one is since the 0.56 version began to introduce binlog server, on this basis there is a 0.57 version, after the github there is no version update. If you look closely at the improvements in 0.56 and 0.57, the main change is a supplement to data integrity, although this architecture is somewhat invasive to existing quick restores. So many of our companies use MHA, but in fact they still don't use binlog server. MHA also has a special place is the handling of network exceptions, in fact, 0.56 and 0.57 are some differences, of course, in the details of the test, in fact, encountered some exceptions are more entangled, it seems that how to explain can be, so 0.56 and 0.57 as the watershed, for the difference in network processing, I prefer the 0.56 version, so we iterated the test 0.56, 0.57 and then back again to complement the 0.56 scene.

Of course, the harvest of this process is relatively large. I also looked at some of the codes of MHA and sorted out my ideas. But I found a problem, I believe many friends have a similar feeling, that is, MHA is written by perl, it is very strange and awkward for many people, because perl language itself groups and readability is there some gap, so we actually prefer to use Python to achieve this thing, of course, with other languages can also be, at least the group is larger.

In fact, when I investigated the details of MHA, I planned to do the python work of MHA code in the year after next. However, I sorted out my own ideas and found that this thing actually has great technical value, but the difference between investment and cost is very large. First, it is very difficult to transform. I have to understand Perl, and then rewrite it with Python or understand the original logic, sort out the shortcomings, and rebuild it. I thought about more details. For the shortcomings of MHA, etc. This is a technical investment, which is very large and difficult. It is very helpful for personal growth. However, from the other three angles, I think it may not be of great practical significance. First, the current technical scheme MHA has no obvious advantages. Second, if the version I modified is good enough, how can it be implemented in the company? If there is no problem running all the time, then the practical significance is actually not great enough. Third, I promote to the community, whether everyone can accept, because I am not facing a state many years ago, how to ensure that I write well enough, or write correctly, this is not a question of patting the head, it must be a lot of careful testing to be convincing.

So many big companies actually did this a long time ago, of course, it may just not be external. Of course, for MySQL's high availability, double-active solutions have always been a lot of solutions, or experiences that seem to work.

For example, the double-master, funnel-shaped architecture design, in fact, in many companies in the early days is indeed done, it seems that this solution has no special difficulties, but when dealing with these critical points, or to invest a lot of effort. I don't intend to say much about this scheme, but more about exception handling.

Then let's talk about MGR. In fact, it should be InnoDB Cluster. I am very optimistic about this solution. Many people may be unfamiliar with it. In fact, the first one we are familiar with is MGR. If InnoDB Cluster is compared to a troika, it is composed of MySQL Shell, MySQL Router and MySQL Group Replication. The core component is MGR. His genes are truly distributed, based on the paxos protocol. Of course, from the perspective of data architecture, availability and integrity are guaranteed for replication-based solutions, but performance is degraded, so MGR simply limits the number of nodes. This concept is different from traditional relational database nodes.

If you pay attention to the Windows installation version, you will find that InnoDB Cluster has been packaged as the default installation service, which provides a comprehensive installation configuration process, you can refer to the following links:

A Method of Quickly Installing InnoDB Cluster

Many people say that InnoDB Cluster's solution has yet to be tested into production practice, which is absolutely true, but in terms of direction, it has been a good supplement and improvement to the earlier solution. His three major components, in fact, MySQL Router is currently a short board, but once this short board does not become a bottleneck, with sharding and other functions, the impact on the MySQL open source community is far-reaching. So the solution can be improved, just as technology evolves. I agree with that sentence, there is no best plan, only the most appropriate plan.

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.