OpenGauss Backup and Restoration Overview
Currently, Gaussian backup includes physical backup and logical backup. Physical backup supports only full backup, not incremental backup. The PITR function is not supported, so backup data cannot be used for roll forward recovery.
The physical backup
The goal of gs_baseBackup is to copy the binary of server database files using the replication protocol. To remotely execute gs_basebackup, you need to use the system administrator account. Gs_basebackup Currently supports only hot backup but does not support compressed backup.
Description:
- Gs_basebackup supports only full backup, not incremental backup.
- Gs_basebackup Currently supports only hot backup but does not support compressed backup.
- Gs_basebackup When backing up tablespaces containing absolute paths, the backup cannot be performed on the same machine. For the same machine, the absolute path is unique, so conflicts can occur. Table Spaces with absolute paths can be backed up on different machines.
– If the incremental detection point function is enabled and dual-write is enabled, gs_baseBackup also backs up dual-write files. – If the pg_xlog directory is a soft link, data is backed up to the pg_xlog directory of the destination path instead of a soft link.
The premise condition
- The openGauss database can be connected normally, and the number of max_wal_senders must be configured in pg_hba.conf. At least one max_wal_senders is available.
- During restoration, ensure that the backup file exists in the backup directory of each node. If the backup file is lost, copy the backup file from other nodes.
The sample
Gs_basebackup Supports remote backup and connects to the database through the IP port:
Backup files are all files in the data directory:
[omm@gsnode2backup]$ pwd /home/omm/backup [omm@gsnode2backup]$ ls backup_label build_completed.done global pg_clog pg_ctl.lock pg_hba.conf.bak pg_llog pg_replslot pg_stat_tmp PG_VERSION postgresql.conf.bak server.crt server.key.rand backup_label.old cacert.pem gswlm_userinfo.cfg pg_copydir pg_errorinfo pg_hba.conf.lock pg_multixact pg_serial pg_tblspc pg_xlog postgresql.conf.lock server.key term_file base full_backup_label mot.conf pg_csnlog pg_hba.conf pg_ident.conf pg_notify pg_snapshots pg_twophase postgresql.conf rewind_lable server.key.cipher wdr_report.htmlCopy the codeRestore data from backup files
When a database fails, you need to restore it from the backup file. Because gs_baseBackup backs up the database in binary mode, you can directly copy and replace the original files or directly start the database on the backup library.
Note: – If the current database instance is running, starting the database directly from the backup file may cause port conflict. This is to modify the port parameter of the configuration file, or specify the port when starting the database. – If the backup file is currently in the active and standby databases, you may need to modify the replication connection between the active and standby databases. That is, replConnInfo1 and ReplConnInfo2 in postgre.conf of the configuration file
To restore the database in place of the original library, follow the steps below:
1. Stop the database server. For details, see Administrator Guide. 2.
2. Copy the original database and all tablespaces to another location for later use
3. Clear all or some files from the original library
4. Restore the required database files from the backup file using the database system user permission
5. If the link file exists in the database, modify the link file to the correct one.
6. Restart the database server and check the database to ensure that the database is restored to the required status.
Note: – Incremental restoration of backup files is not supported. – After restoration, check whether the linked files in the database are connected to the correct files
Stop the original library:
[omm@gsnode1 db1]$gs_om -t stop -h gsnode1 Stopping node. ========================================= Successfullystopped node. ========================================= End stop node. [omm@gsnode1 db1]$gs_om -t status --detail [ Cluster State ] cluster_state : Unavailable redistributing : No current_az : AZ_ALL [ Datanode State ] node node_ip instance state | node node_ip instance state ------------------------------------------------------------------------------------------------------------------------ -- -- -- -- -- -- -- -- -- -- -- -- -- -- 1 gsnode1 192.168.150.101 6001 / gsdata/db1 PDown Manually stopped | 2 gsnode2 192.168.150.102 6002 /gsdata/db1 SStandby Need repair(Disconnected)Copy the codeFirst restore the file
mv db1 db2
scp -rgsnode2:/home/omm/backup/ .
mv backup db1
Copy the codeTry to start the database:
[omm@gsnode1gsdata]$ gs_om -t status --detail [ Cluster State ] cluster_state : Degraded redistributing : No current_az : AZ_ALL [ Datanode State ] node node_ip instance state | node node_ip instance state ------------------------------------------------------------------------------------------------------------------------ -- -- -- -- -- -- -- -- -- -- -- -- -- -- 1 gsnode1 192.168.150.101 6001 / gsdata/db1 PPrimary Normal gsnode2192.168.150.102 6002 / gsdata db1 S | 2 Standby Need repair(WAL)Copy the codeAfter the host is restored, the logs of the standby host cannot be synchronized. Therefore, the standby host needs to be rebuilt. And only in Full mode:
[omm@gsnode2backup]$ gs_ctl build -D /gsdata/db1 -b full
[2020-07-1410:22:05.499][70179][][gs_ctl]: gs_ctl full build ,datadir is -D"/gsdata/db1"
[2020-07-1410:22:05.499][70179][][gs_ctl]: stop failed, killing gaussdb by force ...
[2020-07-1410:22:05.499][70179][][gs_ctl]: command [ps c -eo pid,euid,cmd | grep gaussdb |grep -v grep | awk '{if($2 == curuid && $1!="-n") print"/proc/"$1"/cwd"}' curuid=`id -u`| xargs ls -l | awk '{if($NF=="/gsdata/db1") print$(NF-2)}' | awk -F/ '{print $3 }' | xargs kill -9 >/dev/null 2>&1 ]path: [/gsdata/db1]
[2020-07-1410:22:05.551][70179][][gs_ctl]: server stopped
[2020-07-1410:22:05.552][70179][][gs_ctl]: set gaussdb state file when full build:dbstate(BUILDING_STATE), server mode(STANDBY_MODE), build mode(FULL_BUILD).
gs_ctl: set theconnection xc_maintenance_mode to on error.
[2020-07-1410:22:05.720][70179][dn_6001_6002][gs_ctl]: check connect to server success
[2020-07-1410:22:06.012][70179][dn_6001_6002][gs_ctl]: clear old target dir success
[2020-07-1410:22:06.027][70179][dn_6001_6002][gs_ctl]: connect to server success, buildstarted.
[2020-07-1410:22:06.027][70179][dn_6001_6002][gs_ctl]: create build tag file success
[2020-07-1410:22:06.028][70179][dn_6001_6002][gs_ctl]: get system identifier success
[2020-07-1410:22:06.033][70179][dn_6001_6002][gs_ctl]: receiving and unpacking files...
[2020-07-1410:22:06.033][70179][dn_6001_6002][gs_ctl]: create backup label success
[2020-07-1410:22:06.584][70179][dn_6001_6002][gs_ctl]: xlog start point: 0/20000028
[2020-07-1410:22:06.584][70179][dn_6001_6002][gs_ctl]: begin build tablespace list
[2020-07-1410:22:06.584][70179][dn_6001_6002][gs_ctl]: finish build tablespace list
[2020-07-1410:22:06.584][70179][dn_6001_6002][gs_ctl]: begin get xlog by xlogstream
[2020-07-1410:22:06.584][70179][dn_6001_6002][gs_ctl]: starting background WAL receiver
[2020-07-1410:22:06.584][70179][dn_6001_6002][gs_ctl]: starting walreceiver
[2020-07-1410:22:06.584][70179][dn_6001_6002][gs_ctl]: begin receive tar files
[2020-07-1410:22:06.585][70179][dn_6001_6002][gs_ctl]: receiving and unpacking files...
[2020-07-1410:22:06.616][70179][dn_6001_6002][gs_ctl]: check identify system success
[2020-07-1410:22:06.617][70179][dn_6001_6002][gs_ctl]: send START_REPLICATION 0/20000000 success
keepalive message is received
keepalive message is received
[2020-07-1410:22:07.877][70179][dn_6001_6002][gs_ctl]: finish receive tar files
[2020-07-1410:22:07.877][70179][dn_6001_6002][gs_ctl]: xlog end point: 0/200001D0
[2020-07-1410:22:07.877][70179][dn_6001_6002][gs_ctl]: waiting for background process tofinish streaming...
[2020-07-1410:22:07.901][70179][dn_6001_6002][gs_ctl]: fetching MOT checkpoint
[2020-07-1410:22:07.928][70179][dn_6001_6002][gs_ctl]: build dummy dw file success
[2020-07-14 10:22:07.928][70179][dn_6001_6002][gs_ctl]:rename build status file success
[2020-07-1410:22:07.928][70179][dn_6001_6002][gs_ctl]: build completed(/gsdata/db1).
[2020-07-1410:22:08.007][70179][dn_6001_6002][gs_ctl]: waiting for server to start...
.0 [BACKEND]LOG: Begin to start openGauss Database.
2020-07-1410:22:08.158 5f0d16d0.1 [unknown] 140580179332864 [unknown] 0 dn_6001_6002DB001 0 [REDO] LOG: Recoveryparallelism, cpu count = 4, max = 4, actual = 4
2020-07-1410:22:08.158 5f0d16d0.1 [unknown] 140580179332864 [unknown] 0 dn_6001_6002DB001 0 [REDO] LOG: ConfigRecoveryParallelism, true_max_recovery_parallelism:4,max_recovery_parallelism:4
2020-07-1410:22:08.158 5f0d16d0.1 [unknown] 140580179332864 [unknown] 0 dn_6001_600200000 0 [BACKEND] LOG: Transparentencryption disabled.
2020-07-1410:22:08.171 5f0d16d0.1 [unknown] 140580179332864 [unknown] 0 dn_6001_600200000 0 [BACKEND] LOG: InitNumanumaNodeNum: 1 numa_distribute_mode: none inheritThreadPool: 0.
2020-07-1410:22:08.171 5f0d16d0.1 [unknown] 140580179332864 [unknown] 0 dn_6001_600200000 0 [BACKEND] LOG: shared memory1857 Mbytes, memory context 2110 Mbytes, max process memory 4096 Mbytes
2020-07-1410:22:08.171 5f0d16d0.1 [unknown] 140580179332864 [unknown] 0 dn_6001_600200000 0 [BACKEND] LOG: Initilize thememory protect with Process Chunks number 2110, change bits 20
2020-07-1410:22:08.205 5f0d16d0.1 [unknown] 140580179332864 [unknown] 0 dn_6001_600200000 0 [CACHE] LOG: set data cache size(100663296)
2020-07-1410:22:08.210 5f0d16d0.1 [unknown] 140580179332864 [unknown] 0 dn_6001_600200000 0 [CACHE] LOG: set metadatacache size(33554432)
2020-07-1410:22:08.553 5f0d16d0.1 [unknown] 140580179332864 [unknown] 0 dn_6001_600200000 0 [BACKEND] LOG: gaussdb: fsyncfile "/gsdata/db1/gaussdb.state.temp" success
2020-07-1410:22:08.553 5f0d16d0.1 [unknown] 140580179332864 [unknown] 0 dn_6001_600200000 0 [BACKEND] LOG: create gaussdbstate file success: db state(STARTING_STATE), server mode(Standby)
2020-07-1410:22:08.576 5f0d16d0.1 [unknown] 140580179332864 [unknown] 0 dn_6001_600200000 0 [BACKEND] LOG: max_safe_fds =976, usable_fds = 1000, already_open = 14
2020-07-1410:22:08.579 5f0d16d0.1 [unknown] 140580179332864 [unknown] 0 dn_6001_600200000 0 [BACKEND] LOG: Success to startopenGauss Database, please press any key to exit...
[2020-07-1410:22:09.036][70179][dn_6001_6002][gs_ctl]: done
[2020-07-1410:22:09.036][70179][dn_6001_6002][gs_ctl]: server started (/gsdata/db1)
Copy the codeLogical backup
There are three built-in tools related to logical backup and recovery :gs_dump gs_dumpall gs_restore. Another tool, gs_backup, is used to backup important binaries and database configuration files in software.
gs_dump
Background information
Gs_dump is a tool used by openGauss to export database information. You can export a database or its objects (such as schemas, tables, and views) by yourself. The database that can be exported can be the default database Postgres or a custom database.
Gs_dump is run by OS user omm.
When gs_dump is exporting data, other users can access the openGauss database (read or write).
Gs_dump allows you to export complete and consistent data. For example, if gs_dump is started at time T1 to export database A, the exported data will be the data status of database A at time T1. Changes made to database A after time T1 will not be exported.
Gs_dump can export database information to SQL scripts or other archive files in plain text format.
[omm@gsnode2 ~]$gs_basebackup -D home/omm/backup/ -P -v -h 192.168.150.101 -p 26000 -U omm -Womm@123456
gs_basebackup: toomany command-line arguments (first is "omm@123456")
Try"gs_basebackup --help" for more information.
[omm@gsnode2 ~]$gs_basebackup -D home/omm/backup/ -P -v -h 192.168.150.101 -p 26000 -U omm -W
Password:
INFO: The starting position of the xlog copy of thefull build is: 0/1D89E000. The slot minimum LSN is: 0/1D89E000.
transaction logstart point: 0/1D89E000
begin buildtablespace list
finish buildtablespace list
begin get xlog byxlogstream
gs_basebackup:starting background WAL receiver
check identify system successce(/home/omm/backup/backup_label )
send START_REPLICATION 0/1D000000 success
keepalive message is received
keepalive message is receivedespace (/home/omm/backup/base/14790/14)
keepalive message is receivedblespace(/home/omm/backup/base/14790/25)
keepalive message is receivedblespace(/home/omm/backup/gswlm_userinf)
302195/302195 kB(100%), 1/1 tablespace
transaction log endpoint: 0/1E000160
gs_basebackup:waiting for background process to finish streaming...
gs_basebackup:fetch mot checkpoint
gs_basebackup: nomot checkpoint exists
gs_basebackup: basebackup completed
Copy the code- Plain text SQL script file: Contains THE SQL statements needed to restore the database to the state it was saved in. You can restore the database by running the SQL script file through GSQL. Even on other hosts and other database products, minor changes to SQL script files can be used to rebuild databases.
- Archive format file: Contains data needed to restore the database to its saved state. It can be in tar, directory archive, or custom archive format, as shown in Table 1. The export results must be used in conjunction with gs_Restore to restore the database. The gs_Restore tool allows users to select what needs to be imported at import time and even sort the content waiting to be imported before importing.