Available in VPC
In Backup, you can check the backup information configured per server for safe storage of data for users using Cloud DB for MySQL. Also, when the data is damaged due to a failure, you can perform restoration using the backup file that was in storage. In addition to servers using high availability settings, you can also use the backup and restoration features for Stand Alone Server. However, point-in-time recovery is not supported for Stand Alone Servers.
To use the backup and restoration, it is recommended to first understand the basic execution rules for the backup provided by Cloud DB for MySQL. The basic backup execution rules are as follows:
- Backup execution methods
- Performed daily, once a day.
- Select between automatic settings and user-defined settings.
- Automatic settings: Random time is specified when a MySQL Server is created, and the backup is performed at a time similar to the time of the first backup.
- User-defined settings: Backup starts within 15 minutes after the user-selected time.
- Exceptional situations
- Backup is performed within 30 minutes from the DB creation.
- When DB settings change, the backup is performed up to 5 minutes after the user-defined backup time.
- Backup file
- Retention period: Can be retained for up to 30 days based on user settings.
- Storage location: Stored in separate data storage (storage contracts depend on backup file size).
Backup interface
The basics of using backups are as follows:

| Component | Description |
|---|---|
| ① Menu name | Current menu name. |
| ② Basic features | Check details for Cloud DB for MySQL, refresh the Backup interface. |
| ③ Backup list | Configured backup settings per server and settings information. |
Check backup settings list
You can check the backup settings list per MySQL Server in operation. To view the backup settings list:
- In the VPC environment of the NAVER Cloud Platform console, navigate to Menu > Services > Database > Cloud DB for MySQL.
- Click the Backup menu.
- When the backup settings list appears, check the required information.
- DB Service name: DB Service name specified by user.
- Backup retention date: Maximum number of days for the backup file to be stored in data storage.
- Backup start time: Time at which the backup is performed once a day.
- Backup data size: Size of the completed backup file.
- Latest backup date: Date for the latest backup that was performed.
- View details: Details and restoration of the backup file list created per server, saved to Object Storage.
Check backup file list per server
To check the backup file list created for each server after completing the backup:
- In the VPC environment of the NAVER Cloud Platform console, navigate to Menu > Services > Database > Cloud DB for MySQL.
- Click the Backup menu.
- Click [Details] from View details of the backup settings row you want to check the details for.
- Check the details for the backup file.
- Backup date: Date that the backup was performed.
- Backup start time: Time when the backup was started.
- Backup completion time: Time when the backup was completed.
- Elapsed time: Time it took for the backup to be completed.
- Backup size: Size of the created backup file upon completion of backup (MB).
- Data storage: Size of the MySQL Server data storage.
Restore data from console
Cloud DB for MySQL provides a service that enables you to restore lost data using backup files, and easily and quickly create a MySQL Server. Also, you can restore the data up to the desired time within the available range of restoration using the point-in-time recovery feature.
Restore backup file
You can restore data using the backup file created through automatic backup.
To restore data using the created backup file:
- In the VPC environment of the NAVER Cloud Platform console, navigate to Menu > Services > Database > Cloud DB for MySQL.
- Click the Backup menu.
- Click [Details] in the backup settings row you want to restore.
- Select the backup file and click [Restore backup file].
- When the Restore backup file popup appears, check or enter the required information for restoration.
- Backup time: Range of time available for restoration (up to 7 days).
- Backup completion time: Point in time to restore to.
- Private Sub domain (VPC environment): The Private Sub domain to be used on the server to be restored (cannot select).
- DB Server type: MySQL Server type to restore.
- DB Server name: MySQL Server name to restore.
- Create as a new DB service: Create the server you want to restore as a new DB service.
- DB Service name: New DB Service name.
- High availability: Create it as a high availability configuration when creating a new service.
- Multi Zone: Create the Standby Master Server and Master Server in different availability zones.
- Subnet: Master Subnet and the subnet of another availability zone.
- Data storage type: The type of data storage to restore.
- Click [Restore] or [Create].
- Click [OK].
- Click the DB Server menu.
- Check the status of the server restoration.
- Created as Recovery type.
- Creating: Status in which the MySQL Server is being created (restoration) with the information you entered.
- Configuring: Status in which the MySQL Server is being configured after being created (restoration) with the information you entered.
- Running: Status in which the creation (restoration) and configuration of the MySQL Server have been completed with the information you entered, and access to the MySQL Server from the application server is available.
The completion of the server restoration may take several minutes.
Point-in-time recovery
You can restore data to a desired point in time. You can restore up to the desired minute within the range available for restoration.
To restore data using the point-in-time recovery feature:
However, point-in-time recovery is not supported for Stand Alone type servers.
- In the VPC environment of the NAVER Cloud Platform console, navigate to Menu > Services > Database > Cloud DB for MySQL.
- Click the Backup menu.
- Click [Details] in the backup settings row you want to restore.
- Click [Point-in-time recovery].

- When the Point-in-time recovery popup appears, check or enter the required information for restoration.
- Available DB restoration time: Time specified in the binlog_expire_logs_seconds setting.
- DB restoration time: Point in time to restore to.
- Private Sub domain (VPC environment): The Private Sub domain to be used on the server to be restored (cannot select).
- DB Server type: MySQL Server type to restore.
- DB Server name: MySQL Server name to restore.
- Create as a new DB service: Create the server you want to restore as a new DB service.
- DB Service name: New DB Service name.
- High availability: Create it as a high availability configuration when creating a new service.
- Multi Zone: Create the Standby Master Server and Master Server in different availability zones.
- Subnet: Subnet information of MySQL Server to restore.
- Data storage type: The type of data storage to restore.
- Click [Restore] or [Create].
- Click [OK].
- Click the DB Server menu.
- Check the status of the server restoration.
- Created as Recovery type.
- Creating: Status in which the MySQL Server is being created (restoration) with the information you entered.
- Configuring: Status in which the MySQL Server is being configured after being created (restoration) with the information you entered.
- Running: Status in which the creation (restoration) and configuration of the MySQL Server have been completed with the information you entered, and access to the MySQL Server from the application server is available.
The completion of the server restoration may take several minutes.
Create a new DB Service using restored server
You can create a new DB Service based on the Recovery Server created through the restoration feature and change the server to a Stand Alone or high availability configuration server. The specifications, DB settings, and backup times for the server are retained. When restoring a server whose backup time is not specifically set, the retention period is set as 1 day.
The Recovery Server with encrypted data storage can only create DB Service of high availability configuration.
- In the VPC environment of the NAVER Cloud Platform console, navigate to Menu > Services > Database > Cloud DB for MySQL.
- Click the DB Server menu.
- Click the Recovery Server you want to create a new DB Service from and click [Manage DB].
- Click [Create new DB Service].
- When the Create new DB Service popup appears, select whether to support high availability, enter the DB Service name, and click [Yes].

- Check the status of the server being created.
- Creating: Status in which the MySQL Server is being created with the information you entered.
- Configuring: Status in which the MySQL Server is being configured after being creating with the information you entered.
- Running: Status in which the creation and configuration of the MySQL Server has been completed with the information you entered, and access to the MySQL Server from the application server is available.
Store in Object Storage
In Cloud DB for MySQL, you can store the created backup file to Object Storage to use for backup. To save a stored backup file to Object Storage:
- Additional fees apply when you subscribe to Object Storage. For more information about Object Storage and pricing plan, see Services > Storage > Object Storage on the NAVER Cloud Platform portal.
- Exercise special caution regarding security when uploading backup files to a bucket without separate access and permission controls, as any user who knows the URL can download the files.
- In the VPC environment of the NAVER Cloud Platform console, navigate to Menu > Services > Database > Cloud DB for MySQL.
- Click the Backup menu.
- Click [Details] of the backup settings row for the file you want to save to Object Storage.
- Select the backup file and click [Export to Object Storage].

- When the Export to Object Storage popup appears, click and select the bucket and folder you want to save into.

- Click [Export to Object Storage].
- Click [OK].
- When exporting to Object Storage, unlocking bucket, appropriate access control, and ACL settings are required.
- For the Japan Region, disable access control settings for the Object Storage bucket.
- Exporting to Object Storage may take several minutes to be completed.
Use backup utility
You can back up and restore the data on a MySQL Server using utilities such as Percona Xtrabackup and mysqldump.
Restore backup file using Xtrabackup
After saving the backup file to NAVER Cloud Platform's Object Storage, you can use Xtrabackup to restore data from the server.
The prerequisites for restoring a backup file saved to Object Storage using Xtrabackup are as follows:
- The major version of MySQL installed on the user's separate server is the same as the major version of MySQL that was backed up.
- The Xtrabackup binary required for restoration of backup file exists.
- At the MySQL Server to be restored, my.cnf file with
datadirvariable exists. - The OS user executing the restoration command is able to access and write in the
datadirdirectory. - MySQL is in the Shutdown status in the server to be restored.
- If the server is using another OS other than CentOS, you need to download the Xtrabackup binary for the OS image you are using from the download link. When using MySQL 8.0 or higher, make sure to download the corresponding version of Xtrabackup for the MySQL version you are restoring.
- For more information on Xtrabackup binary options, see Percona official document (English).
To restore data using Xtrabackup, proceed with the following steps in order. The description is based on CentOS 7.8 application servers.
1. Prepare the backup file at the Object Storage
- Store the backup file of the MySQL Server to restore to the Object Storage by referring to Store in Object Storage.
- Set up access control by selecting one of two methods according to security requirements.
- Method A (Access from anywhere): Files can be downloaded from anywhere using the link address in the file details, without any separate access control settings.
- Method B (Access only from specific servers): Add the servers to download backup files to the allow list by referring to Object Storage bucket access control settings.
- Click the saved backup file, then go to Edit > Manage permissions and change all public items to Public.
- From the details of the saved backup file, copy the link in the Link item.
- If configured to be accessible from anywhere, the backup files are highly vulnerable to security threats because anyone with the URL can download them, even from the external internet.
- If you configure a bucket's ACL to restrict access to specific servers only, be advised that access from existing servers using that bucket may be blocked.
2. Restore data using Xtrabackup
- Access the application server by referring to Getting started with Cloud DB for MySQL.
- If the Server is using MySQL 5.7 version, add the
innodb_undo_tablespaces = 2syntax under the[mysqld]syntax of the my.cnf file.
# vi /etc/my.cnf [mysqld] innodb_undo_tablespaces = 2 - If the Server is using MySQL 5.7 version, add the
- Paste the copied link in the following command and run it to download the backup file.
# wget [Link] -- public url example: # wget https://kr.object.ncloudstorage.com/mysql-b/20211013_BACKUP.1634094735 -- private url example: # wget https://kr.object.private.ncloudstorage.com/mysql-b/20211013_BACKUP.1634094735 - Run the following commands in order to download Xtrabackup.
- MySQL 5.7 version
# cd ~ # wget https://www.percona.com/downloads/Percona-XtraBackup-2.4/Percona-XtraBackup-2.4.9/binary/tarball/percona-xtrabackup-2.4.9-Linux-x86_64.tar.gz # tar xzf percona-xtrabackup-2.4.9-Linux-x86_64.tar.gz # cd ./percona-xtrabackup-2.4.9-Linux-x86_64 # XTRABACKUP_DIR=`pwd`- MySQL 8.0 version
# cd ~ # wget https://downloads.percona.com/downloads/Percona-XtraBackup-8.0/Percona-XtraBackup-8.0.23-16/binary/tarball/percona-xtrabackup-8.0.23-16-Linux-x86_64.glibc2.17.tar.gz # tar xzf percona-xtrabackup-8.0.23-16-Linux-x86_64.glibc2.17.tar.gz # cd ./percona-xtrabackup-8.0.23-16-Linux-x86_64.glibc2.17 # XTRABACKUP_DIR=`pwd`- MySQL 8.4 version
# cd ~ # wget https://downloads.percona.com/downloads/Percona-XtraBackup-8.4/Percona-XtraBackup-8.4.0-4/binary/tarball/percona-xtrabackup-8.4.0-4-Linux-x86_64.glibc2.34.tar.gz # tar xzf percona-xtrabackup-8.4.0-4-Linux-x86_64.glibc2.34.tar.gz # cd ./percona-xtrabackup-8.4.0-4-Linux-x86_64.glibc2.34 # XTRABACKUP_DIR=`pwd` - Run the following command to set the absolute path of the my.cnf file.
# MYSQL_CONF=/etc/my.cnf - Run the following commands in order to create a temporary directory and copy the backup file.
# cd ~ # mkdir backup # cd ./backup/ # cp ~/[Backup file name]. -- Example # cp ~/20211013_BACKUP.1634094735 . - Run the following commands in order to specify the path of
BACKUP_DIRas the location of the temporary directory, and check if each path has been specified properly.# BACKUP_DIR=`pwd` # echo $XTRABACKUP_DIR # echo $MYSQL_CONF # echo $BACKUP_DIR - Run the following commands in order to end MySQL in operation and extract the file from
xbstream.# systemctl stop mysqld # cd $BACKUP_DIR # cat [uploaded_ backupfile] | ${XTRABACKUP_DIR}/bin/xbstream -x -- Example # cat 20211013_BACKUP.1634094735 | ${XTRABACKUP_DIR}/bin/xbstream -x - Run the following command to restore the backup file to the created temporary directory.
- MySQL 5.7 version
# ${XTRABACKUP_DIR}/bin/innobackupex --defaults-file=${MYSQL_CONF} --apply-log ${BACKUP_DIR}/- MySQL 8.0 version or higher
# ${XTRABACKUP_DIR}/bin/xtrabackup --defaults-file=${MYSQL_CONF} --prepare --target-dir=${BACKUP_DIR}/ - Open the my.cnf file to check the location of datadir, and run the following command to move the directory for the datadir variable to another temporary backup folder.
# mv [data directory location] /[new_directory location] -- Example # mkdir /new_directory # mv /var/lib/mysql /new_directory - Run the following command to move the backup file to the newly created MySQL directory.
- MySQL 5.7 version
# ${XTRABACKUP_DIR}/bin/innobackupex --defaults-file=${MYSQL_CONF} --move-back ${BACKUP_DIR}- MySQL 8.0 version or higher
# ${XTRABACKUP_DIR}/bin/xtrabackup --defaults-file=${MYSQL_CONF} --move-back --target-dir=${BACKUP_DIR}/ - Enter the following commands in order to move to the location of datadir, and change the datadir permission to
mysql.- Upon completion of the change, you can run the
llcommand to check if the permission has been changed properly.
# cd /var/lib/mysql # chown -R mysql:mysql [data directory path] -- Example # chown -R mysql:mysql /var/lib/mysql - Upon completion of the change, you can run the
- Add "skip-grant-tables" under the
[mysqld]syntax of the my.cnf file.# vi /etc/my.cnf [mysqld] skip-grant-tables - Run the following commands in order to start MySQL and create a new root account.
- When running
create, theERROR 1396 (HY000): Operation CREATE USER failed for 'root'@'localhost'error may occur. In this case, run thedrop user 'root'@'localhost';command to delete the existing root account, and runcreateagain.
# systemctl start mysqld mysql -u root -p mysql > flush privileges; mysql> create user root@localhost identified by 'password'; mysql > grant all privileges on *.* to root@localhost with grant option; mysql > flush privileges; - When running
- Delete the
skip-grant-tablessyntax added under the[mysqld]syntax in the my.cnf file, and run the following command to restart MySQL.# systemctl restart mysqld
Back up and restore DB using mysqldump
You can perform backup and restoration of MySQL Server in the application server using the mysqldump utility.
Back up DB using mysqldump
To back up a DB from a server using the mysqldump utility:
- Since the Cloud DB for MySQL uses Global Transaction Identifier (GTID), the
--set-gtid-purged=OFFoption needs to be added during the backup to restore a MySQL DB that does not use GTID. - If you want to create a replication connection with the Cloud DB for MySQL immediately after performing backup, delete the
--set-gtid-purged=OFFoption to enable the use of GTID. - In case of restoring the backup file of the Cloud DB for MySQL to another Cloud DB for MySQL service, enable the
--set-gtid-purged=OFFoption and proceed with the backup only for the user DB.
- Access the application server by referring to Getting started with Cloud DB for MySQL.
- Run the following command to backup the desired DB.
You can check the user ID, password, private domain, and DB name from server details of each server in the DB Server menu in the console.- Back up only specific DB
# mysqldump --set-gtid-purged=OFF -u [User_ID] -p -h [DB Private domain] -P [DB access port] --single-transaction --databases [name of the database to back up] > [name of the backup file to create].sql -- Example # mysqldump --set-gtid-purged=OFF -u person -p -h db-1qv7d.cdb.ntruss.com -P 3306 --single-transaction --databases dbdb > dumpfile.sql- Back up all DB
--mysqldump 5.7 or earlier versions # mysqldump --set-gtid-purged=OFF -u [User_ID] -p -h [DB Private domain] -P [DB access port] --single-transaction --all-databases > [name of the backup file to create].sql -- Example # mysqldump --set-gtid-purged=OFF -u person -p -h db-1qv7d.cdb.ntruss.com -P 3306 --single-transaction --all-databases > dumpfile.sql --mysqldump 8.0 version or higher # mysqldump --set-gtid-purged=OFF -u [User_ID] -p -h [DB Private domain] -P [DB access port] --single-transaction --column-statistics=0 --all-databases > [name of the backup file to create].sql -- Example # mysqldump --set-gtid-purged=OFF -u person -p -h db-1qv7d.cdb.ntruss.com -P 3306 --single-transaction --column-statistics=0 --all-databases > dumpfile.sql
Restore backup file using mysqldump
To restore data from the server using the mysqldump utility:
If the backup file contains SQL statements that are not supported by Cloud DB for MySQL, as shown in the following example, remove them.
- Syntax that set GLOBAL or SESSION variables.
- Syntax of object creation statements such as PROCEDURE, FUNCTION, and EVENT that include a DEFINER clause.
- Access the application server by referring to Getting started with Cloud DB for MySQL.
- Run the following command to restore the desired backup file.
# mysql -u root -p < [backup file name].sql
-- Example
# mysql -u root -p < dumpfile.sql
-- If a `ERROR 3546 (HY000)` error occurs while restoring from a backup file that excludes the `--set-gtid-purged=OFF` option, first run the commands below in order, then proceed with the restoration.
# mysql -u root -p
mysql> reset master;
Replication connection
You can create a replication connection between the Slave Server and Master Server and check the replication status.
To create a replication connection:
The Master Server is a server that uses a private domain, and the Slave Server is a local server.
- Create a user account to be used for the replication connection by referring to DB user management.
- For HOST (IP), enter the private IP of the application server where the Slave Server is located.
- Add the following settings under the
[mysqld]syntax of the my.cnf file.- The
server-idshould be set with a unique value to identify each server in the replication configuration, and you can only enter a number between 1 and 4294967295.
# Replication server-id = 2 log-bin = mysql-bin relay-log = relay-bin report-host = ncp-mysql-server master_info_repository = FILE relay_log_info_repository = FILE slave_type_conversions = ALL_NON_LOSSY log_slave_updates # required! GTID read_only # required! # Replication GTID enforce-gtid-consistency # required! GTID gtid-mode = ON # required! GTID - The
- Run the following command to restart MySQL.
systemctl restart mysqld - Back up the DB by referring to Use backup utility.
- Run the following commands in order to access the Slave Server with the root account and change the master.
mysql -u root -p
mysql> CHANGE MASTER TO
MASTER_HOST = 'DB Private domain',
MASTER_USER = 'User_ID',
MASTER_PASSWORD = 'user password',
MASTER_PORT = 3306,
MASTER_AUTO_POSITION = 1;
-- Example
mysql> CHANGE MASTER TO
-> MASTER_HOST = 'db-1qv7d.cdb.ntruss.com',
-> MASTER_USER = 'replication',
-> MASTER_PASSWORD = 'password1!',
-> MASTER_PORT = 3306,
-> MASTER_AUTO_POSITION = 1;
- Run the following command to connect to the Master Server from the Slave Server.
mysql> START SLAVE;
Confirm connection
After completing the replication connection, run the following command and refer to the table to check the connection status.
mysql> show slave status \G;
| Item | Description |
|---|---|
Slave_IO_State |
Current status of the Slave Server. |
Master_Host |
IP address of the Master Server that the Slave Server is connected to. |
Master_User |
User account used for the Slave Server's connection to the Master Server. |
Master_Port |
Port used for the Slave Server's connection to the Master Server. |
Connect_Retry |
Duration of the reconnection attempt when the connection is lost (default: 60 seconds).
|
Master_Log_File |
Name of the Master Server's binary log file that the I/O thread is currently reading. |
Read_Master_Log_Pos |
Location of the Master Server's binary log file that the I/O thread is currently reading. |
Relay_Log_File |
Name of the Slave Server's relay log that the SQL thread is currently reading. |
Relay_Log_Pos |
Location of the Slave Server's relay log that the SQL thread is currently reading. |
Relay_Master_Log_File |
Name of the source binary log file that includes the recent events executed by the SQL thread. |
Slave_IO_Running |
I/O thread operation status of the Slave Server; displays the connection status to the Master Server through one of the following three values:
|
Slave_SQL_Running |
Displays if the SQL thread has started. |
Replicate_Do_DB |
DB list specified with the --replicate-do-db option. |
Replicate_Ignore_DB |
Database list specified with the --replicate-ignore-db option. |
Replicate_Do_Table |
Database list specified with the --replicate-do-table option. |
Replicate_Ignore_Table |
Database list specified with the --replicate-ignore-table option. |
Replicate_Wild_Do_Table |
Database list specified with the --replicate-wild-do-table option. |
Replicate_Wild_Ignore_Table |
Database list specified with the --replicate-wild-ignore-table option. |
Last_Errno, Last_Error |
Same value as the Last_SQL_Errno item; the value can be reset with the RESET MASTER and RESET SLAVE commands.
|
Skip_Counter |
Displays the current value of SQL_Slave_Skip_Counter, which is a system variable. |
Exec_Master_Log_Pos |
This is the location of the current master's binary log file read and run by the SQL thread. It displays the start of the transaction or event to be processed next.
|
Relay_Log_Space |
Sum value of the size of all existing relay log files. |
Until_Condition |
Value specified in the START_SLAVE command, displayed as one of the following values:
|
Until_Log_File |
Name of the log file that the SQL thread will run and then suspend. |
Until_Log_Pos |
Position value of the log file that the SQL thread will run and then suspend. |
Master_SSL_Allowed |
The SSL parameter used for the Slave Server's connection to the Master Server, displayed as one of the following values:
|
Master_SSL_CA_File |
SSL parameter used for the Slave Server's connection to the Master Server. |
Master_SSL_CA_Path |
SSL parameter used for the Slave Server's connection to the Master Server. |
Master_SSL_Cert |
SSL parameter used for the Slave Server's connection to the Master Server. |
Master_SSL_Cipher |
SSL parameter used for the Slave Server's connection to the Master Server. |
Master_SSL_Key |
SSL parameter used for the Slave Server's connection to the Master Server. |
Seconds_Behind_Master |
Displays how much the replication speed of the Slave Server has slowed down. |
Master_SSL_Verify_Server_Cert |
SSL parameter used for the Slave Server's connection to the Master Server. |
Last_IO_Errno |
Number of the error that stopped the I/O thread most recently. |
Last_IO_Error |
Error message that stopped the I/O thread most recently. |
Last_SQL_Errno |
Number of the error that stopped the SQL thread most recently. |
Last_SQL_Error |
Error message that stopped the SQL thread most recently. |
Replicate_Ignore_Server_Ids |
Content from running the IGNORE_SERVER_IDS option in the CHANGE MASTER TO syntax for the Slave Server. |
Master_Server_Id |
Master server's server_id value. |
Master_UUID |
Master server's server_uuid value. |
Master_Info_File |
Location of the master.info file. |
SQL_Delay |
Displays by how many seconds the Slave Server delays the replication with the Master Server. |
SQL_Remaining_Delay |
Displays the remaining time when the Slave_SQL_Running_State is Waiting until MASTER_DELAY seconds after master executed event.
|
Slave_SQL_Running_State |
Operation status of the SQL thread. |
Master_Retry_Count |
Number of reconnection attempts when the Slave Server's connection to the Master Server is lost. |
Master_Bind |
Binding network interface for the Slave Server. |
Last_IO_Error_Timestamp |
Time of occurrence for the most recent I/O error.
|
Last_SQL_Error_Timestamp |
Time of occurrence for the most recent SQL error.
|
Retrieved_Gtid_Set |
GTID group that corresponds to all transactions that the Slave Server received.
|
Executed_Gtid_Set |
GTID group created on the binary log.
|
Auto_Position |
Set to 1 when using Auto_Position; set to 0 otherwise. |
Troubleshoot replication errors
If the Executed_Gtid_Set values of the Master Server and Slave Server are not identical, then one of the values for Slave_SQL_Running and Slave_IO_Running is displayed as No when the connection status is checked with the show slave status \G; command. In this case, the following errors may be displayed.
Last_SQL_Error: Coordinator stopped because there were error(s) in the worker(s). The most recent failure being: Worker 1 failed executing transaction 'e0b74649-41d7-11ec-afb6-f220af895dd6:2' at master log mysql-bin.000001, end_log_pos 751. See error log and/or performance_schema.replication_applier_status_by_worker table for more details about this failure or others, if any.
Last_IO_Error: 1236
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires. Replicate the missing transactions from elsewhere, or provision a new slave from backup. Consider increasing the master's binary log expiration period.
To troubleshoot replication errors by editing the Executed_Gtid_Set value:
To prevent data mismatch when resetting the GTID_PURGED value, refer to the official documents of MySQL and Percona.
- Run each of the following commands to check if the
Executed_Gtid_Setvalues of the Master Server and Slave Server are identical.- Master Server:
show global variables like 'gtid_executed'; - Slave Server:
show slave status \G;
- Master Server:
- Run the following command to reset the
GTID_PURGEDvalue.① Reset GTID_PURGED mysql> stop slave; mysql> reset master; mysql> set global GTID_PURGED="master Executed_Gtid_Set value"; mysql> start slave; ② Reset root account mysql> flush privileges; mysql> create user root@localhost identified by 'password'; mysql> grant all privileges on *.* to root@localhost with grant option; mysql> flush privileges;
Manual Backup
You can create a snapshot-based backup of MySQL Server at any time.
You can create up to 30 snapshots per DB service. To create a snapshot:
This feature is available only for DBs configured for high availability (HA).
Back up
- In the VPC environment of the NAVER Cloud Platform console, navigate to Menu > Services > Database > Cloud DB for MySQL.
- From the Cloud DB for MySQL menu, navigate to DB Server > Manage DB > Manual Backup.
- When the Manual Backup popup appears, click [OK].
.png?sv=2026-02-06&spr=https&st=2026-07-18T10%3A11%3A29Z&se=2026-07-18T10%3A46%3A29Z&sr=c&sp=r&sig=EPSG2MPmEN7UJAjmWOKU98jDHkLUH4FZjULwCsk2kPg%3D)
View Manual Backup list
- In the VPC environment of the NAVER Cloud Platform console, navigate to Menu > Services > Database > Cloud DB for MySQL.
- Click the Backup menu.
- Click the [Manual Backup] tab.
- DB Service name: DB Service name specified by user.
- Backup type: Backup method category.
- Backup data size: Size of the completed backup file.
- Latest backup date: Date for the latest backup that was performed.
- View details: Details and restoration of the backup file list created per server.
View Manual Backup list by server
To check the backup file list created for each server after completing the backup:
-
In the VPC environment of the NAVER Cloud Platform console, navigate to Menu > Services > Database > Cloud DB for MySQL.
-
Click the Backup menu.
-
Click [Details] from View details of the backup settings row you want to check the details for.
-
Click the [Manual Backup] tab.
-
Check the details for the backup file.
.png?sv=2026-02-06&spr=https&st=2026-07-18T10%3A11%3A29Z&se=2026-07-18T10%3A46%3A29Z&sr=c&sp=r&sig=EPSG2MPmEN7UJAjmWOKU98jDHkLUH4FZjULwCsk2kPg%3D)
- Backup date: Date that the backup was performed.
- Snapshot name: Name of the Manual Backup snapshot you created.
- Snapshot creation time: Time when the Manual Backup was created.
- Snapshot size: Size of the snapshot backup.
- Zone: Zone containing the snapshot.
Restore a snapshot
Manual Backup creates a snapshot that you can use to restore a new DB service.
- In the VPC environment of the NAVER Cloud Platform console, navigate to Menu > Services > Database > Cloud DB for MySQL.
- Click the Backup menu.
- Click the [Manual Backup] tab.
- Click [Details] in the backup settings row you want to restore.
- Select the backup file and click [Restore Snapshot].
- When the Snapshot recovery popup appears, check or enter the required information for restoration.
.png?sv=2026-02-06&spr=https&st=2026-07-18T10%3A11%3A29Z&se=2026-07-18T10%3A46%3A29Z&sr=c&sp=r&sig=EPSG2MPmEN7UJAjmWOKU98jDHkLUH4FZjULwCsk2kPg%3D)
- Snapshot creation time: Time when the backup was performed.
- Zone: Zone where the snapshot is located.
- DB Server type: MySQL Server type to restore.
- DB Server name: MySQL Server name to restore.
- DB Service name: New DB Service name.
- High availability: Create it as a high availability configuration when creating a new service.
- Multi Zone: Create the Standby Master Server and Master Server in different availability zones.
- Subnet: Subnet information of MySQL Server to restore.
Delete a snapshot
Manual Backup creates snapshots that you can delete.
- In the VPC environment of the NAVER Cloud Platform console, navigate to Menu > Services > Database > Cloud DB for MySQL.
- Click the Backup menu.
- Click the [Manual Backup] tab.
- Click [Details] in the backup settings row you want to restore.
- Select the backup file and click [Delete Snapshot].