Author: Gao riyao senior MySQL kernel R & D
This article comes from the author's speech "MySQL on K8s: open source and open MySQL high availability container arrangement scheme" at kubesphere & Friends 2021 Shanghai station.
MySQL is the most popular open source database in the world. It has been widely used in all walks of life before the container and K8s technology came out. This article will share some practices of MySQL containerization.
|What are the challenges of MySQL operation and maintenance?
The traditional physical deployment method is to deploy the database on the physical machine. For operation and maintenance personnel, they will encounter the challenges of the four dimensions in Figure 1.
1. Cost
For self built MySQL database cluster, the required hardware equipment includes: server, network switch, memory, CPU, hard disk and other hardware equipment.
The cost of hardware equipment includes: selection, purchase, maintenance, upgrading, damage, data loss, etc.
2. Traditional deployment
Each new cluster requires operating system installation, environment configuration, MySQL database installation, debugging, performance optimization and parameter adjustment, followed by system upgrade and database upgrade
3. Operation and maintenance
For different scenarios, such as one source and one copy, one source and two copies, multiple source and multiple copies (MGR), corresponding operation and maintenance scripts need to be written.
When the cluster is small and there are few MySQL instances, the operation and maintenance personnel can cope with it. However, when the cluster continues to increase and there are thousands of MySQL instances, the burden of operation and maintenance personnel will be greatly increased and the efficiency will become low.
The larger the scale, the higher the probability of misoperation, and even "run away from deleting the database". For ordinary enterprises, the ability to deal with the accidental deletion of key data is weak, and the harm is likely to be fatal.
4. Resource elasticity
Traditional physical machine deployment does not have the ability of second level elasticity to automatically scale MySQL resources during peak or trough. For example, expand CPU, memory and other resources during business peak, and recover idle resources during low peak period.
If the duration of an e-commerce spike is designed to be 30 minutes, we can maximize the network, CPU, memory, disk and other resources within 30 minutes. After the second kill, release these resources and greatly save costs.
Mainstream solutions
There are two mainstream solutions to the above challenges:
Physical machine + management platform
Through the database management platform, the unified management of the database can reduce the cost of database operation and maintenance and improve the overall availability of the database.
Upper cloud
Deploy the database to a virtual computing environment, which is often called database cloud. All major cloud manufacturers in the market provide RDS services.
The cloud on the database can realize the advantages of on-demand payment, on-demand expansion, high availability and storage consolidation. Greatly reduce the difficulty of large-scale deployment of operation and maintenance personnel and operation and maintenance database.
So, are there other solutions to these challenges? Next, let's introduce database containerization.
|Why database containerization?
According to the China Cloud native user survey report 2020 [1] released by CNCF cloud native industry alliance, more than 60% of Chinese enterprises have applied container technology in the production environment, of which 43% have used container technology in core production business.
Container technology
Docker was born
Fairly lightweight image standardized production
Make installation, deployment and delivery very efficient. It solves the problems of complex packaging of Pass service and inconsistent environment.
Lightweight Virtualization (rootfs/cgroup/namespace)
Contribute to resource sharing and degrade performance loss
De facto standard for Kubernetes container orchestration
Relying on the theoretical advantages of Google Borg project, it inherits the experience of Google's large-scale production environment. K8s provides a set of basic dependencies for building distributed systems based on containers. K8s has also become the de facto standard for container scheduling.
Operation and maintenance capability
Routing gateway, horizontal expansion, monitoring, backup, disaster recovery, etc.
Declarative API
Describe the containerized business and the relationship between containers.
Container orchestration
According to the wishes of users and the rules of the whole system, the relationships between containers can be handled completely and automatically.
By observing the urgent needs of users for container products when actually using mysql, we can see that the process of MySQL container is imperative. Take KubeSphere open source community [2] as an example. The most popular one in its app store is the highly available version of MySQL.
|Exploration of MySQL container
RadonDB MySQL is an open source, highly available and cloud native cluster solution based on MySQL. It supports one master multi slave high availability architecture, and has a full set of management functions such as security, automatic backup, monitoring alarm and automatic capacity expansion. At present, it has been used on a large scale in the production environment, including banking, insurance, traditional large enterprises and so on.
RadonDB MySQL Kubernetes[3] supports installation, deployment and management on Kubernetes and KubeSphere, and automatically performs tasks related to running RadonDB MySQL clusters. Service high availability is realized by Xenon, an open source MySQL Cluster High Availability tool.
Architecture diagram
Xenon in each Pod manages MySQL in the current Pod. It mainly obtains and saves the current status and obtains the replication status information of the current execution.
Helm version
The general package management tool templates K8s resources for easy sharing. It mainly solves the following problems:
- Deploy application resources and separate configuration;
- Manage its life cycle;
- MySQL upgrade and update;
- Deletion of resources.
Main functions:
- MySQL high availability
- Decentralized leader automatic election
- Master slave second switching
- Strong data consistency
- Cluster management
- Monitoring alarm
- Cluster log management
- Account management
KubeSphere application management
The echo information can be deployed by executing commands through the terminal.
$ xenoncli cluster status
+------------------------------------------------------+-------------------------------+--------+---------+--------------------------+---------------------+----------------+------------------------------------------------------+
| ID | Raft | Mysqld | Monitor | Backup | Mysql | IO/SQL_RUNNING | MyLeader |
+------------------------------------------------------+-------------------------------+--------+---------+--------------------------+---------------------+----------------+------------------------------------------------------+
| demo-radondb-mysql-0.demo-radondb-mysql.default:8801 | [ViewID:1 EpochID:2]@LEADER | UNKNOW | OFF | state:[NONE]
| [ALIVE] [READWRITE] | [true/true] | demo-radondb-mysql-0.demo-radondb-mysql.default:8801 |
| | | | | LastError: | | | |
+------------------------------------------------------+-------------------------------+--------+---------+--------------------------+---------------------+----------------+------------------------------------------------------+
| demo-radondb-mysql-1.demo-radondb-mysql.default:8801 | [ViewID:1 EpochID:2]@FOLLOWER | UNKNOW | OFF | state:[NONE]
| [ALIVE] [READONLY] | [true/true] | demo-radondb-mysql-0.demo-radondb-mysql.default:8801 |
| | | | | LastError: | | | |
+------------------------------------------------------+-------------------------------+--------+---------+--------------------------+---------------------+----------------+------------------------------------------------------+
| demo-radondb-mysql-2.demo-radondb-mysql.default:8801 | [ViewID:1 EpochID:2]@FOLLOWER | UNKNOW | OFF | state:[NONE]
| [ALIVE] [READONLY] | [true/true] | demo-radondb-mysql-0.demo-radondb-mysql.default:8801 |
| | | | | LastError: | | | |
+------------------------------------------------------+-------------------------------+--------+---------+--------------------------+---------------------+----------------+------------------------------------------------------+
$ xenoncli cluster gtid
+------------------------------------------------------+----------+-------+-------------------+--------------------+
| ID | Raft | Mysql | Executed_GTID_Set | Retrieved_GTID_Set |
+------------------------------------------------------+----------+-------+-------------------+--------------------+
| demo-radondb-mysql-1.demo-radondb-mysql.default:8801 | FOLLOWER | ALIVE | | |
+------------------------------------------------------+----------+-------+-------------------+--------------------+
| demo-radondb-mysql-2.demo-radondb-mysql.default:8801 | FOLLOWER | ALIVE | | |
+------------------------------------------------------+----------+-------+-------------------+--------------------+
| demo-radondb-mysql-0.demo-radondb-mysql.default:8801 | LEADER | ALIVE | | |
+------------------------------------------------------+----------+-------+-------------------+--------------------+| RoadMap
Operator version
The Operator version provides stateful services for specific scenarios and automatic management for complex applications. In addition to meeting the requirements of Helm version, it mainly solves the following problems:
- Listen to Kubernetes API and do corresponding processing in each life cycle of instance creation, scaling and death to ensure data continuity in stateful applications;
- Designated node cross machine room / remote disaster recovery, fixed IP, etc;
- The master-slave replication is abnormal or the replication delay exceeds the normal range, such as automatic positioning and automatic repair.
With the help of Operator framework and functional requirements for fine-grained manipulation applications.
[coming soon] main functions:
- Add / delete node
- Automatic expansion and contraction capacity
- Upgrade cluster
- Backup and recovery
- Automatic failover
- Automatically rebuild nodes
- Automatic restart service
- Account management (API interface provided)
- Online migration
- Automatic operation and maintenance
- Multi node role
- Disaster recovery cluster
- SSL transport encryption
- ......
I hope that students interested in database containerization will pay attention to RadonDB open source community, a cloud native and containerized database open source community!
[1]. 2020 China Cloud native survey report: https://www.cncf.io/blog/2021/04/28/cncf-cloud-native-survey-china-2020/
[2]. KubeSphere open source community: https://kubesphere.com.cn
[3]. RadonDB MySQL Kubernetes: https://github.com/radondb/radondb-mysql-kubernetes
About RadonDB
RadonDB open source community is a cloud oriented native and containerized database open source community. It provides database technology lovers with a technology sharing platform around mainstream open source databases (MySQL, PostgreSQL, Redis, MongoDB, ClickHouse, etc.), and provides enterprise level RadonDB open source products and services.
At present, RadonDB open source database series products have been approved by Everbright Bank, Shanghai Pudong Development Silicon Valley Bank, Hami bank, Taikang Insurance, Taiping Insurance, AXA, sunshine insurance, Centennial life insurance, Anji logistics, Anchang logistics, blue moon, Tiancai Shanglong, rockjiahua, Shengzhe technology, Wuxi huipao sports, Beijing Telecom, Jiangsu transportation holding, Sichuan Airlines, Kunming Airlines It is adopted by thousands of enterprises and community users such as state-controlled biology.
RadonDB can be delivered based on cloud platform and Kubernetes container platform. It not only provides database product solutions covering multiple scenarios, but also provides professional cluster management and automatic operation and maintenance capabilities. Its main functional features include: high availability master-slave switching, strong data consistency, read-write separation, one click installation and deployment, multi-dimensional index monitoring & alarm, elastic capacity expansion & capacity reduction Horizontal free expansion, automatic backup & recovery, multi activity in the same city, remote disaster recovery, etc. RadonDB only needs enterprise and community users to focus on business layer logic development, without paying attention to complex issues such as cluster high availability selection, management and operation and maintenance, so as to help enterprise and community users greatly improve the efficiency of business development and value innovation!
GitHub:
Wechat group: please search and add group assistant wechat radondb