Troubleshoot common issues

Available in Classic and VPC

You might run into the following problems when using Cloud DB for MySQL. Find out causes and possible solutions.

Individual start and stop of MySQL Server

Unable to start and stop MySQL Server individually.

Cause

Individual start or stop of MySQL Server is not supported. You can only restart or delete. You cannot stop an individual MySQL Server to temporarily avoid charges.

Solution

Only restart of delete MySQL Server. When restarting, the virtual server on which MySQL Server is installed and the server itself restart simultaneously.

MySQL Server connection error

Error occurs when accessing the MySQL Server.
Currently using SSL VPN but cannot connect to Cloud DB for MySQL.

Cause

You need to create an application server that will communicate with MySQL Server to access MySQL Server. Otherwise, Cloud DB for MySQL of NAVER Cloud Platform cannot be used normally.

Solution

Check the application server
A MySQL server created from Cloud DB MySQL is currently only accessible within NAVER Cloud Platform, so the applications server must also be created inside NAVER Cloud Platform. For the overall flow of server creation, check scenario and see Start guide by environment for each platform:

• Overall usage scenario
• Getting started with Cloud DB for MySQL (VPC)
• Getting started with Cloud DB for MySQL (Classic)

Check how to access the MySQL Server
To access MySQL Server from the NAVER Cloud Platform console:

• Access methods using Private domain from NAVER Cloud Platform server: Getting started with Cloud DB for MySQL
• Access methods from outside of the cloud: access using SSL VPN, access using public domain

Failover when restarting Master Server

Failover not executed when restarting Master Server.

Cause

Failover is automatically executed only in case of failures, not by user's restart command.

Solution

No action is required as it is not a failure.

Execute Failover

You need to reproduce a Master Server failover situation prior to service launch to proactively verify that applications remain unaffected during such incidents.

Solution

Too learn how to execute failover, see Master DB failover. You may not be able to access the server during the failover.

Deleted data recovery

Recovery of deleted data is needed.

Cause

You cannot recover them because deleting server resources deletes all data.

Solution

The data can't be recovered once it's deleted. Upload backup data to Object Storage before deleting the server and keep it for a period of time before returning it. For restoring from a backup uploaded to Object Storage, see restoring backup files with Xtrabackup.

Create database

Direct database creation is needed.

Cause

To prevent problems caused by misuse of permissions, we do not grant users the permission to create database directly.

Solution

You can create a DB in one of the 3 ways below. When creating database, an account with DDL permissions will have full control over the created database:

• Create a database via the console
• Create a database using Store Procedure
• Create a database using Cloud DB for MySQL API

Notifications on exceeding MySQL Server threshold

Unable to receive an event notification on exceeding MySQL Server threshold.

Cause

Cloud DB for MySQL provides monitoring service and event collection service for the performance and operating system of the server. You can directly set thresholds by integrating with Cloud Insight. If there's an error between Cloud Insight integrations and custom config value, notification may not be sent normally.

Solution

The monitoring results and event collection results of Cloud DB for MySQL can be integrated with Cloud Insight to get notifications through email or SNS. For detailed usage, see below information by environment for each platform:

• VPC environment: Monitoring, Event
• Classic: Monitoring, Event

Replication error

Replication error occurs and replication stopped.

Cause

Depending on the situation, a variety of causes may exist. For more information, check the solution.

Solution

• Click [Skip replication error] and temporarily skip the query with error. In this case, it may not guarantee the perfect alignment with Master Server's data, potentially leading to recurring errors and further replication stops.
• Reinstall the DB where the replication error has occurred. In this case, it rebuilds DB with the last backup copy and matches the data consistency with Master Server. Rebuilding takes time, but once the process is complete, the server will have the same data as Master Server.
  For more information on skip replication error feature and DB reinstallation, see check replication status.

Mitigate Replication delay

Replication delay occurs.

Cause

Replication delay is not a failure of Cloud DB for MySQL but rather a result caused by the replication specifications of MySQL and the behavior of user applications.
Replication delay occurs in the following situations:

• High write loads on the master DB
• Large amount of write queries
• Many change tasks committed in a single transaction
• Performing queries that modify many rows in tables without primary key
• Large volume of queries requiring prolonged execution
• Waiting due to locks

You can identify queries causing delays in the query timeline graph chart of monitoring. Search query timeline for when the delay increases, or check query timeline and view binary logs being executed for the server that is experiencing the delay.

Solution

If replication delays occur, change the innodb_flush_log_at_trx_commit Config value and add a primary key to tables without one, which may be causing replication delays on the master DB, before rebuilding the standby Master Server.

• For more information on the innodb_flush_log_at_trx_commit value of the master DB and how to change it, see MySQL guide and DB server's DB Config management.
• There are two ways to rebuild standby master after adding primary key to a table that does not have one in master DB:
  • Reinstall from check replication status.
  • Disable high availability setting on Master Server and reinstall.

mysqldump utility error

An error occurs when performing a backup or restore using the mysqldump utility.

Cause

Cloud DB for MySQL is a fully managed service and does not grant all privileges.

Solution

• When performing backup using the mysqldump utility, you must add the appropriate options. For more information, see backing up with mysqldump.
• When restoring using the mysqldump utility, you must remove any unsupported statements. For more information, see restoring backup file with mysqldump.

Unknown status

In the Cloud DB for MySQL console, the status of the DB Server is displayed as unknown.

Cause

• If the collection of monitoring metrics is delayed or fails due to an excessive load on the DB Server, the status of the corresponding master or Slave Server is displayed as unknown.
• If replication has been in the stop state for more than 1 hour, the Standby Master Server's status is displayed as unknown.
• The status of the Standby Master Server is displayed as unknown if replication delay (Seconds_Behind_Master) has accumulated for more than 1 hour.

Solution

• If the status of either the master or Slave Server is unknown, use SHOW PROCESSLIST or performance schema to identify and tune the queries causing the load to alleviate the server's load.
• If the status of the Standby Master Server is unknown, reinstall it and analyze why replication is down or delayed.
  • Check if a large number of DML queries or long transactions were performed on the write Master Server and take steps to prevent it from happening again.
  • When the status of the Standby Master Server is unknown, the automatic failover function is limited when the master DB fails to prevent data loss. Take action as soon as possible to ensure optimal HA performance.

Unsupported engine table creation restriction

Tables using the MyISAM, BLACKHOLE, FEDERATED, ARCHIVE, or MEMORY engine cannot be created.

Cause

Cloud DB for MySQL does not support the following table engines:

• MyISAM, BLACKHOLE, FEDERATED, ARCHIVE, MEMORY
• These engines are restricted due to lack of transaction support, insufficient data consistency, and limitations in replication and failover in cloud environments.

Solution

Use the InnoDB engine when creating new tables.

Check current table engine

SELECT TABLE_SCHEMA, TABLE_NAME, ENGINE 
FROM information_schema.TABLES 
WHERE ENGINE IN ('MyISAM','BLACKHOLE','FEDERATED','ARCHIVE','MEMORY')
    AND TABLE_SCHEMA NOT IN ('information_schema','mysql','performance_schema','sys');

Change current table engine

ALTER TABLE table_name ENGINE = InnoDB;

Error notifications in the console

The following error notifications occur in the console.

• CASE 1: MySQL replication is in a delayed state. Please try again after all delays have been resolved.
• CASE 2: Master DB failover cannot be performed due to unstable communication with the DB server. Try again after a short while.
• CASE 3: Work cannot be performed before or after the backup time. To proceed with the work, please adjust the backup time.
• CASE 4: Backup is in progress. Proceed with the work after the backup has been completed. The backup duration increases in proportion to the size of user data.

Cause and solution

CASE 1

• Cause

  • A stop or replication delay has occurred due to a replication error.
  • It is the day of using DMS (Database Migration Service).

• Solution

  • In the event of a replication error or delay, please reinstall the standby master or resolve the replication delay before retrying.
  • If it is the day of using DMS, please reinstall the standby master and then retry.

CASE 2

• Cause

  • The HA monitor is not running properly.

• Solution

  • Since this may be a temporary phenomenon, please try again after a short while. If the same popup is displayed for an extended period, please contact customer support.

CASE 3

• Cause

  • Some operations are restricted during the backup period.

• Solution

  • In the [DB Server] > [DB Status] > [Manage Backup Settings] tab menu, adjust the backup time before proceeding with the work.

CASE 4

• Cause

  • A backup is in progress on the standby master.

• Solution

  • Please retry the work after the backup is completed. The backup duration may vary depending on the size of the data.