One: Introduction
1. Background
1. For public cloud computing platforms, only the three major services of computing, network, and storage are often not enough. In the context of the current flourishing of Internet applications, almost all applications use databases, and databases often carry Apply the most core data. In addition, in the context of the growing popularity of big data analysis, reliable and convenient database management has become more important. Therefore, DBase as a Service (DBaaS, database service) has naturally become an important service for cloud computing platforms to create value for users.
2. Compare various data-related services in Amazon AWS. The most famous ones are RDS (SQL-base) and DynamoDB (NoSQL). In addition to basic data management capabilities, they also have good scalability, disaster tolerance, and Performance of different specifications. Therefore, for Openstack, the most popular open source cloud computing platform, DBaaS service has also been added from the Icehouse version, code-named Trove. Until the Openstack Liberty version released at the end of last year, Trove has been iteratively released in 4 versions, and it has become one of the official core services of Openstack. This article will introduce the principles, architecture and functions of Trove in depth, and demonstrate the application of Trove through practice.
2. Design goals
1. Trove is Database as a Service for OpenStack. It's designed to run entirely on OpenStack, with the goal of allowing users to quickly and easily utilize the features of a relational or non-relational database without the burden of handling complex administrative tasks. ” This is Trove's description of this project on the official homepage. There are two key points. One is from the product design, it is positioned not only for relational databases, but also covers non-relational database services. The other is from products In terms of implementation, it is completely based on Openstack.
2. From the first point, it can be seen that Trove has surpassed similar products in solving problems. Because we compare with other cloud computing platforms, relational and non-relational databases are provided by different services (such as AWS RDS and DynamoDB), and the implementation is often independent of each other system, not only UI is different, API It's not the same. The goal of Trove is to abstract as many things as possible, provide a unified UI and API externally, minimize redundant implementations, and improve platform cohesion. As long as it has the concepts of instance, database, user, configuration, backup, cluster, master-slave replication, whether it is a relational or non-relational database, it can be managed in a unified manner. With the release of the latest Liberty version, the current open source mainstream relational and non-relational databases are also supported, such as Mysql (including Percona and MariaDB branches), Postgresql, Redis, MongoDB, CouchDB, Cassandra, etc. However, according to the official introduction, currently only Mysql has been fully tested for production, and others are still in the experimental stage.
3. The second point is completely based on Openstack, which can be said to be a major innovation. Just imagine, suppose you are a cloud computing service provider. If you want to provide database services now, you only need to upgrade and configure on the original platform software. Nothing else is needed. You don’t need to purchase database server hardware or network planning. Need to plan IDC, what kind of feeling is this? Trove is completely built on top of the original basic services of Openstack. An analogy is similar to Google's famous Bigtable service, which is built on several basic services such as GFS, Borg, and Chubby. Therefore, Trove actually has some of the basic features of the cloud platform, such as disaster tolerance isolation, dynamic scheduling, and rapid response capabilities, and from the perspective of research and development, it also greatly reduces the phenomenon of re-creating wheels.
Three, basic concepts
1. Database instance (Instance): The openstack virtual machine that contains the database program. If the user creates a database instance, then he actually creates an openstack virtual machine and starts the database service on the virtual machine.
2. Datastore: used to represent and store the type, version, virtual machine image and other information of the database. When users create a database instance, they need to specify the Datastore.
3. Configuration Group: A collection of database parameters. Users can apply configuration groups to one or more database instances, thus avoiding a lot of repeated operations.
Four, characteristics
1. Obtain the database server "on demand", configure the obtained database server or database server cluster
2. Automatic operation, automatic addition, deletion, modification and preparation.
3. Better resource utilization, you can freely scale the database instance according to the business volume.
Two: Architecture
One, the core architecture
Second, detailed components
1. trove-api: It provides REST-style API for receiving and distributing operation requests. It also communicates with trove-conductor and trove-taskmanager. Some lightweight requests, such as obtaining instance status, number of instances, and other operations are all Process or access trove directly by itself. Trove-conductor and trove-taskmanager handle relatively heavyweight operations. For example, operations such as creating a database and creating a backup are passed to trove-taskmanager through rpc, and then completed by calling components such as nova, swift, neutron, and cinder.
2. trove-conductor: save the status information sent by trove-guestagent in vm to the database. The communication with trove-guestagent is realized through rpc. The purpose of trove-conductor is to avoid direct access to the created database instance The database is a middleware that writes yesterday into the database as a trove-guestagent.
3. Trove-taskmanager: To perform most of the complex operations in trove, the requester sends messages to trove-taskmanager, and trove-taskmanager calls the corresponding program to execute these requests in the context of the requester. taskmanager handles some operations, including instance creation and deletion, interaction with other services such as Nova, Cinder, Swift, etc., some more complex Trove operations such as replication and clustering, and management of the entire life cycle of the instance. trov-taskmanager is like other Openstak service clients, such as nova, swift, cinder, etc. When you want to create a database instance, it sends a request to nova, and lets nova create an instance. If you want to back up, call the swift interface to upload the backup .
4. trove-guestagent: integrated in the vm image, by monitoring the instructions sent by the task manager in the rpc, and executing the code locally to complete the database task, the taskmanager sends the message to the guest agent, and the guest agent executes these requests by calling the corresponding program .
Three, function
1. Dynamic resize capability: It is divided into instance-resize and volume-resize. The former mainly refers to the memory size and the number of CPU cores of the instance running, and the latter mainly refers to the size of the hard disk volume corresponding to the database partition. Since the instance runs on the vm, and the specifications of the vm's cpu and memory can be dynamically adjusted by Nova, the adjustment is very convenient and quick. In addition, the hard disk volume is also resized by the dynamic expansion function provided by Cinder. There will be a short interruption in the service during the resize process, which is caused by the restart of mysqld.
2. Full and incremental backup: In the current implementation of mysql, the backup is performed by the guestagent on the instance vm running the xtrabackup tool, and the files after the backup will be stored in the Swift object storage. The process of creating an instance from a backup is the opposite. Due to the powerful backup function of xtrabackup, all Trove has to do is to do some glue work.
3. Dynamic configuration update: currently supports custom configuration of the instance, you can create a configuration group that should be attached to a group of instances, and dynamically attach to the running instance to take effect.
4. One-click creation of one master and multiple slaves: In the API for creating database instances, it supports batch creation of multiple slave instances, and the designated instance is the master for synchronous replication. This facilitates the operation of creating multiple slave instances from an existing instance. And the synchronous replication after mysql5.6 version supports GTID binary log, which makes the establishment of the relationship between master and slave instances more reliable and flexible, and faster in failover processing.
5. Cluster creation and management (percona/mariadb support): The cluster function is currently not supported in the mysql native version, but its two branch versions, percona and mariadb, are supported based on the cluster replication technology implemented by the Galera library. In addition, the Liberty version of Trove also provides cluster support for mongodb.
Three: common operations
One, instance, database, database user management
2. Backup and cluster management
Create a database instance
When creating a database instance, you actually call nova-api through the trove-taskmanager create_instance() method , and then call the _get_injected_files method to inject guess_info and trave-guetagent.conf information into the database instance /etc/trove/conf.d/ . Provided to guest-agent for subsequent operations.
So the 4.0 version of trove does not need to encapsulate the trove-guestagent.conf configuration file in the mirror at the beginning. This configuration file is injected through nova, so the mirror only needs to configure where guest-agent reads this configuration file. The rest is left to the configuration file trove-guestagent guest_info_file.
[root@w-test01 conf.d]# cat guest_info.conf
[DEFAULT]
guest_id=7ec35639-5139-4ae4-8388-8101e41cc0f7 #This ID is the ID assigned to this instance by trove
datastore_manager=mysql #Which datastore is used
tenant_id=f2f0e038ff0342a3bc99d8971f829ac2 #which tenant is
When you enter the size of the cloud disk to be created in the console, you actually call the _create_volume method in taskmanager:
After collecting all the above information, then call nova to create a database instance:
Then the guest-agent in the database instance will read the trove-guestagent.conf injected through nova to connect to the rpc to read the operation request sent by the taskmanager.
The remaining operations such as creating a database and creating users are implemented by taskmanager calling guest-agent in the database instance.
Some implementations of guest-agent operations on mysql are included in /usr/lib/python2.7/dist-packages/trove/guestagent/datastore/mysql/service_base.py
def _get_actual_db_status() #Get the database instance status method
Mainly by calling /usr/bin/mysqladmin ping" and ps -C mysqld h to get the status of the database instance.
Judge whether mysql is shutdown by judging whether the pid file exists:
def create_database #Create database instance method:
def create_user #Create user and authorization method:
There are methods to delete the database, delete users, get binlog, start slave, and close slave later.
At the same time, it should be noted that when trove creates a database instance, it will create one for each database instance by default.
SecGroup-xxx xxx is the security group of the host ID.
Trove does not start the root user by default, so the user name in the console user tab cannot be filled in root.
It should be noted that all the above operations are performed by the trove user, so it must be confirmed that the trove user has sudo permissions, otherwise it will fail.
Before the completion of the above operations, the database status is still building, that is, the vm is starting, creating the database, creating users, authorizing users, synchronizing the my.cnf configuration file to the database instance, restarting mysql, and trove-guestagent sending rpc .
To trove-taskmanager, and finally check that the database runs successfully, send an Active status message to rpc. After trove-taskmanager receives the Active message, it will not send a database creation message, and trove-conductor will also go to the database after receiving the trove-guestagent Active message. Update the status of the trove instance in the trove list, and you can see the status of the instance Active in the trove list.
Backup and restore
Currently trove-guestagent only supports three backup methods of mysql, one is the traditional mysql Dump method, the other is InnoBackupEx, and the incremental backup method InnoBackup is InnoBackupExIncremental.
The backup program is placed in /usr/lib/python2.7/dist-packages/trove/guestagent/strategies/backup.
The calling method is also relatively simple, that is, whatever backup method is configured in trove-guestagent.conf, it calls the method in the specified class to execute the method, and the method also contains some software commands.
It should be noted that the default configuration is to call Innobackup, the backup log will be stored in the tmp directory, and after the backup is completed, it will be stored in swift by default.
The default backup folder in swift is database_backups, compression is enabled, ssl encryption, fragmentation, etc.
Call the save method in the SwiftStorage class to upload to Swift
Which will carry out the verification of the file.
There are actually two files that are backed up. The first enc file is mainly used for fragmentation, and the second file is the main backup file.
mysql master-slave
The trove-master side first backs up the current data to Swift--->then taskmanager re-creates a database instance------>The newly created database instance pulls the just backup from Swift according to the bin-log inside. GTID to restore---->Establish a master-slave relationship---detect the successful taskmanager to delete the backup uploaded to Swift.
A test will be done before the backup. If there is a backup before, the incremental backup method will be called to save space, and the full backup method will be called when it is detected.
Let's make a variable definition first, and define the variables for incremental backup and full backup:
if determines whether to call full backup or incremental backup.
Currently trove only supports mysql master-slave, not master-slave and asynchronous master-slave.
When creating a master-slave, creating a slave also calls the create_instance() method:
It's just a judgment here, if slave_of_id is passed, call the __create_replication_slave() method:
The __create_replication_slave() method will get the ID of the backup, and then continue to call nova to create the host.
The next operation will be handed over to the guest-agent in the database instance for operation.
The guest-agent will first download the backup file from Swift. Then restore. Next, establish the master-slave relationship. What I want to explain here is that trove has two ways to establish a master-slave relationship. One is the traditional bin-log form, and the other is in the form of GTID.
In /usr/lib/python2.7/dist-packages/trove/common/cfg.py
These are two different strategies defined:
At the same time, different methods are called to execute.
When your profile
replication_strategy = MysqlBinlogReplication
replication_namespace = trove.guestagent.strategies.replication.mysql_binlog
Calling is
/usr/lib/python2.7/dist-packages/trove/guestagent/strategies/replication/mysql_binlog.py
for
replication_strategy = MysqlGTIDReplication
replication_namespace = trove.guestagent.strategies.replication.mysql_gtid
Calling is
/usr/lib/python2.7/dist-packages/trove/guestagent/strategies/replication/mysql_gtid.py
What is the difference between these two files? The commands defined in the method are different:
Overview of GTID:
Global transaction identified: global transaction identifieds.
GTID things are globally unique, and one transaction corresponds to one GTID. A GTID is executed only once on a server to avoid repeated executions that may cause data confusion or inconsistent master and slave. GTID is used to replace the classic copy method, instead of using binlog+pos to start copying. Instead, use master_auto_postion=1 to automatically match GTID breakpoints for replication. MySQL-5.6.5 began to support, and MySQL-5.6.10 began to improve. On the traditional slave side, binlog does not need to be turned on, but in GTID, the binlog on the slave side must be turned on for the purpose of recording the executed GTID (mandatory).
Here is an introduction to mysql GTID:
The components of GTID:
The front is server_uuid: the back is a serial number
For example: server_uuid: sequence number
7800a22c-95ae-11e4-983d-080027de205a:10
UUID: The unique ID of each mysql instance. Since it will be passed to the slave, it can also be understood as the source ID.
Sequence number: Each MySQL server is a self-increasing sequence starting from 1, and a number corresponds to a transaction.
Advantages of GTID over traditional replication:
-
It is easier to implement failover, instead of looking for log_file and log_Pos as needed.
-
Easier to build master-slave replication.
-
It is safer than traditional copying.
GTID is continuous without holes, so when there is a data conflict between the master and slave libraries, you can skip it by adding empty things.
The working principle of GTID:
When the master updates the data, it will generate the GTID before the transaction and record it in the binlog. The i/o thread on the slave side writes the changed binlog to the local relay log. The sql thread obtains the GTID from the relay log, and then compares whether there is a record in the binlog on the slave side. If there is a record, it means that the GTID transaction has been executed and the slave will ignore it. If there is no record, the slave will execute the GTID transaction from the relay log and record it in the binlog. In the parsing process, it will be judged whether there is a primary key, if not, use a secondary index, if not, use a full scan.
Key points:
-
When the slave receives the master's binlog, it will check whether the master's GTID has been executed (a server can only execute it once).
-
In order to ensure the consistency of master-slave data, multiple threads can only execute one GTID at the same time.