Khó Chịu Trong Lòng

  Theory The restore command automatically defaults to selecting the latest backup from the first repository where backups exist. The order in which the repositories are checked is dictated by the pgbackrest.conf (e.g. repo1 will be checked before repo2). To select from a specific repository, the --repo option can be passed (e.g. --repo=1). The --set option can be passed if a backup other than the latest is desired. Restoration Scenarios: Restoring the backup on a different host Restoring a single database from the Postgres cluster Restoring the backup to a specific point in time Restoring only the delta changes Restoring the backup on a different host to start as a streaming standby 1. Verify backup information [enterprisedb@edb-nhatrang ~]$ pgbackrest info --stanza=employees 2. Restoring the backup on a different host (IP : 192.168.56.77) Setup Passwordless SSH Connection between Backup Server (192.168.56.79) and Database Server (192.168.56.77) Backup Server  ss...

Theory A stanza is the configuration for a PostgreSQL database cluster that defines where it is located, how it will be backed up, archiving options, etc. Most db servers will only have one PostgreSQL database cluster and therefore one stanza, whereas backup servers will have a stanza for every database cluster that needs to be backed up. The stanza-delete command removes data in the repository associated with a stanza. Use this command with caution — it will permanently remove all backups and archives from the pgBackRest repository for the specified stanza. A. CONFIGURATION 1. Create backup location [root@edb-nhatrang /]# mkdir -p /backup/pgbackrest [root@edb-nhatrang /]# chown -R enterprisedb: /backup/ 2. Database Cluster Configuration Enable archive mode ON Set archive_command = ‘pgbackrest --stanza=employees archive-push %p’ Get data_directory = ‘/u01/edb/as16/data’ edb=# show archive_mode ;  archive_mode  --------------  on (1 row) edb=# show archive_command ...

Theory : The method based on global transaction identifiers (GTIDs) is transactional and therefore does not require working with log files or positions within these files, which greatly simplifies many common replication tasks.  Replication using GTIDs guarantees consistency between source and replica as long as all transactions committed on the source have also been applied on the replica. Enabling log-slave-updates on a replica means, the replica writes updates that are received from a master to its own binary logs. So a replica can become a intermediate master of another replica. This option is a stepping stone for various simple to complex level replication setups and new technologies like Group Replication. 1. General information Master Node 01 IP : 192.168.56.59 Hostname : edb-saigon.taolaoxibup.com OS : Red Hat Enterprise Linux release 9.4 (Plow) MySQL version : Ver 8.0.37-commercial for Linux on x86_64 (MySQL Enterprise Server - Commercial) mysql> show databases; +----...

Theory : The traditional method is based on replicating events from the source's binary log, and requires the log files and positions in them to be synchronized between source and replica. 1. General information Master Node IP: 192.168.56.59 Hostname: edb-saigon.taolaoxibup.com OS: Red Hat Enterprise Linux release 9.4 (Plow) MySQL version: Ver 8.0.37-commercial for Linux on x86_64 (MySQL Enterprise Server - Commercial) Slave Node IP: 192.168.56.29 Hostname: edb-hanoi.taolaoxibup.com OS: Red Hat Enterprise Linux release 9.4 (Plow) MySQL version: Ver 8.0.37-commercial for Linux on x86_64 (MySQL Enterprise Server - Commercial) 2. Preparation on Master/Slave Node Turn off Firewall Disable SELinux Configuring /etc/hosts 192.168.56.59   edb-saigon.taolaoxibup.com     edb-saigon 192.168.56.29   edb-hanoi.taolaoxibup.com       edb-hanoi 3. Update Master/Slave Server config file Master Node [root@mysql-saig...