Functions

Billing

TaurusDB provides three billing modes, yearly/monthly, pay-per-use, and serverless billing, to meet your requirements in different scenarios.

After purchasing a DB instance, you can change the billing mode when necessary. You can change the billing mode from pay-per-use to yearly/monthly or from yearly/monthly to pay-per-use.

Connecting to a DB Instance

You can connect to a DB instance through a MySQL command-line interface (CLI), graphical user interface (GUI), Java database connectivity (JDBC), or Data Admin Service (DAS). For details about the differences among them, see Connection Methods.

Configuring Security Group Rules

You can configure security group rules to allow specific IP addresses to access your DB instances. The default security group rule allows all outgoing data packets. ECSs and DB instances can access each other if they are in the same security group. After a security group is created, you can configure security group rules to control access from and to the DB instances in the security group.

For more information, see Configuring Security Group Rules.

Migrating Data

You can migrate data from RDS for MySQL, self-managed MySQL, other cloud MySQL, and self-managed Oracle databases to TaurusDB, or from one TaurusDB instance to another.

For details about different migration schemes, see Data Migration Schemes.

For details about how to migrate data, see Migrating Data to TaurusDB Using mysqldump, Migrating Data to TaurusDB Using the Export and Import Functions of DAS, and Migrating Data to TaurusDB Enterprise Edition.

Database Proxy

Database Proxy is a network proxy service that sits between TaurusDB and applications. It is used to handle all requests from the applications to access TaurusDB instances.

Read/write splitting enables read and write requests to be automatically routed through a database proxy address. After creating a TaurusDB instance, you can create a proxy instance. With the proxy address, write requests are automatically forwarded to the primary node and read requests are forwarded to each node based on the routing policy of the proxy instance, offloading the read load from the primary node.

For more information, see What Is Database Proxy?

Serverless Instances

Serverless instances use a write once read many (WORM) architecture and shared storage. They provide the ability to dynamically scale with system workloads. Each instance node can vertically scale CPUs and memory in seconds and horizontally scale read replicas. It means that compute can quickly and independently adapt to the peaks and troughs, achieving high cost-effectiveness.

For more information, see What Is a Serverless Instance?

Backups and Restorations

TaurusDB lets you back up and restore your instances to ensure data reliability. You can restore data to:

• A new DB instance, the original DB instance, or an existing DB instance using an automated or manual backup.
• A specified point in time. It is instance-level data restoration. Data can be resorted to a new DB instance, the original DB instance, or an existing DB instance.

For more information, see Data Backups and Data Restorations.

Read Replicas

In read-intensive scenarios, a single DB instance may be unable to handle the read pressure and workloads may be affected. To offload read pressure from the primary node, you can create one or more read replicas. These read replicas can process a large number of read requests and increase application throughput. To do this, connection addresses need to be scheduled separately for the primary node and each read replica on your applications so that all read requests can be sent to read replicas and write requests to the primary node.

There are synchronous and asynchronous read replicas.

• Synchronous read replicas: Their failover priority is 1 and specifications are the same as those of the primary node. To avoid failover failures caused by inconsistent specifications between the primary node and read replicas, a cluster instance must have a synchronous read replica, and a multi-AZ instance must have a synchronous read replica in a different AZ from the primary node.
• Asynchronous read replicas: Their failover priority is not 1, or their specifications are different from those of the primary node.

For more information, see Introducing Read Replicas.

DBA Assistant

DBA Assistant provides visualized database O&M and intelligent diagnosis for developers and database administrators (DBAs), making database O&M easy and efficient. By analyzing alarms, resource usage, health status, performance metrics, storage usage, and slow query logs, it helps you quickly locate faults and keep track of instance statuses.

For more information, see What Is DBA Assistant?

Parameter Templates

You can use database parameter templates to manage DB engine configurations. A database parameter template acts as a container for engine configuration values that can be applied to one or more DB instances.

When you create a DB instance, you can select the default parameter template (Default-TaurusDB V2.0), the high-performance parameter template (Default-TaurusDB V2.0-High Performance), or a custom parameter template in the current region.

• Default-TaurusDB V2.0 contains DB engine defaults and system defaults that are configured based on the engine, compute class, and allocated storage space of an instance. Parameter values in the default template cannot be changed, but you can create a custom template with whatever values you require.
• Default-TaurusDB V2.0-High Performance is a set of optimized configuration parameters that aim to enhance the performance and reliability of database servers. The parameter settings in the template can be adjusted based on different application scenarios and hardware configurations.
• You can select a custom parameter template and change the parameter values as required. The changes to parameter values in a custom parameter template are not applied to your instance until you apply the template to the instance. For details, see Applying a Parameter Template.

Logs

TaurusDB supports the following types of logs:

• Error logs

  Error logs contain logs generated while a database is running, including error messages and slow SQL query statements. For details, see Managing Error Logs of a DB Instance.

• Slow query logs

  Slow query logs record statements that exceed the long_query_time value (10s by default). You are advised to set it to 1s. For details, see Managing Slow Query Logs of a DB Instance.

• Audit logs

  If you enable the SQL audit function, all SQL operations will be logged for your download and query.

  By default, SQL audit is disabled. Enabling this function may affect database performance. For details, see Enabling SQL Audit.

• Binlogs

  Binlogs record all DDL and DML statements (except data query statements). You can download binlogs to a local PC for further analysis. Binlogs are stored in OBS buckets. For details, see Querying and Downloading Binlogs.