Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Published by Scroll Versions from space ML1 and version 5.3
Sv translation
languageen


Info

See also FTP Server Setup for Fast Backup and Restore.

Table of Contents

Parallel Backup and Restore

Xpand implements Fast Backup and Restore as a binary backup mechanism that works at the row level. Each Xpand node sends its data directly to the backup target in parallel, eliminating bottlenecks and allowing backup to scale with cluster size. Restore is handled similarly; the initiating node coordinates with other participating nodes in parallel to read from the dump file and restore replicas. 

The structure of the dumped data consists of text files describing the schema and metadata about the backup. The dumped data also contains binary files of compacted row data and data consistency information. Modifying these files may make it impossible to restore from the backup.

Xpand uses a Cyclic Redundancy Check (CRC) during Backup and Restore. Calculating the CRC allows the Restore function to validate the data written during the Backup function. CDC adherence also requires that any failed backup or restore be restarted from the beginning.

Xpand's Fast Backup and Restore:

  • Is implemented as SQL commands that are executed from a MySQL client.
  • Supports passive (versus active) mode FTP or SFTP
  • Supports password-based authentication for SFTP 
  • Cannot be executed via stored procedures, functions or triggers.
Note

Xpand recommends running BACKUP and RESTORE in a screen session or using tmux to avoid connection failures.

Xpand also recommends running both BACKUP and RESTORE during off-peak hours.

Anchor
Backup
Backup
Backup

Backup runs as a single transaction and will pin BigC (Xpand's garbage collection) for the duration of the operation. This may require operational consideration if your cluster does not have enough free space for the undo log created from this long running transaction.

Backup SQL Syntax
sql> BACKUP identifier [, identifier] [EXCLUDING excluded_identifier] TO 'target' [COMPRESSED]

Both the identifer and excluded_identifer should refer to valid system objects. This can be a fully qualified name, or include wildcards (*) for the database, object, or both. For example:

  • db_name.obj_name - references a specific object in the given database (i.e. table name, view name).
  • db_name.*  - expands to all accessible objects in that database.
  • *.*  - expands to every accessible object in the system. (Meaningless for excluded objects.)

Additionally the excluded_identifer can specify a given table. For example:

  • *.tbl_name - references a given table name in any database that is to be excluded from the backup.

Xpand uses username and password authentication. The server path for FTP represents the relative path from the FTP root directory whereas the path for the SFTP server should be the absolute path from the Linux root directory. For example: "ftp://user:[email protected]/relative_path/from_ftp_root" or "sftp://user:[email protected]:absolute_path/from_Linux_root".

Note

Care should be taken when excluding objects from a backup. This can cause errors during RESTORE if another object depends on the excluded object.

For example, if a trigger or view refers to an excluded object that does not already exist in the restored environment, an error will occur during the RESTORE.

Triggers, views, and foreign keys that reference an excluded object will be backed up, unless they are specifically excluded.

SFTP

To use an SFTP for Backup and Restore, specify the absolute path of the file location (versus relative path for FTP) and provide a username and password for authentication. For example: "sftp://user:[email protected]:absolute_path/from_Linux_root"

Compression

To create a compressed backup, specify the COMPRESSED option. This functionality reduces bandwidth requirements for backup to remote locations and reduces the amount of storage utilized, but adds additional latency to complete a backup.

Tuning BACKUP Performance

You may want to tune BACKUP to be slower or faster. 

sql> set global backup_backup_concurrency = desired_value;

The global variable backup_backup_concurrency determines the number of tables that can be backed up simultaneously. With the default value of 1, the backup process is limited to one table at a time.

Example BACKUP Commands

sql> BACKUP db_name1.*, db_name2.tbl_name1, db_name2.tbl_name2 TO 'ftp://storage01/uploads/johndoe+kibbles.jun01'; 
sql> BACKUP *.* EXCLUDING db_name2.tbl_name1 TO 'ftp://storage01/uploads/johndoe.kibbles.jun01';
sql> BACKUP test TO 'sftp://plato:[email protected]:22/tmp/tc5326/tc5326.bkup';

Getting Information on Backups

The following queries show the status of all currently running backups and restores.

Displaying all Backups on a Source

sql> SELECT * from system.backups where source="ftp://storage01/uploads"\G
*************************** 1. row **************************
source: ftp://storage01/uploads
backup: 1_52T_large_dogfood_dbx2
cluster_name: cl5d97786267d0d4cb
version: 5.0.45-clustrix-7.5.2
status: ERROR
start_time: 2016-06-15 01:43:36
completed_time: 2016-06-15 03:19:31
size: 0

Displaying the Status of Backup/Restore

Run the following query to view information for a backup in progress
sql> select * from system.backup_status\G
*************************** 1. row **************************
nodeid: 2
id: 5756997494884148226
type: BACKUP
url: ftp://storage01/uploads/1_52T_large_dogfood_dbx2_2
objs: (("test" . "")("clustrix_ui" . "")("bugstest_01" ."")("jtunes_01" . "")("longstats_01" . "")("npktest_01" ."")("perfstats_01" . "")("run_resources_01" . "")("statd_01" ."")("bugstest_02" . "")("jtunes_02" . "")("longstats_02" ."")("npktest_02" . "")("perfstats_02" . "")("run_resources_02" ."")("statd_02" . "*"))
start_time: 2016-06-22 22:50:32
expected_bytes: 793977192448
replicas: 1070
rows: 49589227
bytes: 23991322310
1 row in set (0.01 sec)

Displaying all Backed Up Tables on a Source

sql> SELECT * from system.backup_tables where source="ftp://storage01/uploads" limit 2;
+-------------------------+--------------------------+-------------+------------+------+
| source                  | backup                   | db          |table       | size |
+-------------------------+--------------------------+-------------+------------+------+
| ftp://storage01/uploads | 1_52T_large_dogfood_dbx2 | bugstest_01 |attach_data | 0    |
+-------------------------+--------------------------+-------------+------------+------+
| ftp://storage01/uploads | 1_52T_large_dogfood_dbx2 | bugstest_01 |attachments | 0    |
+-------------------------+--------------------------+-------------+------------+------+
2 rows in set (12.16 sec)

Anchor
Restore
Restore
Restore

Use the following syntax to restore objects previously backed up with Fast Backup.

Restore SQL Syntax
sql> RESTORE identifier [AS identifier] [, identifier [AS identifier]] [EXCLUDING excluded_identifier] FROM target [REPLICAS=N]

Both the identifer and excluded_identifer should refer to valid system objects. This can be a fully qualified name, or include wildcards (*) for the database, object, or both. For example:

  • db_name.obj_name - references a specific object in the given database (i.e. table name, view name).
  • db_name.*  - expands to all accessible objects in that database.
  • *.*  - expands to every accessible object in the system. (Meaningless for excluded objects.)

Additionally, the excluded_identifer can specify a given table. For example:

  • *.tbl_name - references a given table name in any database that is to be excluded from the restore.

Tables may be renamed during the restore process by providing a table alias [AS identifier].

The server path for FTP represents the relative path from the FTP root directory whereas the path for the SFTP server should be the absolute path from the Linux root directory. For example: "ftp://user:[email protected]/relative_path/from_ftp_root" or "sftp://user:[email protected]:absolute_path/from_Linux_root".

Note

Care should be taken when restoring from a backup that used the EXCLUDING option. This can cause errors during restoration if another object depends on the excluded object(s).

For example, if a trigger or view refers to an object that does not already exist in the restored environment, an error will occur.

Triggers, views, and foreign keys that reference an object excluded from the backup will be successfully restored only if the object exists in the restored environment.

REPLICAS = N 

The number of replicas for a table or index is recorded within the backups. Normally when RESTORE is run, tables and indexes are restored with the same number of replicas as the original. This option allows you to explicitly specify the number of replicas that should be created as part of the RESTORE operation.

For example, if a table had three replicas when backed up, the following example would create the table with only two replicas.

sql> RESTORE * FROM 'ftp://storage01/uploads/johndoe.kibbles.jun01' REPLICAS = 2;

See more on specifying the number of replicas in a table in the section on Managing Data Distribution.

Tuning RESTORE Performance

You may want to tune RESTORE to be slower or faster. 

sql> set global backup_restore_concurrency = desired_value;

The global variable backup_restore_concurrency determines the number of slices that can be restored simultaneously to each node. 

Example RESTORE Commands

sql> RESTORE db_name.tbl_name AS db_name_backup.tbl_name FROM 'ftp://[email protected]/backups/backupfolders/backup_file';
sql> RESTORE tbl_name, tbl_name2, tbl_name3 FROM 'ftp://[email protected]://server.com/backups/backupfolders/backup_file';
sql> RESTORE ehms FROM 'sftp://[email protected]/root/ehmssftp';

Global Variables 

The following global variables impact Fast Backup and Restore. The defaults provided are generally acceptable. These variables are not available by session. 

NameDescriptionDefault Value
backup_backup_concurrency

The number of tables that can be backed up simultaneously.

1
backup_restore_concurrencyThe maximum number of slices restored concurrently on each node. 16
backup_write_compression_levelCompression level from 1 (fastest) to 9 (best compression)6

Using BACKUP/RESTORE to Resolve Replication Issues

Fast Backup and Restore can also be used to resolve the following issues in replicated environments.

Scenario I : Xpand slave does not exist or needs to be reset with master.

  1. Take a fresh backup using BACKUP sql command on master. This will minimize the time it will take for the slave to catch up if older backups were to be used.
  2. Stop the slave if one already exists. If none exists as yet, please refer to Using Xpand as a Replication Slave and Starting and Stopping a Slave Process for steps to create a new Xpand slave and leave it in stop mode after successful creation.
  3. Restore backup taken in step 1 on slave using RESTORE command.
  4. Master's binlog position when backup initiates is stored under your_backup_location/metadata/binlogs file. This file contains relevant information in the format logfile.seq#:position, for example, foo1.002843:99744547.
  5. Reset the position recorded in the binlogs file by issuing the command:

sql> CHANGE MASTER TO MASTER_LOG_FILE='foo1.002843', MASTER_LOG_POS=99744547,MASTER_HOST='foo1', MASTER_USER='root', MASTER_PORT=3306;

         6. Start the slave.

Scenario II: Xpand Master needs to be restored, Xpand Slave looks good.

  1. Promote Xpand slave to act as master. Please refer to Promoting a Xpand Slave to Master for the necessary steps to promote a passive Xpand slave to an active Master mode.
  2. Follow steps outlined in Scenario I to restore and reset the old master which is now in passive slave mode.
  3. If necessary, repeat the steps to switch over the current passive slave to active master once both master and slave are fully caught up.

Scenario III: Xpand Master and Slave both need to be restored and reset.

  1. Stop the slave.
  2. Restore the master and slave using RESTORE command.
  3. Reset the slave to the current position of the master (i.e. from SHOW MASTER STATUS on the master), after the restore, before it begins taking writes from clients. Note that using this technique, you are losing incremental changes since the backup. An advanced method to capture the incremental changes since backup would be to replay the binlogs if they are still available, and change the serverid of the master, in order to have it reapply the events in the binlog. Please contact Xpand Support for assistance with this advanced procedure.
  4. Start the slave.
Tip

If you receive the following timeout error during the backup process, "Socket timeout while waiting for server response: read_timer", the global variable ftp_read_timeout_secs can be increased to a higher value, up to 3000, to prevent this error. This global applies to backups and restores of both FTP and SFTP servers.

Mysqldump

To create a dump of the Xpand, use the mysqldump utility, which is included on each node in your cluster. If you intend to import the dump into a Slave, create the binary log for the replication stream before you create the dump.

To create the dump, issue the following command:

shell> mysqldump -u user -h clustrix host --single-transaction --master-data=2 --all-databases > mydumpfile.dump
  • The --single-transaction flag ensures a consistent snapshot of the database by querying for all of the data in a single transaction and permits continued access to the Xpand while the dump is being created.
  • The --master-data=2 flag inserts a CHANGE MASTER command in a comment near the top of the dump file, indicating the location in the binary log where a slave must start to be consistent with the dump. If no binlog is being created, omit the --master-data flag.

Additional Resources

FTP Server Setup for Fast Backup and Restore

List of Errors for Backup and Restore


Sv translation
languageko
Info

FTP Server Setup for Fast Backup and Restore도 참조하십시오.

Table of Contents

병렬 백업 및 복원

ClustrixDB는 행 수준에서 작동하는 바이너리 백업 메커니즘으로 빠른 백업 및 복원을 구현합니다. 각 ClustrixDB 노드는 병목을 제거하고 클러스터 크기로 백업을 확장할 수 있도록 백업 대상에 직접 데이터를 병렬로 전송합니다. 복원도 비슷하게 처리됩니다, 즉, 시작 노드는 다른 참여 노드와 조정해 병렬로 덤프 파일을 읽고 복제본을 복원합니다.

덤프 된 데이터의 구조는 백업에 대한 스키마와 메타데이터를 설명하는 텍스트 파일로 구성됩니다. 덤프 된 데이터에는 압축된 행 데이터 및 데이터 일관성 정보의 바이너리 파일도 들어 있습니다. 이러한 파일을 수정하면 백업에서 복원할 수 없게 될 수 있습니다.

ClustrixDB는 백업 및 복원 중에 CRC(Cyclic Redundancy Check)를 사용합니다. CRC를 계산하면 복원 기능이 백업 기능 중에 기록된 데이터의 유효성을 검사할 수 있습니다. CRC를 준수하기 위해 장애가 발생한 백업 또는 복원은 처음부터 다시 시작해야 합니다.

ClustrixDB의 빠른 백업 및 복원은

  • MySQL 클라이언트에서 실행되는 SQL 명령으로 구현됩니다.
  • passive (대 active) 모드 FTP 또는 SFTP를 지원합니다.
  • SFTP에 대한 암호 기반 인증을 지원합니다.
  • 저장 프로시저, 함수 및 트리거를 통해 실행할 수 없습니다.
Note

커넥션 장애를 피하려면 screen 세션에서 BACKUPRESTORE를 실행하거나 tmux를 사용할 것을 권장합니다.

또한, 사용량이 적은 시간에 BACKUPRESTORE를 실행하도록 권장합니다.

백업

백업은 단일 트랜잭션으로 실행되며 작업 기간 동안 BigC(ClustrixDB의 가비지 컬렉션)를 고정합니다. 이 오래 실행되는 트랜잭션에서 작성된 Undo 로그에 대해 충분한 여유 공간이 클러스터에 없는 경우 운영적인 고려가 필요할 수 있습니다.

Backup SQL 구문
sql> BACKUP identifier [, identifier] [EXCLUDING excluded_identifier] TO 'target' [COMPRESSED]

identiferexcluded_identifer는 유효한 시스템 객체를 참조해야 합니다. 이것은 FQN(fully qualified name)이거나 데이터베이스, 객체 또는 둘 모두에 대해 와일드카드(*)를 포함할 수 있습니다. 예:

  • db_name.obj_name - 해당 데이터베이스의 특정 객체(즉, 테이블 이름, 뷰 이름)를 참조합니다.
  • db_name.* - 해당 데이터베이스의 액세스 가능한 모든 객체로 확장됩니다.
  • *.* - 시스템의 모든 액세스 가능한 객체로 확장됩니다. (제외된 객체에 대해서는 의미가 없습니다.)

또한, excluded_identifer는 특정 테이블을 지정할 수 있습니다. 예:

  • *.tbl_name - 백업에서 제외할 데이터베이스의 해당 테이블 이름을 참조합니다.

ClustrixDB는 사용자 이름 및 패스워드 인증을 사용합니다. FTP의 서버 경로는 FTP 루트 디렉토리의 상대 경로를 나타내지만 SFTP 서버의 경로는 Linux 루트 디렉토리의 절대 경로이어야 합니다. 예: "ftp://user:[email protected]/relative_path/from_ftp_root" 또는 "sftp://user:[email protected]:absolute_path/from_Linux_root".

Note

백업에서 객체를 제외할 때는 주의해야 합니다. 다른 객체가 제외된 객체에 의존하고 있으면 RESTORE 중에 오류가 발생할 수 있습니다.

예를 들어, 트리거 또는 뷰가 복원된 환경에 존재하지 않는 제외된 객체를 참조하는 경우, RESTORE 중에 오류가 발생합니다.

제외된 객체를 참조하는 트리거, 뷰 및 외래 키는 특별히 제외되지 않는 한 백업됩니다.

SFTP

백업 및 복원에 SFTP를 사용하려면 파일 위치의 절대 경로(대 FTP의 상대 경로)를 지정하고 인증을 위한 사용자 이름과 패스워드를 제공하십시오. 예를 들어, "sftp://user:[email protected]:absolute_path/from_Linux_root"

압축

압축된 백업을 생성하려면 COMPRESSED 옵션을 지정하십시오. 이 기능은 원격 위치로의 백업에 대한 대역폭 요구 사항을 줄이고 사용되는 스토리지의 양을 줄여주지만, 백업을 완료하는데 더 많은 시간이 걸립니다.

글로벌 변수

다음 글로벌 변수는 빠른 백업 및 복원에 영향을 줍니다. 제공되는 기본값은 일반적으로 허용됩니다. 이 변수는 세션 변수로 사용할 수 없습니다.

이름설명기본값
backup_backup_concurrency단일 백업 트랜잭션 내에서 병렬 처리를 제어합니다.1
backup_compression_buffer_size_bytes압축 버퍼의 크기262144
backup_read_buffer_size_bytes읽기 버퍼의 크기262144
backup_restore_concurrency각 노드에서 동시에 복원할 슬라이스 수입니다. 자동 선택에는 0을 지정하십시오.0
backup_write_buffer_size_bytes쓰기 버퍼의 크기262144
backup_write_compression_level1(가장 빠름)에서 9(최고 압축)까지의 압축 수준6

백업 명령의 예제

sql> BACKUP db_name1.*, db_name2.tbl_name1, db_name2.tbl_name2 TO 'ftp://storage01/uploads/johndoe+kibbles.jun01'; 
sql> BACKUP *.* EXCLUDING db_name2.tbl_name1 TO 'ftp://storage01/uploads/johndoe.kibbles.jun01';
sql> BACKUP test TO 'sftp://plato:[email protected]:22/tmp/tc5326/tc5326.bkup';

백업 정보 얻기

다음 쿼리는 현재 실행 중인 모든 백업 및 복원의 상태를 보여줍니다.

소스에 있는 모든 백업 표시

sql> SELECT * from system.backups where source="ftp://storage01/uploads"\G
*************************** 1. row **************************
source: ftp://storage01/uploads
backup: 1_52T_large_dogfood_dbx2
cluster_name: cl5d97786267d0d4cb
version: 5.0.45-clustrix-7.5.2
status: ERROR
start_time: 2016-06-15 01:43:36
completed_time: 2016-06-15 03:19:31
size: 0

백업 / 복원 상태 표시

진행 중인 백업에 대한 정보를 보려면 다음 쿼리를 실행하십시오.
sql> select * from system.backup_status\G
*************************** 1. row **************************
nodeid: 2
id: 5756997494884148226
type: BACKUP
url: ftp://storage01/uploads/1_52T_large_dogfood_dbx2_2
objs: (("test" . "")("clustrix_ui" . "")("bugstest_01" ."")("jtunes_01" . "")("longstats_01" . "")("npktest_01" ."")("perfstats_01" . "")("run_resources_01" . "")("statd_01" ."")("bugstest_02" . "")("jtunes_02" . "")("longstats_02" ."")("npktest_02" . "")("perfstats_02" . "")("run_resources_02" ."")("statd_02" . "*"))
start_time: 2016-06-22 22:50:32
expected_bytes: 793977192448
replicas: 1070
rows: 49589227
bytes: 23991322310
1 row in set (0.01 sec)

소스에 있는 백업된 모든 테이블 표시

sql> SELECT * from system.backup_tables where source="ftp://storage01/uploads" limit 2;
+-------------------------+--------------------------+-------------+------------+------+
| source                  | backup                   | db          |table       | size |
+-------------------------+--------------------------+-------------+------------+------+
| ftp://storage01/uploads | 1_52T_large_dogfood_dbx2 | bugstest_01 |attach_data | 0    |
+-------------------------+--------------------------+-------------+------------+------+
| ftp://storage01/uploads | 1_52T_large_dogfood_dbx2 | bugstest_01 |attachments | 0    |
+-------------------------+--------------------------+-------------+------------+------+
2 rows in set (12.16 sec)

Anchor
#Restore
#Restore
복원

다음 구문을 사용하여 이전에 빠른 백업으로 백업한 객체를 복원합니다.

Restore SQL 구문
sql> RESTORE identifier [AS identifier] [, identifier [AS identifier]] [EXCLUDING excluded_identifier] FROM target [LAZY PROTECT] [REPLICAS=N]

identiferexcluded_identifer는 유효한 시스템 객체를 참조해야 합니다. 이것은 FQN(fully qualified name)이거나 데이터베이스, 객체 또는 둘 모두에 대해 와일드카드(*)를 포함할 수 있습니다. 예:

  • db_name.obj_name - 해당 데이터베이스의 특정 객체(즉, 테이블 이름, 뷰 이름)를 참조합니다.
  • db_name.* - 해당 데이터베이스의 액세스 가능한 모든 객체로 확장됩니다.
  • *.* - 시스템의 모든 액세스 가능한 객체로 확장됩니다. (제외된 객체에 대해서는 의미가 없습니다.)

또한, excluded_identifer는 특정 테이블을 지정할 수 있습니다. 예:

  • *.tbl_name - 복원에서 제외할 데이터베이스의 해당 테이블 이름을 참조합니다.

테이블 별칭 [AS identifier]를 제공하여 복원 프로세스 중에 테이블의 이름을 변경할 수 있습니다.

FTP의 서버 경로는 FTP 루트 디렉토리의 상대 경로를 나타내지만 SFTP 서버의 경로는 Linux 루트 디렉토리의 절대 경로이어야 합니다. 예: "ftp://user:[email protected]/relative_path/from_ftp_root" 또는 "sftp://user:[email protected]:absolute_path/from_Linux_root".

Note

EXCLUDING 옵션을 사용한 백업에서 복원할 때는 주의를 기울여야 합니다. 다른 객체가 제외된 객체에 의존하는 경우 복원하는 동안 오류가 발생할 수 있습니다.

예를 들어, 트리거 또는 뷰가 복원된 환경에 존재하지 않는 객체를 참조하면 오류가 발생합니다.

백업에서 제외된 객체를 참조하는 트리거, 뷰 및 외래 키는 객체가 복원된 환경에 있는 경우에만 성공적으로 복원됩니다.

LAZY PROTECT

이 옵션은 RESTORE 명령이 각 슬라이스의 단일 복제본만 작성하도록 합니다. 일단 RESTORE가 완료되면, Rebalancer는 추가로 요청된 수의 복제본을 자동으로 생성합니다.

이 옵션은 RESTORE의 실행 시간을 크게 줄이지만, Rebalancer가 추가 복제본 생성을 마칠 때까지 클러스터는 완전한 데이터 보호 기능을 갖지 않습니다.

예:

sql> RESTORE * FROM 'ftp://storage01/uploads/johndoe.kibbles.jun01' LAZY PROTECT;

이 예제에서는 각 테이블에 대해 하나의 복제본을 만듭니다. 복원이 완료되면 각 테이블의 사양에 따라 추가 복제본이 생성됩니다.

REPLICAS = N

백업된 각 테이블 또는 인덱스에 대해 이전에 존재했던 복제본 수가 백업에 기록됩니다. 일반적으로 RESTORE가 실행될 때, 원본과 동일한 수의 복제본으로 테이블과 인덱스가 복원됩니다. 이 옵션을 사용하면 RESTORE 작업의 일부로 생성해야 하는 복제본의 수를 명시적으로 지정할 수 있습니다.

예를 들어, 백업했을 때 테이블에 세 개의 복제본이 있는 경우 다음 예제는 두 개의 복제본만 가진 테이블을 생성합니다.

sql> RESTORE * FROM 'ftp://storage01/uploads/johndoe.kibbles.jun01' REPLICAS = 2;

이 옵션은 LAZY PROTECT와 같이 사용될 수 있습니다. 예를 들어, 다음 명령은 위와 동일한 테이블을 만들지만, 반환하기 전에 첫 번째 복제본만 만들어집니다. RESTORE가 완료되면 Rebalancer는 각 슬라이스에 대해 하나의 추가 복제본을 만듭니다.

sql> RESTORE * FROM 'ftp://storage01/uploads/johndoe.kibbles.jun01' LAZY PROTECT REPLICAS = 2;

테이블의 복제본 수 지정에 대한 자세한 내용은 Managing Data Distribution 섹션을 참조하십시오.

RESTORE 성능 튜닝

RESTORE를 더 느리게 또는 더 빠르게 튜닝할 수 있습니다.

sql> set global backup_restore_concurrency = desired value;

글로벌 변수 backup_restore_concurrency는 한 번에 해당 노드에 동시에 복원할 수 있는 슬라이스 수를 결정합니다. 기본값은 0이고 이 값은 시스템이 현재 클러스터의 노드 수를 동시 복원 기본값으로 사용하는 것을 의미합니다. 예를 들어, 4로 설정하면 복원 프로세스가 동시에 최대 4개의 슬라이스를 노드에 씁니다.

RESTORE 명령의 예제

sql> RESTORE db_name.tbl_name AS db_name_backup.tbl_name FROM 'ftp://[email protected]/backups/backupfolders/backup_file';
sql> RESTORE tbl_name, tbl_name2, tbl_name3 FROM 'ftp://[email protected]://server.com/backups/backupfolders/backup_file';
sql> RESTORE ehms FROM 'sftp://[email protected]/root/ehmssftp';

BACKUP / RESTORE를 사용하여 복제 문제 해결

빠른 백업 및 복원은 복제된 환경에서 다음 문제를 해결하는 데 사용할 수 있습니다.

시나리오 I: ClustrixDB 슬레이브가 없거나 마스터로 재설정해야 할 경우

  1. 마스터에서 BACKUP SQL 명령을 사용하여 새 백업을 가져옵니다. 이렇게 하면 슬레이브가 마스터와 동기화하는데 필요한 시간을 최소화할 수 있습니다.
  2. 슬레이브가 이미 있으면 슬레이브를 중지합니다. 그렇지 않은 경우, 새로운 ClustrixDB 슬레이브를 생성한 후 중지 모드로 변환합니다. Using ClustrixDB as a SlaveStarting and Stopping a Slave Process를 참조하십시오.
  3. RESTORE 명령을 사용하여 1단계에서 수행한 백업을 슬레이브에 복원합니다.
  4. 백업이 시작될 때 마스터의 binlog 위치가 your_backup_location/metadata/binlogs 파일에 저장됩니다. 이 파일에는 관련 정보가 logfile.seq#:position 형식으로 들어 있습니다 (예: foo1.002843:99744547).
  5. 다음 명령을 실행하여 binlogs 파일에 기록된 위치를 재설정합니다.

sql> CHANGE MASTER TO MASTER_LOG_FILE='foo1.002843', MASTER_LOG_POS=99744547,MASTER_HOST='foo1', MASTER_USER='root', MASTER_PORT=3306;

6. 슬레이브를 시작합니다.

시나리오 II: ClustrixDB Master를 복원해야 하며 ClustrixDB Slave가 양호한 경우

  1. 마스터로 작동하도록 ClustrixDB 슬레이브를 승격합니다. 패시브(passive) ClustrixDB 슬레이브를 활성 마스터 모드로 승격하는데 필요한 단계는 Promoting a ClustrixDB Slave to Master를 참조하십시오.
  2. 시나리오 I에 설명된 단계에 따라 현재 패시브 슬레이브 모드에 있는 이전 마스터를 복원하고 재설정합니다.
  3. 필요하다면 마스터와 슬레이브 간 동기화가 완전히 수행되면 패시브 모드의 슬레이브를 활성 모드의 마스터로 전환하는 단계를 수행합니다.

시나리오 III: ClustrixDB Master 및 Slave 모두를 복원 및 재설정해야 하는 경우

  1. 슬레이브를 중지합니다.
  2. RESTORE 명령을 사용하여 마스터 및 슬레이브를 복원합니다.
  3. 복원이 완료되면 슬레이브가 클라이언트에서 쓰기를 받기 전에 슬레이브를 마스터의 현재 위치(즉, 마스터의 SHOW MASTER STATUS로부터)로 재설정합니다. 이 방법을 사용하면 백업 이후 변경 사항을 잃게 됩니다. 백업 이후 변경 사항을 캡처하는 고급 방법은 binlog가 여전히 사용 가능한 경우 binlog를 재생하고 마스터의 serverid를 변경하여 binlog에 이벤트를 다시 적용하도록 하는 것입니다. 이 고급 절차에 대한 도움이 필요하면 Clustrix 지원팀에 문의하십시오.
  4. 슬레이브를 시작합니다.
Tip

백업 프로세스 중 "Socket timeout while waiting for server response: read_timer" 시간제한 오류가 발생하면 이 오류를 방지하기 위해 글로벌 변수 ftp_read_timeout_secs를 최대 3000까지 증가시킬 수 있습니다. 이 글로벌 변수의 기본값은 600이고 FTP 및 SFTP 서버의 백업 및 복원에 적용됩니다.

Mysqldump

ClustrixDB의 덤프를 만들려면 mysqldump 유틸리티를 사용하십시오. 해당 유틸리티는 클러스터의 각 노드에 포함되어 있습니다. Slave로 덤프를 가져오려면 덤프를 생성하기 전에 복제 스트림용 바이너리 로그를 생성하십시오.

덤프를 생성하려면 다음 명령을 실행하십시오.

shell> mysqldump -u user -h clustrix host --single-transaction --master-data=2 --all-databases > mydumpfile.dump
  • --single-transaction 플래그는 단일 트랜잭션에서 모든 데이터를 쿼리하여 데이터베이스의 일관된 스냅샷을 보장하고 덤프가 생성되는 동안 ClustrixDB에 대한 지속적인 액세스를 허용합니다.
  • --master-data=2 플래그는 덤프 파일의 상단 주석에 CHANGE MASTER 명령을 삽입하며 이는 슬레이브가 동기화를 시작할 바이너리 로그 위치를 나타냅니다. binlog가 생성되지 않으면 --master-data 플래그를 생략하십시오.

추가 리소스

FTP Server Setup for Fast Backup and Restore

List of Errors for Backup and Restore