Big talk about the love and hatred of MySQL

In the process of database development, the four orderly points of security-->stability-->efficiency-->low cost have been in the shadows. The latter is just empty talk when it leaves the former. On the evening of October 19th, MySQL released version 8.0.22. One of the new features (Automatic connection failover for Async Replication Channels) caught my attention and was also very interested. As a DBA veteran, I have mixed feelings. In the past 20 years, The failover function has always been dominated by the three-party step-by-step tool. It has been the pain of several generations of DBAs. The most popular database on the Internet has been criticized in this area. This feature has not been tested yet, no matter what, at least this part of the official finally started to solve it. In the dead of night, I sorted out my thoughts and summarized the development of MySQL products up to now. Basically, they develop in the following directions:
1. Master-slave synchronization: asynchronous synchronization to semi-synchronization, and then to enhance semi-synchronization, and then to Group replication; adopting the security strategy of synchronization to improve the efficiency of synchronization, and from single-threaded replication to parallel replication, dedicated to reducing the problem of master-slave delay, but the relative absolute delay of synchronization has accompanied the whole development process until now.
2. Performance optimization direction: multi-threaded, thread pool (supported by the enterprise version of the original version of MySQL, not supported by the community version); various logs are independent, as of version 8.0.22, the logs for ensuring security and problem records are basically independent. You can dynamically adjust parameters to individually control closing and opening; refactor the core engine Innodb, optimize various locks, independent locks, and optimize transaction operations. Various optimizations of a meal operation make the performance of the latest version of MySQL reach unprecedented heights.
3. The direction of multi-mode database: relational data, JSON semi-structured data, object data, memory type and full-text search engine, etc. multiple data engines, supporting OLTP business began to expand to OLAP business (Analytics Service supported on Oracle cloud) ), although only supported on its own cloud.
4. Learn from other database directions:The biggest reference is the ORACLE database. The various grammars and some usages are becoming more and more ORACLE; some functions of MongoDB are used for reference, such as related settings in MIC, automatic cloning of slave nodes, etc., but there are indeed some complex.
5. Intelligent operation and maintenance direction: support all kinds of online DDL, almost no perception of business, this lays a solid foundation for the future intelligent self-service dynamic optimization index; almost all key performance parameters support online modification; support persistent dynamic adjustment parameters, Ensure that the parameters after restart are the same as before restart; when MySQL is closed, the hot data in the memory can be persisted to the hard disk, and reloaded from the hard disk to the memory when starting, reducing the database preheating and quickly entering the previous wartime state after the database is restarted; SQL statement rewriting function, rewriting SQL without changing the business code; it can support automatic adjustment of some parameter configurations at startup according to the hardware configuration, although the parameters that can be automatically adjusted are limited, combined with the previous items, it is for the future MySQL in the intelligent parameters In terms of tuning and self-optimization, the development of autonomous databases has laid the foundation.
6. Improve security direction: A sound log ensures that no data is lost under various abnormal conditions. This is also the most basic requirement of the database. MySQL has been working hard to enhance and enhance it, and strive to build a financial-grade database; enhanced user authentication methods caching_sha2_password, strengthen the authentication mode, and increase the difficulty of brute force cracking of user authentication strings. But the biggest safety feature, failove, has never been.
7. Cost reduction direction: The progress of this route is a bit slow. At present, innodb compression has been exerted, and the compression ratio has been improved; efforts have been made to enhance the user experience and simplify the use and operation of labor costs, but some operations are compared Malformed, complicated operation configuration, such as the configuration of MySQL innodb cluster.
Although MySQL is well-loved by the people, the installed capacity is also very large, and it is also very good, but it still has many shortcomings :
1. Automatically create slave nodes:Group replication has just automatically added a new node, but all Binlog logs must be initialized to start the database (I feel that the product designing this solution is a little bit small), otherwise you need to use mysqldump to do it manually. So far, the operation of adding new nodes is still very troublesome. , It is still inconvenient, and the operation is still complicated. On the other hand, MongoDB is much simpler. Both the operation and the operation and maintenance cost are very low.
2. Failover: After more than 20 years of development, MySQL still relies on third-party tools for failover. The self-healing aspects of failure have been improved, but so far, it is not ideal. In fact, in MySQL JDBC, similar to MongoDB, it supports multi-database and multi-node configuration, but there is no automatic fault detection and switching function. This function has always been a decoration. The MySQL8.0.22 version finally supports failover switching. Looking at the configuration parameters, the operation is broken. It is estimated that this function of MongoDB is not a star. It is expected that the official will invest more manpower and material resources in this area, so that MySQL will end this original state of operation and improve the SLA and business unavailability time of operation and maintenance personnel.
3. Optimization of the drop table/database delete operation: At present, deleting large tables and libraries has a huge impact on database performance, and even the database can be dry.
4. Fake deletion or delayed deletion of database tables , make the database delete recycle bin, and customize regret medicine for the database.
5. MySQL's MySQL Innodb Cluster is currently a tasteless one , and it is estimated that it is not used by people. Router and shell components can be fully integrated into MySQL. The more components, the higher the cost of operation and maintenance. This management mode is not very good with middleware. , Can also be customized privately (after all, the cost of modifying the middleware is not as high as that of the MySQL source code), the configuration management is complicated, is it not good to match the MongoDB replication set?
6. Not doing business properly:Each product has its core competitiveness. The current products of MySQL have the suspicion of forgetting their original intentions (safe, stable, efficient, and low-cost). They spend too much time, want to do too many things, and want to refer to other database functions. , Can all database in MySQL work? Can you really unify the database?
Will the legendary MySQL storage and computing separation be officially supported?
The database storage and computing separation architecture has been very popular in the past two years. This is also a direction of database development. On the one hand, hardware technology advances, support elastic scaling, rational use of resources, and reduce costs. On the other hand, the business needs of high concurrent and large data volume. Especially at the moment when everything is a cloud, the emergence of this kind of architecture is indeed timely. If MySQL supports this architecture, it will inevitably have to make a lot of modifications to the MySQL-Innodb storage engine, and also have its own corresponding distributed file system. The current MySQL architecture may need a lot of adjustments. In order to further reduce the delay of master-slave synchronization, MySQL officials may support physical replication to optimize the delay problem. As for the separation of storage and computing, I personally feel that it will not be officially supported, at least in a short period of time. Maybe it will be supported in MySQL 13, because my Henan fellow Wang Shouyi said that thirteen incense ^-^
sets the advantages of multiple databases. Do not forget the original intention, the sea is the river, the tolerance is the big, I feel that MySQL is not tolerant and open enough. Many ready-made successful cases and program ideas can be used for reference. Besides, the official R&D personnel are also top-notch in the world. How can they learn? We don’t understand many things, we don’t know, we don’t dare to ask, who knows, maybe you wake up tomorrow and MySQL will make a gorgeous turn and run into the era of intelligent and autonomous databases with bridal makeup ?