[Tencent Cloud TDSQL-C Serverless Product Experience] Database Killer in the New Era

[Tencent Cloud TDSQL-C Serverless Product Experience] Database Killer in the New Era

overview

In recent years, with the rapid development of the Internet industry, relational databases are also facing unprecedented challenges. Cloud native database has become one of the important solutions to solve these challenges. The version launched by Tencent Cloud TDSQL-C Serverlessis one of the leaders in the field of cloud native databases.

In the process of "learning" at CSDN, I discovered that Tencent Cloud and CSDN launched the "Tencent Cloud TDSQL-C Product Evaluation Activity". In order to better understand TDSQL-C Serverlessthis product, I immediately applied for TDSQL-C Serverlessa database experience quota and successfully passed the manual. A cluster was constructed based on the guidelines as CMSthe basic support for this development.

Overall experience process

TDSQL-C ServerlessFirst, I had a first experience with the version according to the activity manual , and then I built a LightCMSservice by creating a version. I seamlessly migrated the database Weboriginally running on my server to the version. It is indeed fully compatible with the protocol, and then it can be used without writing and reading. When data is retrieved, the system automatically stops the database service. Once data is accessed, the system can automatically expand the database instance in milliseconds, which not only ensures application response speed, but also verifies the characteristics of .Mysql5.7TDSQL-CMySQLserverless

Our company's system belongs to the e-commerce industry and is a system that complies with the 80% principle (that is, 80% is reading and 20% is writing), so I can TDSQL-C Serverlesseasily achieve separation of reading and writing. This is why this product is a Cluster products can link other instances through read-write groups. In this way, the load of the system can be greatly reduced, and the system is still billed on a pay-per-use basis.

Through this initial experience, I also deeply felt the advantages of TDSQL-C Serverlessthe version in terms of automatic flexibility , compatibility , and high availability . Next, I will put my entire experience process below. If there is anything wrong, I hope everyone will correct it.

1. Set up the project environment

1.1. Create TDSQL-C Serverless

We choose serverlessthe version because my original database is the same mysql, so I also chose it here for better migration. mysql5.7At the same time, it also supports overseas regions. If you have overseas projects, you can also choose this product.

Let’s first buy a cluster. What’s very interesting here is why buying a database is called a cluster? Everyone will know after seeing it!
Insert image description here

Insert image description here
Insert image description hereAfter purchasing immediately, you will see a status of being created.
Insert image description hereThen we can open the public network access and it will be in the following status.

Insert image description here

1.2. Create cms database

Here TDSQL-C comes with its own web management tool. Log in to the cluster through DMC to see
Insert image description here
Insert image description herea new cmsdatabase .

Insert image description here
In this way, our database is basically set up. Isn’t it much more convenient than building it ourselves?

1.3. Build LightCms

What we are going to use is laravelthe development framework LightCms. Here I use version 8.x. The warehouse address is as follows:https://github.com/eddy8/LightCMS.git

Insert image description here

git clone https://github.com/eddy8/LightCMS.git
cd LightCMS
composer install

Then configure .envthe file and tdsql-cconfigure the database into it

Insert image description hereRun migration files and initial data

php artisan migrate --seed

Then configure nginx and you can access it normally.

server {
    listen 80;
    server_name light.com;
    root /data/www/lightCMS/public;
    index index.php index.html index.htm;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location ~ \.php$ {
        fastcgi_pass 127.0.0.1:9000;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        #不同配置对应不同的环境配置文件。比如此处应用会加载.env.pro文件,默认不配置会加载.env文件。此处可根据项目需要自行配制。
        #fastcgi_param   APP_ENV pro;
        include fastcgi_params;
    }
}

Insert image description here

2. Experience automatic start and stop

2.1 What is automatic start and stop?

As we all know, relational databases generally require us to manually configure and manage the database server. For example, you need to purchase server configuration in advance, and then open and close the database according to business conditions. If the number of visits is high, you need to upgrade the configuration. If the number of visits is low, you need to proactively stop the service to save money. This brings us a lot of management workload.

But TDSQL-C Serverlessthe version is different, it supports automatic start and stop function. How to understand this? We only need to use the database normally to complete read and write operations, and it can automatically sense the level of access internally. When the traffic is high, it will automatically add more computing and storage resources to us to ensure that the operation speed is not affected. And if the number of visits becomes low, it will also actively recycle some resources to help us save money.

Just like an elevator, we can ride it by pressing the floor button, and the elevator door will automatically open and close inside. We don’t need to consider the specific operational details of the elevator. The automatic start and stop function of the TDSQL-C Serverless version is this intelligent "on-demand" operation mechanism.

2.2 Automatic start and stop test

Let’s first add an article in the background

Insert image description here
Insert image description hereNow it is normal to obtain the article data display from the database, and then we can manually pause the database, or we can also wait for it to be idle for a period of time and automatically pause it.

Insert image description hereInsert image description hereNow the database is in a suspended state, and then we refresh our article to see what the running status of the database and program is:

Insert image description hereInsert image description here

After I refreshed, it still ran as stably as before, and the database started automatically. I didn't feel at all that the data had stopped and was not running during the period. It felt like it was truly pay-as-you-go. If there was no traffic, we didn't have to pay extra. Got it

It feels very good for our test programs or those segmented traffic, because many times the database can actually be in a suspended state.

3. Experience the read-write separation architecture

As mentioned before, our company's projects will use read-write separation, so this time I specially came to see how the read-write separation of TDsql-C serverless is? Can the company purchase one?

3.1. Create a read-only instance

In the cluster details, you can choose to add a read-only instance

Insert image description hereThen you can choose the number of read-only groups and ccuthe status of the read-only server. This can be configured and scheduled based on the traffic we usually read in the project. It is also elastically scalable.
Insert image description hereHere you can see our read-write instances and read-only instances. At the same time We also enable public network access for read-only instances.

Insert image description here
Then in the program, we import all the query traffic to the read-only node. There are some things to note about this read-only instance, which is different from our usual read-only instances:

  • Read-only instances and read-write instances share the same storage, and there is no need to maintain accounts and databases.
  • Read-only instances do not need binlogto be synchronized with read-write instances, and there is no need to copy and relocate data. It usually only takes seconds to create a read-only instance.
  • Read-only instance specifications may be different from read-write instances, but in order to facilitate users to adjust the configuration according to load conditions, it is recommended that the specifications of each read-only instance be consistent.

3.2. Distribute article list and article details traffic to read-only groups

Because most of the system queries are article details and article lists, we will not query the read and write instances here. The read and write instances can be used to write data.

3.2.1. Configure read-only group in .env
DB_READ_HOST=gz-cynosdbmysql-grp-mq7d6y1f.sql.tencentcdb.com
DB_READ_PORT=20229
DB_READ_USERNAME=root
DB_READ_PASSWORD=Qwerabc.
3.2.2. Configure read and write separation in config/database.php
        'mysql' => [
            'read' => [
                'host' => env('DB_READ_HOST', ''),
                'username' => env('DB_READ_USERNAME', ''),
                'password' => env('DB_READ_PASSWORD', ''),
                'port' => env('DB_READ_PORT', '3306'),
                'database' => env('DB_DATABASE', 'forge'),
            ],
            'write' => [
                'host' => env('DB_HOST', '127.0.0.1'),
                'port' => env('DB_PORT', '3306'),
                'database' => env('DB_DATABASE', 'forge'),
                'username' => env('DB_USERNAME', 'forge'),
                'password' => env('DB_PASSWORD', ''),
            ],
            'driver' => 'mysql',
            'host' => env('DB_HOST', '127.0.0.1'),
            'port' => env('DB_PORT', '3306'),
            'database' => env('DB_DATABASE', 'forge'),
            'username' => env('DB_USERNAME', 'forge'),
            'password' => env('DB_PASSWORD', ''),
            'unix_socket' => env('DB_SOCKET', ''),
            'charset' => 'utf8mb4',
            'collation' => 'utf8mb4_unicode_ci',
            'prefix' => '',
            'strict' => true,
            'engine' => null,
        ],
3.2.3. The content controller forwards traffic to the read instance Front/HomeController.php
    public function content($entityId)
    {
    
    
        $entity = Entity::query()->External()->findOrFail($entityId);

        ContentRepository::setTable($entity->table_name);
        ContentRepository::model()::on('mysql::read');
        $contents = ContentRepository::paginate();

        return view('front.content.list', compact('entity', 'contents'));
    }

Insert image description here

3.2.4. Start jmeter to construct the thread group

Here we also simply construct 30 threads to loop 100 times.

Insert image description here
Insert image description here

3.2.5. Observe the performance status of read and write instances

This is a read-write server. You can see that even if the thread is up, it will have no impact on the CPU and memory, because no request is forwarded to it at all. At the same time,
Insert image description herewe look at this read-only instance. When we start testing, the CPU and memory have been It has started to be pulled up
Insert image description here
. You can actually see here that TDSQL-C Serverlessthe separation of access and read and write is still very simple. So what if our traffic is very large and one read-only instance is not enough? Don’t worry, TDSQL-Cit has been handled for us. We don’t need to do logical shunting in the code, but open a read-only group, and the read-only group address will uniformly balance the shunting.

3.3. Create read-only group shunt

Insert image description hereThen we purchase a read-only instance and click this to adjust the configuration

Insert image description here
Select read-only node 2

Insert image description hereThe external network address is not enabled by default here. The other external network address can also be closed. Because we have enabled the read-only group, all our read-only traffic can be managed by the read-only group. Change the configuration to read-only
Insert image description here. Group configuration
Insert image description here
At the same time, we still use jmeterthe same thread for testing, 30 threads and 100 times to see if the pressure of the read-only instance has been shared. At present, after the test script is stopped, the CPU of the read-only server also decreases.

Insert image description here
A read-only server uses up to 8%CPU, see the picture below

Insert image description hereThe two read-only instances are automatically split through the read-only group. From this chart, we can also see that it is a balanced distribution.
Insert image description here

Summarize

This experience process is like this. At the same time, it also answers why this database creates a cluster instead of an instance. In fact, it is not difficult to find through our experience process that the whole process is not just an instance, it can also be linked to read and write instances for pressure TDSQL-C Serverless. Sharing is no longer within the capabilities of ordinary database instances. As a developer, I am very fortunate to have participated in this event and felt serverlessthe charm of the product. Through the practical TDSQL-C Serverlessversion, I have also accumulated more experience in using cloud native databases. At the same time, I can also provide my own advantages and opinions on various aspects of the product through evaluation. I hope this article can bring you some help!

Guess you like

Origin blog.csdn.net/hacks8/article/details/133124317