In questo tutorial creerai un database dimostrativo ed eseguirai un carico di lavoro dell'applicazione. Quindi, configurerai i processi di archiviazione e backup. Ora imparerai a verificare i processi di backup, archiviazione e ripristino. Infine, imparerai come recuperare il database in un momento specifico.
Questo tutorial è destinato ad amministratori di database, operatori di sistema, professionisti DevOps e Cloud Architect interessati a configurare una strategia di backup e ripristino per i database PostgreSQL.
Questo tutorial presuppone che tu abbia familiarità con i container Docker e che tu abbia dimestichezza con i comandi Linux, i motori di database PostgreSQL e Compute Engine.
Obiettivi
- Configura un processo di backup e archiviazione.
- Esegui un PITR.
- Monitora il backup.
- Verifica un ripristino.
Costi
In questo documento vengono utilizzati i seguenti componenti fatturabili di Google Cloud:
Per generare una stima dei costi in base all'utilizzo previsto,
utilizza il Calcolatore prezzi.
Una volta completate le attività descritte in questo documento, puoi evitare la fatturazione continua eliminando le risorse che hai creato. Per ulteriori informazioni, consulta la pagina Pulizia.
Prima di iniziare
- Accedi al tuo account Google Cloud. Se non conosci Google Cloud, crea un account per valutare le prestazioni dei nostri prodotti in scenari reali. I nuovi clienti ricevono anche 300 $di crediti gratuiti per l'esecuzione, il test e il deployment dei carichi di lavoro.
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Assicurati che la fatturazione sia attivata per il tuo progetto Google Cloud.
-
Abilita le API Compute Engine and Cloud Storage.
- Installa Google Cloud CLI.
-
Per initialize gcloud CLI, esegui questo comando:
gcloud init
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Assicurati che la fatturazione sia attivata per il tuo progetto Google Cloud.
-
Abilita le API Compute Engine and Cloud Storage.
- Installa Google Cloud CLI.
-
Per initialize gcloud CLI, esegui questo comando:
gcloud init
-
Nella console Google Cloud, attiva Cloud Shell.
Nella parte inferiore della console Google Cloud viene avviata una sessione di Cloud Shell che mostra un prompt della riga di comando. Cloud Shell è un ambiente shell con Google Cloud CLI già installato e con valori già impostati per il progetto attuale. L'inizializzazione della sessione può richiedere alcuni secondi.
Concetti
Prima di iniziare il tutorial, rivedi i seguenti concetti di PostgreSQL:
- Archiviazione continua. Quando il database salva continuamente transazioni sequenziali in un file.
- WAL (Write Ahead Log). Le modifiche apportate ai file di dati vengono registrate nel WAL prima di essere apportate al file.
- Record WAL. Ogni transazione applicata al database viene formattata e archiviata come record WAL.
- File di segmenti. I file di segmento hanno nomi file in aumento monotonico e contengono il maggior numero possibile di record WAL. La dimensione del file è configurabile con un valore predefinito di 16 MiB. Puoi scegliere una dimensione maggiore se prevedi che le transazioni voluminose in termini di dimensioni o conteggio per ridurre il numero aggregato di file di segmento generati e per ridurre il carico della gestione dei file.
Per maggiori informazioni, consulta Affidabilità e log write-ahead.
Il seguente diagramma mostra come i WAL vengono persistenti in due fasi.
Nel diagramma precedente, la prima fase dei WAL permanenti è composta dalle transazioni di scrittura della registrazione del motore del database nel buffer WAL in concomitanza con la scrittura in una tabella. Quando viene eseguito il commit della transazione, il buffer WAL viene scritto (svuotato) su disco durante la seconda fase con un'aggiunta al file del segmento WAL.
Scelta di un PITR
Un PITR è appropriato per i seguenti scenari:
- Riduci al minimo il Recovery Point Objective (RPO). L'RPO è il tempo massimo di perdita di dati tollerato prima che abbia un impatto significativo sui processi aziendali. Il salvataggio di tutte le transazioni nei WAL tra snapshot di backup riduce drasticamente la quantità di dati persi in quanto sono presenti le transazioni dall'ultimo backup completo da applicare al database.
- Riduci al minimo l'RTO (Recovery Time Objective). L'RTO è la quantità di tempo necessaria per recuperare un database in caso di un evento distruttivo. Dopo aver configurato i backup binari e l'archiviazione dei log, il tempo necessario per recuperare il database può essere minimo.
- Soluzione per un bug di danneggiamento dei dati o un errore amministrativo. Se una release del codice causa un catastrofico danneggiamento dei dati o viene commesso un errore irreversibile durante la manutenzione di routine, puoi eseguire il ripristino prima di quel momento.
In alcune architetture delle applicazioni, come le architetture basate su microservizi, potrebbero essere presenti database paralleli che potrebbero richiedere recuperi indipendenti. Ad esempio, un'applicazione di vendita al dettaglio potrebbe avere dati dei clienti in un database e dettagli degli ordini di vendita al dettaglio e informazioni sull'inventario in altri database. A seconda dello stato complessivo dei dati, potrebbe essere necessario ripristinare uno, due o tutti i database in parallelo.
Un PITR non è appropriato nei seguenti scenari:
- L'RPO è elevato. Se il criterio di ripristino di emergenza può tollerare la perdita di transazioni ricevute dopo lo snapshot recente, puoi evitare ulteriori passaggi e concentrarti sulla riduzione del tempo per il recupero dei dati.
- È necessario un ripristino completo del database. Se il tuo obiettivo è recuperare fino alla transazione più recente, il target di recupero è il timestamp dell'ultima transazione persistente. Questo scenario è un caso specifico di PITR, ma semanticamente questo obiettivo è definito recupero completo.
Considerazioni sul rendimento
Il processo di archiviazione applica un carico I/O aggiuntivo sul server del database. Il carico aggiuntivo dipende dalle caratteristiche del carico di lavoro perché è proporzionale al volume delle transazioni di scrittura, aggiornamento ed eliminazione.
Se vuoi ridurre l'impatto di I/O che l'attività di archiviazione WAL potrebbe comportare sul tuo database principale, puoi eseguire gli archivi WAL periodici utilizzando una replica di sola lettura.
Questa configurazione isola il database principale dalle attività di I/O orientate al batch relative al trasferimento dei file WAL. Le transazioni destinate alla replica di sola lettura vengono trasmesse in un flusso costante dal database principale, il che richiede un impatto molto inferiore sulla velocità effettiva in stato stabile.
Inoltre, se la topologia del database di produzione include già una replica di sola lettura, questa configurazione non comporta alcun carico aggiuntivo: gestione, prezzo o altro.
Architettura di riferimento
Il seguente diagramma illustra l'architettura implementata in questo tutorial.
In questo tutorial creerai un'infrastruttura cloud per osservare un PITR che utilizza i seguenti componenti:
- Un server di database PostgreSQL in esecuzione su Compute Engine.
- Cloud Storage per l'archiviazione di snapshot e log delle transazioni.
Il seguente diagramma mostra i due container Docker avviati sulla macchina virtuale (VM) del database PostgreSQL. Per separazione dei problemi, il server di database è in esecuzione in uno dei container e l'archivio WAL è in esecuzione nell'altro container.
Questo diagramma mostra come i volumi Docker in ciascun container sono mappati ai punti di montaggio Persistent Disk sulla VM host.
Configurazione delle variabili di ambiente
Gli script e i comandi utilizzati in questo tutorial si basano sulle variabili dell'ambiente shell.
In Cloud Shell, imposta le variabili di ambiente per il progetto, il nome dell'istanza e il database PostgreSQL dimostrativo.
export PROJECT_ID=your-gcp-project export PG_INSTANCE_NAME=instance-pg-pitr export POSTGRES_PASSWORD=PasswordIsThis export POSTGRES_PITR_DEMO_DBNAME=pitr_demo
Sostituisci quanto segue:
your-gcp-project
: il nome del progetto creato per questo tutorial.PasswordIsThis
: una password sicura per il database PostgreSQL.
Imposta la variabile di ambiente per la zona Google Cloud. Sostituisci
choose-an-appropriate-zone
con una zona Google Cloud.export ZONE=choose-an-appropriate-zone export REGION=${ZONE%-[a-z]}
Imposta la variabile di ambiente per la subnet Virtual Private Cloud (VPC) predefinita per la regione della tua zona:
export SUBNETWORK_URI=$(gcloud compute networks subnets \ describe default --format=json --region=$REGION | \ jq --raw-output '.ipCidrRange')
Imposta la variabile di ambiente per il bucket Cloud Storage. Sostituisci
archive-bucket
con un nome univoco per il bucket Cloud Storage in cui vengono salvati i WAL.export ARCHIVE_BUCKET=archive-bucket
Creazione di un bucket Cloud Storage
Crea un bucket Cloud Storage per archiviare i file WAL dal database PostgreSQL:
gsutil mb gs://${ARCHIVE_BUCKET}
Consentire l'accesso alle istanze degli indirizzi IP privati
Per le istanze utilizzate in questo tutorial, come in molti casi d'uso in produzione, non è necessario che le istanze VM ottengano gli indirizzi IP pubblici. Tuttavia, le istanze richiedono l'accesso alla rete internet pubblica per eseguire il pull delle immagini container di esempio e l'accesso è necessario per connetterti utilizzando una shell sicura. Configuri un gateway NAT (Network Address Translation) e configuri Identity-Aware Proxy (IAP) per l'inoltro TCP.
Crea un gateway NAT
Poiché le istanze VM che crei non hanno indirizzi IP pubblici, devi creare un gateway NAT in modo che le istanze possano estrarre le immagini container dall'hub Docker.
In Cloud Shell, crea un router Cloud:
export CLOUD_ROUTER_NAME=${PROJECT_ID}-nat-router gloud compute routers create $CLOUD_ROUTER_NAME \ --network=default --region=$REGION
Crea il gateway NAT:
gcloud compute routers nats create ${PROJECT_ID}-nat-gateway \ --region=$REGION \ --router=$CLOUD_ROUTER_NAME \ --auto-allocate-nat-external-ips \ --nat-all-subnet-ip-ranges
Configura IAP per l'inoltro TCP
IAP controlla l'accesso alle applicazioni cloud e alle VM in esecuzione su Google Cloud. IAP verifica l'identità dell'utente e il contesto della richiesta per determinare se un utente può accedere a una VM.
In Cloud Shell, consenti il traffico dal blocco di rete di forwarding TCP alle istanze nel tuo progetto:
export IAP_FORWARDING_CIDR=35.235.240.0/20 gcloud compute --project=$PROJECT_ID firewall-rules create \ cloud-iap-tcp-forwarding --direction=INGRESS \ --priority=1000 --network=default \ --action=ALLOW --rules=all \ --source-ranges=$IAP_FORWARDING_CIDR
Per connetterti utilizzando un tunnel di inoltro TCP, aggiungi un'associazione di criteri di Identity and Access Management (IAM). Sostituisci
your-email-address
con l'indirizzo email che utilizzi per accedere alla console Google Cloud.export GRANT_EMAIL_ADDRESS=your-email-address gcloud projects add-iam-policy-binding $PROJECT_ID \ --member=user:$GRANT_EMAIL_ADDRESS \ --role=roles/iap.tunnelResourceAccessor
Creazione dell'infrastruttura di database PostgreSQL
In Cloud Shell, clona il repository di codice sorgente che contiene gli script di configurazione e modifica il contesto della shell nel repository locale:
git clone https://github.com/GoogleCloudPlatform/gcs-postgresql-recovery-tutorial cd gcs-postgresql-recovery-tutorial
Per creare e configurare l'istanza VM del database, esegui questo script:
cd bin ./create_postgres_instance.sh
Per questo tutorial, questo script avvia un'istanza VM nella zona scelta con il sistema operativo ottimizzato per i container e due nuovi dischi permanenti collegati. In questo caso, puoi ignorare il messaggio di avviso restituito dall'API sulle scarse prestazioni di I/O perché gli script creano dischi permanenti di piccole dimensioni.
Revisione della configurazione di cloud-init
Cloud-init è un pacchetto di distribuzione multipla che inizializza un'istanza Cloud.
Esamina il seguente esempio di codice cloud-init:
Per questo tutorial, cloud-init viene utilizzato per:
- Creare due dispositivi di archiviazione a blocchi su Persistent Disk.
- Crea i file system sui due dispositivi: uno per i dati e uno per i log di archiviazione.
- Monta i dispositivi in punti di montaggio logici sull'istanza VM che sono condivisi con i container Docker.
- Crea e avvia un servizio
systemd
(postgres.service
), che avvia un container Docker PostgreSQL con quanto segue:- I dischi permanenti montati come volumi.
- La porta PostgreSQL (
5432
) pubblicata nell'host della VM.
- Crea un file
/var/tmp/docker-entrypoint-initdb.d/init-pitr-demo-db.sql
per creare un semplice insieme di tabelle in un database e in uno schema dimostrativo. - Crea e avvia un secondo servizio
systemd
(wal_archive.service
) che esegue un container Docker di Google Cloud CLI con i dischi WAL montati come volume. Questo servizio esegue il backup dei file WAL archiviati in Cloud Storage. - Creare, abilitare e avviare un timer
systemd
(wal_archive.timer
) che esegue periodicamentewal_archive.service
. - Assicurati che la porta PostgreSQL (
5432
) sia aperta per la subnet VPC in modo che il generatore di transazioni possa raggiungere la porta del database.
Modifica la configurazione dell'istanza di database
Il server di database è in esecuzione, ma devi configurare l'accesso alla rete e avviare il processo di archiviazione WAL.
Connettiti all'istanza VM del database
Nella console Google Cloud, vai alla pagina Istanze VM.
Per aprire una shell di terminale, fai clic su SSH accanto all'istanza
instance-pg-pitr
che hai creato.Nella shell del terminale, verifica che il container Docker sia stato avviato:
docker ps
L'output è simile al seguente:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 8bb65d8c1197 postgres:11-alpine "docker-entrypoint.s…" About a minute ago Up About a minute postgres-db
Se il container non è ancora in esecuzione, attendi un istante, quindi utilizza lo stesso comando per ricontrollare.
Consenti connessioni di rete in entrata al database
Nella shell del terminale dell'istanza
instance-pg-pitr
, apri il file di configurazione dell'autenticazione basata su host di PostgreSQL per modificarlo:sudoedit /mnt/disks/data/pgdata/pg_hba.conf
Per rimuovere l'accesso predefinito al database con tutti gli indirizzi IP, commenta la seguente riga alla fine del file aggiungendo
#
all'inizio della riga. La riga del file è simile alla seguente:#host all all all md5
Per consentire le connessioni protette da password dagli host nel blocco CIDR
10.0.0.0/8
, aggiungi la seguente riga alla fine del file:host all all 10.0.0.0/8 md5
Questa voce consente la connettività dalla subnet VPC in cui viene successivamente creato il generatore di transazioni.
Salva e chiudi il file.
Configurare l'archiviazione WAL
Nella shell del terminale dell'istanza
instance-pg-pitr
, modifica il filepostgresql.conf
:sudoedit /mnt/disks/data/pgdata/postgresql.conf
Sostituisci le righe
archive_mode
,archive_command
earchive_timeout
commentate esistenti con quanto segue:archive_mode=on archive_command = '( ARCHIVE_PATH=/var/lib/postgresql/wal/pg_wal_archive; test ! -f $ARCHIVE_PATH/%f && cp %p $ARCHIVE_PATH/%f.cp && mv $ARCHIVE_PATH/%f.cp $ARCHIVE_PATH/%f ) ' archive_timeout = 120
Quando sostituisci le righe del file modificato, l'aspetto è simile al seguente snippet di codice:
Salva e chiudi il file.
Applicare e verificare le modifiche alla configurazione
Nella shell del terminale dell'istanza
instance-pg-pitr
, riavvia il container per applicare le modifiche:sudo systemctl restart postgres
Verifica i file di segmenti WAL:
sudo ls -l /mnt/disks/wal/pg_wal
L'output è simile al seguente:
total 16388 -rw------- 1 postgres 70 16777216 Sep 5 23:07 000000010000000000000001 drwx------ 2 postgres 70 4096 Sep 5 23:05 archive_status
Verifica la connettività di rete al database:
export LOCAL_IP=127.0.0.1 docker exec postgres-db psql -w --host=$LOCAL_IP \ --command='SELECT 1'
L'output è simile al seguente:
?column? ---------- 1 (1 row)
Chiudi la connessione SSH all'istanza.
Avvio del generatore di transazioni per completare il database
I passaggi seguenti avviano un programma Go che genera transazioni per questo tutorial. Il programma viene eseguito all'interno di un container su un'istanza VM.
L'immagine per il container è già stata creata e ospitata in un progetto con un Container Registry pubblico.
In Cloud Shell, passa alla directory del generatore di transazioni:
cd ~/gcs-postgresql-recovery-tutorial/bin
Imposta le variabili di ambiente:
export TRANS_GEN_INSTANCE_NAME=instance-trans-gen export POSTGRES_HOST_IP=$(gcloud compute instances describe \ --format=json --zone=${ZONE} ${PG_INSTANCE_NAME} | \ jq --raw-output '.networkInterfaces[0].networkIP')
Per eseguire il generatore di transazioni, avvia l'istanza:
./run_trans_gen_instance.sh
Ignora il messaggio di avviso relativo alle scarse prestazioni di I/O.
Attendi qualche istante e verifica che le transazioni raggiungano il database PostgreSQL:
gcloud compute ssh $PG_INSTANCE_NAME \ --tunnel-through-iap \ --zone=$ZONE \ --command="docker exec postgres-db psql \ --dbname=$POSTGRES_PITR_DEMO_DBNAME \ --command='SELECT COUNT(*) FROM pitr_db_schema.customer;'"
L'output contiene un conteggio maggiore di 0 quando il generatore di transazioni aggiunge record al database:
count ------- 413 (1 row)
Configurazione della pianificazione del backup degli snapshot binari
Puoi eseguire il backup dei dischi permanenti in base a una pianificazione e conservarli per un periodo di tempo definito nel criterio delle risorse.
Crea la pianificazione di snapshot
In Cloud Shell, imposta le variabili di ambiente:
export ZONE=zone-of-your-instance export SNAPSHOT_SCHEDULE_NAME=pg-disk-schedule export REGION=${ZONE%-[a-z]} export SNAPSHOT_WINDOW_START=$(TZ=":GMT" date "+%H:00") export SNAPSHOT_RETENTION_DAYS=2 export SNAPSHOT_FREQUENCY_HOURS=1
Sostituisci zone-of-your-instance con la zona Google Cloud in cui hai avviato in precedenza la VM del database.
Crea la pianificazione di snapshot:
gcloud compute resource-policies create snapshot-schedule \ $SNAPSHOT_SCHEDULE_NAME \ --region=$REGION \ --max-retention-days=$SNAPSHOT_RETENTION_DAYS \ --on-source-disk-delete=apply-retention-policy \ --hourly-schedule=$SNAPSHOT_FREQUENCY_HOURS \ --start-time=$SNAPSHOT_WINDOW_START \ --storage-location=$REGION
Collega la pianificazione degli snapshot ai dischi
Quando hai eseguito lo script per creare un'istanza, i volumi di dati e WAL sono stati creati come due dischi permanenti indipendenti. Per creare snapshot di dischi permanenti in base a una pianificazione definita, devi associare un criterio delle risorse a ogni disco permanente. In questo caso, vuoi che gli snapshot dei dischi vengano eseguiti contemporaneamente, quindi utilizza lo stesso criterio per entrambi i dischi permanenti collegati alla VM di Compute Engine.
In Cloud Shell, imposta le variabili di ambiente:
export SNAPSHOT_SCHEDULE_NAME=pgdata-disk-schedule export PG_INSTANCE_NAME=instance-pg-pitr export ZONE=zone-of-your-instance
Collega il criterio di pianificazione al disco dati permanente:
gcloud beta compute disks add-resource-policies ${PG_INSTANCE_NAME}-data \ --resource-policies $SNAPSHOT_SCHEDULE_NAME \ --zone $ZONE
Collega il criterio di pianificazione al disco WAL permanente:
gcloud beta compute disks add-resource-policies ${PG_INSTANCE_NAME}-wal \ --resource-policies $SNAPSHOT_SCHEDULE_NAME \ --zone $ZONE
Esegui manualmente uno snapshot
(Facoltativo) Gli snapshot pianificati vengono eseguiti all'interno della finestra di pianificazione, perciò è improbabile che uno snapshot venga acquisito immediatamente al momento della creazione della pianificazione. Se non vuoi attendere lo snapshot pianificato, puoi eseguire manualmente lo snapshot iniziale.
In Cloud Shell, imposta le variabili di ambiente:
export ZONE=zone-of-your-instance export PG_INSTANCE_NAME=instance-pg-pitr export REGION=${ZONE%-[a-z]}
Crea uno snapshot dei due dischi permanenti dell'istanza PostgreSQL:
gcloud compute disks snapshot \ ${PG_INSTANCE_NAME}-data ${PG_INSTANCE_NAME}-wal \ --snapshot-names=${PG_INSTANCE_NAME}-data-`date+%s`,${PG_INSTANCE_NAME}-wal-`date +%s` \ --zone=$ZONE --storage-location=$REGION
Visualizza gli snapshot che hai creato:
gcloud compute snapshots list
L'output è simile al seguente:
NAME DISK_SIZE_GB SRC_DISK STATUS instance-pg-pitr-data-1578339767 200 us-central1-f/disks/instance-pg-pitr-data READY instance-pg-pitr-wal-1578339767 100 us-central1-f/disks/instance-pg-pitr-wal READY
Esecuzione di un PITR
Un PITR viene spesso eseguito per recuperare i dati persi a causa di un errore operativo o programmatico.
In questa sezione del tutorial, eseguirai un aggiornamento del database per simulare una perdita catastrofica di dati. Simulerai quindi una risposta in preda al panico prima di avviare un ripristino dal momento precedente all'invio del comando errato.
Assicurati che sia possibile eseguire un PITR
Prima di eseguire un PITR, devi concedere tempo sufficiente per eseguire quanto segue:
- I backup binari (snapshot del disco)
- Archiviazione WAL
Per questo tutorial, il valore archive_timeout
è stato impostato su un valore generalmente basso di 120 secondi per forzare una frequente rotazione dei file WAL. Devi inoltre attendere che venga eseguito almeno uno snapshot del disco pianificato oppure devi eseguire uno snapshot del disco manualmente.
Verifica di aver acquisito almeno uno snapshot:
Nella console Google Cloud, vai alla pagina Snapshot.
Verifica che esistano almeno due snapshot: uno per il volume dei dati e uno per il volume WAL, ad esempio
instance-pg-pitr--us-central1-a-20190805023535-i3hpw7kn
.
Verifica che i file di segmento siano archiviati in Cloud Storage:
Nella console Google Cloud, vai alla pagina Browser Cloud Storage.
Fai clic su
archive-bucket
.
Danneggiare i dati
Per simulare una perdita catastrofica di dati, apri una shell della riga di comando del database PostgreSQL e danneggia i dati nella tabella compilata dal generatore di transazioni.
Nella console Google Cloud, vai alla pagina Istanze VM.
Per l'istanza
instance-pg-pitr
, fai clic su SSH.Nel terminale SSH, esegui il frontend PostgreSQL nel container Docker:
docker exec -it postgres-db psql --dbname=pitr_demo
Per modificare una riga nella tabella dei clienti, invia un'istruzione DML SQL con un errore ortografico intenzionale nella shell PostgreSQL:
UPDATE pitr_db_schema.customer SET name = 'New Name for customer id=1'; WHERE id = 1;
L'output è simile al seguente:
UPDATE 999 pitr_demo=# WHERE id = 1; ERROR: syntax error at or near "WHERE" LINE 1: WHERE id = 1; ^
L'errore è stato generato perché è stato inserito un punto e virgola aggiuntivo prima della clausola
WHERE
. Tutte le righe del database sono state aggiornate. Ora puoi eseguire un PITR per recuperare le righe modificate dall'istruzione errata.
Determina l'ora target per il recupero
Il primo passaggio di un PITR consiste nel determinare il tempo target per il recupero. Questo periodo di tempo viene determinato esaminando i dati per identificare un punto leggermente precedente all'evento che danneggia i dati.
Nella shell del terminale dell'istanza
instance-pg-pitr
, ottieni il timestamp massimo delle righe danneggiate:SELECT MAX(create_timestamp)::timestamptz FROM pitr_db_schema.customer WHERE name = 'New Name for customer id=1';
L'output è simile al seguente:
max . ------------------------------- 2019-08-05 18:14:58.226511+00 (1 row)
In un database di produzione, la query per determinare il target di recupero è più complessa, soprattutto nei casi in cui la tabella interessata è di grandi dimensioni e la colonna indicativa non è indicizzata.
Copia il risultato. Potrai utilizzare il valore restituito da questa query nel passaggio successivo.
Recupera il database
Per questo tutorial, uno script di recupero automatizza il PITR. Ti consigliamo di disporre di una procedura automatica per recuperare il database e di testarla periodicamente.
In Cloud Shell, cambia la directory di lavoro attuale nella posizione dello script di ripristino:
cd ~/gcs-postgresql-recovery-tutorial/bin
Imposta le variabili di ambiente richieste per lo script. Sostituisci
YYYY-MM-DD HH:MM:SS.999999+00
con l'output della query che hai copiato in precedenza.export PROJECT_ID=$(gcloud config get-value project) export PG_INSTANCE_NAME=instance-pg-pitr export POSTGRES_PASSWORD=PasswordIsThis export PG_INSTANCE_NAME=instance-pg-pitr export RECOVER_BUCKET=archive-bucket export PIT_RECOVERY_TARGET="YYYY-MM-DD HH:MM:SS.999999+00" export ZONE=zone-of-your-instance
Esegui lo script di ripristino:
./recover_to_point_in_time.sh
Informazioni sullo script di ripristino
Questa sezione fornisce alcuni dettagli sui parametri di input e sui passaggi eseguiti dallo script.
Lo script richiede che siano impostate le seguenti variabili di ambiente:
PIT_RECOVERY_TARGET
: l'ora target di recupero.PROJECT_ID
: il progetto in cui si trova l'istanzaPG_INSTANCE_NAME
.ZONE
: la zona in cui si trova l'istanzaPG_INSTANCE_NAME
.PG_INSTANCE_NAME
: l'istanza in cui è in esecuzione l'istanza PostgreSQL di produzione.RECOVER_BUCKET
: il bucket Cloud Storage in cui sono archiviati i file di segmento WAL.POSTGRES_PASSWORD
: la password utilizzata per l'utente del database PostgreSQL.
Lo script effettua i seguenti passaggi:
- Determina gli snapshot del disco più recenti in base alla data e all'ora della destinazione di recupero.
Crea un file
cloud-init.yaml
che viene fornito a una VM di archiviazione ottimizzata per i container che esegue il database PITR. Il filecloud-init.yaml
crea file di configurazione ed esegue diversi comandi di sistema per definire il seguente ambiente:- Un container
gcsfuse
che monta il bucket di file di file del segmento WAL come volume che viene quindi esposto all'host tramite un montaggio di associazione Docker. Un
postgres-db
container in cui il motore del database esegue quanto segue:- Il file system host in cui i dischi permanenti sono collegati come volumi.
- Il file system host a cui il bucket Cloud Storage è collegato come volume.
Un file di recupero
recovery.conf
nella directory dei dati PostgreSQL con le seguenti informazioni:- La data target.
- Comando
restore
: un comando di copia con parametri che il database utilizza per copiare i file di segmenti WAL secondo necessità dal file system di archivio.%f
è il file di segmento e%p
è il percorso utilizzato dal database per l'elaborazione dei file durante il ripristino.
Le impostazioni
archive_
vengono commentate dal file delle impostazionipostgresql.conf
per evitare di danneggiare la directory di archivio WAL.
- Un container
Avvia l'istanza PITR con le seguenti informazioni:
- Nome creato combinando la variabile di ambiente
$PG_INSTANCE_NAME
e i valori alfanumerici della variabile di ambiente$PIT_RECOVERY_TARGET
. - Dischi permanenti creati dagli snapshot dei dischi identificati in precedenza.
- Nome creato combinando la variabile di ambiente
Di seguito è riportato un esempio di file recovery.conf
:
restore_command = '(test -d /var/lib/postgresql/wal/pg_wal_recover && cp /var/lib/postgresql/wal/pg_wal_recover/%f %p ) '
recovery_target_time='YYYY-MM-DD HH:MM:SS UTC'
recovery_target_inclusive=true
Convalida il recupero
Nella console Google Cloud, vai alla pagina Istanze VM.
Per l'istanza
instance-pg-pitr-YYYYMMDDHHMMSS
, fai clic su SSH.Nei terminali SSH, esegui il frontend PostgreSQL nel container Docker:
docker exec -it postgres-db psql --dbname=pitr_demo
Se viene visualizzato il seguente errore, attendi l'avvio del container PostgreSQL, quindi esegui nuovamente il comando:
Error: No such container: postgres-db
Controlla i dati nella tabella dei clienti:
SELECT * FROM pitr_db_schema.customer WHERE id > (SELECT MAX(id)-10 FROM pitr_db_schema.customer);
L'output è simile al seguente:
id | name | create_timestamp ------+---------------------------+---------------------------- 711 | customer_name_from_golang | 2019-12-06 18:03:51.229444 712 | customer_name_from_golang | 2019-12-06 18:03:52.531755 713 | customer_name_from_golang | 2019-12-06 18:03:53.555441 714 | customer_name_from_golang | 2019-12-06 18:03:54.581872 715 | customer_name_from_golang | 2019-12-06 18:03:55.607459 716 | customer_name_from_golang | 2019-12-06 18:03:56.633362 717 | customer_name_from_golang | 2019-12-06 18:03:57.658523 718 | customer_name_from_golang | 2019-12-06 18:03:58.685469 719 | customer_name_from_golang | 2019-12-06 18:03:59.706939
Il nome mostra il valore creato dal generatore di transazioni. La riga finale contiene un timestamp precedente alla destinazione di ripristino (che hai fornito allo script di ripristino in una variabile di ambiente). A seconda del numero di record da recuperare, potrebbe essere necessario attendere qualche istante prima che tutte le righe vengano aggiornate.
Esegui la pulizia
Il modo più semplice per eliminare la fatturazione è eliminare il progetto Google Cloud che hai creato per il tutorial. In alternativa, puoi eliminare le singole risorse.
Elimina il progetto
- Nella console Google Cloud, vai alla pagina Gestisci risorse.
- Nell'elenco dei progetti, seleziona il progetto che vuoi eliminare, quindi fai clic su Elimina.
- Nella finestra di dialogo, digita l'ID del progetto e fai clic su Chiudi per eliminare il progetto.
Passaggi successivi
- Scopri di più sul sistema operativo ottimizzato per i container.
- Scopri di più su cloud-init.
- Scopri di più su Cloud Storage FUSE.
- Esplora le architetture di riferimento, i diagrammi e le best practice su Google Cloud. Visita il nostro Cloud Architecture Center. .