Cloud DB for MySQL overview
    • PDF

    Cloud DB for MySQL overview

    • PDF

    Article Summary

    The latest service changes have not yet been reflected in this content. We will update the content as soon as possible. Please refer to the Korean version for information on the latest updates.

    Available in Classic and VPC

    Cloud DB for MySQL is a fully managed database service using MySQL, which is the most widely used relational database in the world. It builds MySQL databases easily, stably operates through NAVER's optimization settings, and automatically recovers when a failure occurs.

    A variety of features Cloud DB for MySQL offers

    Please see below for detailed descriptions about the various features that Cloud DB for MySQL offers.

    • Quick and easy installation
      You can use the service right away after a few simple inputs and clicks.
    • Optimization settings verified by NAVER services
      MySQL settings that have been verified for a long time by NAVER services are provided by default for fast and stable operation without the need for additional configuration.
    • Automatic data backup and creation of MySQL server from backup data
      Data is automatically backed up once a day at the time designated by the customer, and data recovery is available by creating a new MySQL server with the backed up data.
    • Performance monitoring and notifications
      Various performance monitoring figures and graphs related to MySQL and operating system are provided.
    • Read load balancing
      Up to 10 slave server DBs can be replicated, and you can link them to the Load Balancer, as well as balance the database read load.
    • Automatic failover support
      If you use the high availability (HA) settings, then the server redundancy is configured with the master server and standby master server. If the master server fails, then it automatically fails over to the standby master server, enabling more stable operation of the server.

    About Cloud DB for MySQL guide

    The Cloud DB for MySQL guide consists of the following topics that will help you to effectively use Cloud DB for MySQL. The content that users can view in each topic is as follows.

    NAVER Cloud Platform provides a variety of related resources, as well as the guide to help customers better understand Cloud DB for MySQL. If you are a developer or marketer in need of detailed information while you are considering adopting Cloud DB for MySQL or establishing data related policies, then please make good use of the resources below.

    Please check FAQs first.

    You can get your questions answered quickly by referring to the answers in the FAQ before reading the guide. If you haven't found the answer to your question in the FAQ below, then search the guide for what you would like to know.

    Q. What is the difference between VPC and Classic environments?
    A. The Classic environment is a general cloud environment, while the VPC environment is a cloud environment that provides logically separated VPCs (Virtual Private Cloud).
    Through VPCs, you can implement an environment similar to the existing data center network your company was using. Up to 3 VPCs can be created for each account. Each VPC provides a network address space with a maximum netmask of 0.0.255.255/16 (65,536 IPs).

    Q. How do I access the MySQL Server I created?
    A. You can access by using a private domain in the NAVER Cloud Platform server, or access from outside of the cloud by using an SSL VPN or public domain.
    For descriptions on access methods using a private domain from the NAVER Cloud Platform server, refer to Getting started with Cloud DB for MySQL. For descriptions on access methods from outside of the cloud, refer to Access using SSL VPN and Access using public domain respectively.

    Q. How can I manage databases by directly accessing the MySQL Server rather than accessing through the application server?
    A. You can use the MySQL Workbench or phpMyAdmin to directly access MySQL Server for management.
    For more details about how to use each utility, refer to Accessing DB from outside cloud.

    Q. Can I start or stop individual MySQL Server like general servers?
    A. Individual start or stop of MySQL Server is not supported. You can only restart or delete them.
    Stopping an individual MySQL Server to temporarily prevent fees from incurring is not possible. If you perform a restart, then the virtual server where the MySQL Server is installed and the corresponding server are restarted at the same time.

    Q. When using the high availability settings, what is the difference between the master server and the standby master server?
    A. While the MySQL Server is being operated normally, the standby master server does not perform any roles and replicates the master server's data as it is. If the master server fails and can no longer be operated normally, then it automatically performs a failover where the standby master server takes over the role of the master server.

    Q. If I restart the master server, then does it automatically perform a failover?
    A. Failovers are automatically performed in case of failures, and they are not performed by the restart command of the user.

    Q. Can users directly perform failovers?
    A. Users can directly perform failovers. You can reproduce a failover situation caused by a master server failure to check any effects on applications prior to opening the service.
    The server access may not be available during the failover process. For detailed usage methods, refer to Master DB Failover of DB server.

    Q. The capacity has decreased after restarting MySQL Server. What should I do?
    A. The MySQL Server may increase the temporary tablespace storage size if you use long transactions, which may cause it to display a decreased capacity of MySQL Server.
    This is a normal behavior, and the temporary storage is terminated once the MySQL Server is restarted.

    Q. When monitoring the server through the Monitoring menu, the memory usage seems to continue to increase. Is there an issue in the server?
    A. For the performance improvement of the MySQL Server, the memory usage can increase to a value of innodb_buffer_pool_size or higher, but usage increase up to approximately 90% of the actual memory size is a normal behavior.

    Q. Regarding the performance or operating system of MySQL Server, is there a feature that enables the configuration of thresholds and notifies the admin of the events that occurred when they are exceeded?
    A. By default, Cloud DB for MySQL provides monitoring service and event collection service for the performance and operating system of the server.
    In addition, you can directly set thresholds and notifications via email or SMS for occurring events by linking with Cloud Insight. For detailed usage methods, please refer to Monitoring and Event.

    Q. The replication stopped due to a replication error. What should I do?
    A. Depending on the situation, you can temporarily skip the query where the error occurred by using the skip replication error feature. You can also try re-installing the DB where the replication error occurred.
    In case of a skip replication error, since it doesn't perfectly match the data consistency with the master server, the error can reoccur later and stop the replication again. In case of DB re-installation, it rebuilds the DB with the last backup copy, and matches the data consistency with the master server. It takes time to rebuild, and once the rebuild is complete, it holds the same data as the master server.
    For descriptions on skip replication error and DB re-installation, refer to Check replication status of DB server.

    Q. Why do replication delays occur?
    A. Replication delay is a phenomenon caused by the replication specifications of MySQL and the operation of the user application. It is not a failure of Cloud DB for MySQL. Generally, replication delay occurs when the master DB has a high write load, when a large number of write queries are received, when a single transaction is committed after a large number of changes, when a query that changes many rows in a table without a primary key is performed, when a query that requires a long execution time is received, and when it has to wait due to a lock.
    You can check queries that cause delays from Query timeline graph chart of Monitoring. Search the point in time where delays increase from the query timeline, or check the query timeline of the server that's being delayed.

    Q. What do I have to do to mitigate or resolve replication delays?
    A. When a delay occurs, you need to change the config value of innodb_flush_log_at_trx_commit, add a primary key to the table that doesn't have a primary key, since this causes the replication delay in the master DB, and then rebuild the standby master server.
    For descriptions and methods for changing the master DB's innodb_flush_log_at_trx_commit value, refer to the MySQL Guide and DB server's Manage DB config, respectively.
    There are two ways to rebuild the standby master after adding a primary key to a table that does not have a primary key in the master DB. Re-install from Check replication status, or remove and reset the high availability settings of the master server.

    Q. Can I link an external solution to use?
    A. You can link external solutions such as Zeroboard and gnuboard. You can specify the storage engine as InnoDB when installing to use them.
    You can use the MySQL installation-type service if a different storage engine is necessary.


    Was this article helpful?

    Changing your password will log you out immediately. Use the new password to log back in.
    First name must have atleast 2 characters. Numbers and special characters are not allowed.
    Last name must have atleast 1 characters. Numbers and special characters are not allowed.
    Enter a valid email
    Enter a valid password
    Your profile has been successfully updated.