Esecuzione di un PITR di un database PostgreSQL su Compute Engine

---

Questo tutorial mostra come configurare il processo di archiviazione e quindi eseguire una recupero point-in-time (PITR) di un database PostgreSQL in esecuzione Compute Engine.

In questo tutorial, creerai un database dimostrativo ed eseguirai un'applicazione carico di lavoro. Quindi, configurerai i processi di archiviazione e backup. Ora imparerai come verificare i processi di backup, archiviazione e ripristino. Infine, imparerai come ripristinare il database in un momento specifico.

Questo tutorial è destinato ad amministratori di database, operatori di sistema, DevOps professionisti e cloud architect interessati a configurare un backup di ripristino per i database PostgreSQL.

Questo tutorial presuppone che tu abbia familiarità con i container Docker e che tu hanno dimestichezza con i comandi Linux, con i motori di database PostgreSQL e in Compute Engine.

Obiettivi

• Configura un processo di backup e archiviazione.
• Esegui un PITR.
• Monitora il backup.
• Verifica un recupero.

Costi

In questo documento vengono utilizzati i seguenti componenti fatturabili di Google Cloud:

• Compute Engine
• Cloud Storage

Per generare una stima dei costi basata sull'utilizzo previsto, utilizza il Calcolatore prezzi. I nuovi utenti di Google Cloud potrebbero essere idonei per una prova gratuita.

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

1. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

   Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

   Go to project selector

2. Assicurati che la fatturazione sia attivata per il tuo progetto Google Cloud.

3. Abilita le API Compute Engine and Cloud Storage.

   Abilita le API

4. Install the Google Cloud CLI.

5. To initialize the gcloud CLI, run the following command:

   gcloud init

6. In the Google Cloud console, activate Cloud Shell.

   Activate Cloud Shell

   At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

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 ai file di dati sono registrati in WAL prima di essere aggiunti al file.
• Record WAL. Ogni transazione applicata al database viene formattata come record WAL.
• Segmenta i file. I file di segmento hanno nomi di file che aumentano in modo monotonico, e contenere il maggior numero possibile di record WAL. La dimensione del file è configurabile, con un valore predefinito di 16 MiB. Puoi scegliere una taglia più grande se prevedi transazioni voluminose di dimensioni, o numero, per ridurre il numero aggregato di i file di segmento generati e per ridurre il carico di gestione dei file.

Per ulteriori informazioni, vedi Affidabilità e log write-ahead.

Il seguente diagramma mostra come i WAL vengono mantenuti in due fasi.

Nel diagramma precedente, la prima fase dei WAL persistenti è costituita dalla del motore del database che registra transazioni di scrittura nel buffer WAL in concomitanza con scrivere in una tabella. Quando viene eseguito il commit della transazione, il buffer WAL viene scritto (con svuotamento) su disco durante la seconda fase con un'aggiunta al WAL del segmento.

Nota: questo tutorial è attualmente scritto per la versione più recente di Postgres della scrittura: versione 11. Nella versione 10 e successive di Postgres, i WAL vengono creati nella directory pg_wal. Prima della versione 10, i file venivano creati nell'interfaccia pg_xlog.

Scegliere 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 tollerata prima che abbia un impatto significativo sull'attività i processi di machine learning. Salvataggio di tutte le transazioni nel WAL tra gli snapshot di backup riduce drasticamente la quantità di dati persi perché hai transazioni dall'ultimo backup completo da applicare al database.
• Riduci al minimo il Recovery Time Objective (RTO). L'RTO è la quantità necessario per recuperare un database se si verifica un evento distruttivo. Dopo i backup binari e l'archiviazione dei log, il tempo necessario per possono essere minimi.
• Soluzione per un bug di corruzione dei dati o un errore amministrativo. Se una release del codice provoca un danneggiamento catastrofico dei dati o un e irreversibile sia stato commesso un errore durante la manutenzione di routine, prima di quel momento.

In alcune architetture applicative, ad esempio un'architettura di microservizi, Potrebbero essere database paralleli che potrebbero richiedere recuperi indipendenti. Per Ad esempio, un'applicazione di retail potrebbe avere i dati dei clienti in un database i dettagli degli ordini al dettaglio e le informazioni sull'inventario in altri database. In base a lo stato complessivo dei dati, potrebbe essere necessario recuperare uno, due o tutti i database in parallelo.

Il PITR non è appropriato nei seguenti scenari:

• L'RPO è elevato. Se i criteri di ripristino di emergenza possono tollerare delle transazioni ricevute dopo l'istantanea recente, puoi evitare passaggi aggiuntivi e di concentrarti sulla riduzione dei tempi di recupero dei dati.
• È necessario un ripristino completo del database. Se il tuo obiettivo è recuperare alla transazione più recente, la tua destinazione di recupero è il timestamp l'ultima transazione persistente. Questo scenario è un caso specifico di PITR ma semanticamente questo obiettivo è indicato come ripristino completo.

Considerazioni sulle prestazioni

Il processo di archiviazione applica un carico I/O aggiuntivo al server di database. La dipende dalle caratteristiche del carico di lavoro, perché è proporzionale al volume delle transazioni di scrittura, aggiornamento ed eliminazione.

Se vuoi ridurre l'impatto I/O dell'attività di archiviazione WAL sul database principale, puoi eseguire gli archivi WAL periodici utilizzando un di sola lettura.

Questa configurazione isola il database principale dall'I/O orientato al batch attività relative al trasferimento dei file WAL. Transazioni destinate a le repliche di sola lettura vengono trasmesse in un flusso costante dall'istanza principale il database, determinando così un impatto molto inferiore sulla velocità effettiva in stato stabile.

Inoltre, se la topologia del database di produzione include già un modello replica, questa configurazione non comporta ulteriori oneri: gestione, o in altro modo.

Architettura di riferimento

Il seguente diagramma illustra l'architettura implementata in questo tutorial di Google Cloud.

In questo tutorial creerai un'infrastruttura cloud per osservare un PITR che viene utilizzando 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 Macchina virtuale (VM) database PostgreSQL. Come separazione dei problemi, il server del database sia in esecuzione in uno dei container e l'archivio WAL in esecuzione nell'altro container.

Questo diagramma mostra come i volumi Docker in ogni container sono mappati Punti di montaggio Persistent Disk sulla VM host.

Configurazione delle variabili di ambiente

Gli script e i comandi utilizzati in questo tutorial si basano sull'ambiente shell come la codifica one-hot delle variabili categoriche.

1. In Cloud Shell, imposta le variabili di ambiente per il tuo 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 che che hai creato per questo tutorial.
   • PasswordIsThis: una password sicura per PostgreSQL standard.

2. Impostare la variabile di ambiente per la zona Google Cloud. Sostituisci choose-an-appropriate-zone con un Zona Google Cloud.

   export ZONE=choose-an-appropriate-zone
   export REGION=${ZONE%-[a-z]}
   

3. Imposta la variabile di ambiente per il valore predefinito Virtual Private Cloud (VPC) per la regione della tua zona:

   export SUBNETWORK_URI=$(gcloud compute networks subnets \
       describe default --format=json --region=$REGION | \
       jq --raw-output '.ipCidrRange')
   

4. Imposta la variabile di ambiente per il bucket Cloud Storage. Sostituisci archive-bucket con un nome univoco per 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 da cui archiviare i file WAL il database PostgreSQL:

  gcloud storage buckets create gs://${ARCHIVE_BUCKET}
  

Autorizzazione dell'accesso alle istanze degli indirizzi IP privati

Per le istanze utilizzate in questo tutorial, come in molti casi d'uso di produzione, non è necessario che le istanze VM ottengano indirizzi IP pubblici. Tuttavia, le istanze richiedono l'accesso alla rete internet pubblica per eseguire il pull dell'esempio immagini container e richiedi l'accesso per connetterti utilizzando un una shell. Configuri un gateway NAT (Network Address Translation) configurare Identity-Aware Proxy (IAP) per l'inoltro TCP.

Crea un gateway NAT

Poiché le istanze VM che crei non hanno indirizzi IP pubblici, crea un gateway NAT affinché le istanze possano eseguire il pull delle immagini container Docker Hub.

1. In Cloud Shell, crea un'istanza Router Cloud:

   export CLOUD_ROUTER_NAME=${PROJECT_ID}-nat-router
   gloud compute routers create $CLOUD_ROUTER_NAME \
       --network=default --region=$REGION
   

2. 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
   

Configurazione di 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 è autorizzato ad accedere a una VM.

1. In Cloud Shell, consenti il traffico dalla rete di forwarding TCP alle istanze del 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
   

2. Per connetterti utilizzando un tunnel di inoltro TCP, aggiungi un Identity and Access Management (IAM) dell'associazione di criteri. Sostituisci your-email-address con l'email 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

1. In Cloud Shell, clona il repository di codice sorgente che contiene di configurazione e cambiare il contesto della shell nel repository locale:

   git clone https://github.com/GoogleCloudPlatform/gcs-postgresql-recovery-tutorial
   cd gcs-postgresql-recovery-tutorial
   

2. Per creare e configurare l'istanza VM del database, esegui questo comando script:

   cd bin
   ./create_postgres_instance.sh
   

   Per questo tutorial, questo script avvia un'istanza VM con il sistema operativo ottimizzato per i container e due nuovi dei dischi permanenti standard. In questo caso, puoi ignorare il messaggio di avviso restituito dall'API su prestazioni di I/O scarse perché gli script creano Persistent Disk e dischi permanenti.

Revisione della configurazione cloud-init

Cloud-init è un pacchetto multi-distribuzione che inizializza un'istanza cloud.

Esamina il seguente esempio di codice cloud-init:

write_files:
- path: /var/tmp/docker-entrypoint-initdb.d/init-pitr-demo-db.sql
  permissions: 0644
  owner: root
  content: |
    CREATE DATABASE ${POSTGRES_PITR_DEMO_DBNAME};

    \c ${POSTGRES_PITR_DEMO_DBNAME}

    CREATE SCHEMA pitr_db_schema;

    CREATE TABLE pitr_db_schema.customer
       (id SERIAL NOT NULL,
        name VARCHAR(255),
        create_timestamp TIMESTAMP DEFAULT current_timestamp,
        PRIMARY KEY (id));

    CREATE TABLE pitr_db_schema.invoice
       (id SERIAL NOT NULL,
        customer_id INTEGER
          REFERENCES pitr_db_schema.customer(id),
        description VARCHAR(1000),
        create_timestamp TIMESTAMP DEFAULT current_timestamp,
        PRIMARY KEY (customer_id, id));

- path: /etc/systemd/system/postgres.service
  permissions: 0644
  owner: root
  content: |
    [Unit]
    Requires=docker.service
    After=docker.service
    Description=postgres docker container

    [Service]
    TimeoutStartSec=0
    KillMode=none
    Restart=always
    RestartSec=5s
    ExecStartPre=-/usr/bin/docker kill postgres-db
    ExecStartPre=-/usr/bin/docker rm -v postgres-db
    ExecStart=/usr/bin/docker run -u postgres --name postgres-db \
                                  -v /var/tmp/docker-entrypoint-initdb.d:/docker-entrypoint-initdb.d \
                                  -v /mnt/disks/data:/var/lib/postgresql/data \
                                  -v /mnt/disks/wal:/var/lib/postgresql/wal \
                                  -e PGDATA=/var/lib/postgresql/data/pgdata \
                                  -e POSTGRES_PASSWORD=${POSTGRES_PASSWORD} \
                                  -e POSTGRES_INITDB_WALDIR=/var/lib/postgresql/wal/pg_wal \
                                  -p ${POSTGRES_PORT}:${POSTGRES_PORT} \
                               postgres:11-alpine
    ExecStop=-/usr/bin/docker stop postgres-db
    ExecStopPost=-/usr/bin/docker rm postgres-db

- path: /etc/systemd/system/wal_archive.service
  permissions: 0644
  owner: root
  content: |
    [Unit]
    Requires=docker.service postgres.service
    After=docker.service postgres.service
    Description=WAL archive docker container

    [Service]
    TimeoutStartSec=10min
    Type=oneshot
    ExecStart=/usr/bin/docker run --name wal-archive \
                                  -v /mnt/disks/wal/pg_wal_archive:/mnt/wal_archive \
                               google/cloud-sdk:slim gsutil mv /mnt/wal_archive/[0-9A-F]*[0-9A-F] gs://${ARCHIVE_BUCKET}
    ExecStopPost=-/usr/bin/docker rm wal-archive

- path: /etc/systemd/system/wal_archive.timer
  permissions: 0644
  owner: root
  content: |
    [Unit]
    Description=Archive WAL to GCS (every 5 minutes)

    [Timer]
    OnBootSec=5min
    OnUnitInactiveSec=5min
    OnUnitActiveSec=5min

    [Install]
    WantedBy=timers.target

Per questo tutorial, cloud-init viene utilizzato per:

1. Creare due dispositivi di archiviazione a blocchi su Persistent Disk.
2. Crea i file system sui due dispositivi: uno per i dati e uno per i log di archivio.
3. Monta i dispositivi in punti di montaggio logici sull'istanza VM, che sono condivise con i container Docker.
4. 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.
5. Crea un /var/tmp/docker-entrypoint-initdb.d/init-pitr-demo-db.sql per creare un semplice set di tabelle in un database dimostrativo e .
6. Crea e avvia un secondo servizio systemd (wal_archive.service) che esegue un container Docker Google Cloud CLI con i dischi WAL montati come volume. Questo servizio esegue il backup dei file WAL archiviati su di archiviazione ideale in Cloud Storage.
7. Crea, attiva e avvia un timer systemd (wal_archive.timer) che esegue periodicamente wal_archive.service.
8. Assicurati che la porta PostgreSQL (5432) sia aperta per la subnet VPC in modo 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 per avviare il processo di archiviazione WAL.

Connettiti all'istanza VM del database

1. Nella console Google Cloud, vai alla pagina Istanze VM.

   Vai all'istanza VM

2. Per aprire una shell del terminale, accanto all'istanza instance-pg-pitr che creato, fai clic su SSH.

3. 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 momento e poi utilizza lo stesso per eseguire una nuova verifica.

Consenti connessioni di rete in entrata al database

Attenzione :queste impostazioni potrebbero non essere le impostazioni di rete appropriate per il tuo database di produzione e sono usati solo per questo tutorial.

1. Nella shell del terminale dell'istanza instance-pg-pitr apri File di configurazione dell'autenticazione basata su host PostgreSQL per la modifica:

   sudoedit /mnt/disks/data/pgdata/pg_hba.conf
   

2. Per rimuovere l'accesso predefinito a tutti gli indirizzi IP al database, commenta nella riga seguente dalla fine del file aggiungendo # alla all'inizio della riga. La riga nel file è simile alla seguente:

   #host all all all md5
   

3. Consentire connessioni protette da password dagli host in 10.0.0.0/8 blocco CIDR, aggiungi la riga seguente alla fine del file:

   host    all             all             10.0.0.0/8               md5
   

   Questa voce consente la connettività dalla subnet VPC in cui viene creato in un secondo momento.

4. Salva e chiudi il file.

Configura l'archiviazione WAL

1. Nella shell del terminale dell'istanza instance-pg-pitr, modifica postgresql.conf file:

   sudoedit /mnt/disks/data/pgdata/postgresql.conf
   

2. Sostituisci archive_mode, archive_command, con commento esistente e archive_timeout righe 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
   

   Nota: per questo tutorial viene utilizzato un timeout di archiviazione di 120 secondi per dimostrare la creazione e l'archiviazione dei file dei segmenti WAL nonostante una bassa volume delle transazioni. Per ulteriori informazioni su queste impostazioni, vedi Documentazione relativa ai log write-ahead di PostgreSQL.

   Quando sostituisci le righe nel file modificato, il risultato è simile a il seguente snippet di codice:

   
   .... illustrative snippet start ....
   
   # - Archiving -
   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
   #------------------------------------------------------------------------------
   # REPLICATION
   #------------------------------------------------------------------------------
   
   .... illustrative snippet end ....
   
   

3. Salva e chiudi il file.

Applica e verifica le modifiche alla configurazione

1. Nella shell del terminale dell'istanza instance-pg-pitr riavvia il contenitore per applicare le modifiche:

   sudo systemctl restart postgres
   

2. Verifica la presenza dei file dei 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
   

3. 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)
   

4. Chiudi la connessione SSH all'istanza.

Avvio del generatore di transazioni per compilare il database

I seguenti passaggi avviano Vai 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 pubblica Container Registry.

Nota: il codice è disponibile nel repository dei tutorial ed è incluso uno script per creare l'immagine. Se desideri completare personalmente la procedura o modificare puoi utilizzare lo script per creare l'immagine ed eseguirne il push e Container Registry. I passaggi per modificare lo script non rientrano nell'ambito di questa procedura tutorial di Google Cloud.

1. In Cloud Shell, passa alla directory del generatore di transazioni:

   cd ~/gcs-postgresql-recovery-tutorial/bin
   

2. 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')
   

3. Per eseguire il generatore di transazioni, avvia l'istanza:

   ./run_trans_gen_instance.sh
   

   Ignora il messaggio di avviso relativo alle prestazioni scadenti dell'I/O.

4. Attendi qualche istante e verifica che le transazioni stiano raggiungendo 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 i record vengono aggiunti al creato dal generatore di transazioni:

    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 dell'ora definita nel criterio della risorsa.

Crea la pianificazione di snapshot

1. 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 Zona Google Cloud in cui hai avviato in precedenza la VM del database.

2. 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 dati e i volumi WAL sono stati vengono creati come due dischi permanenti indipendenti. Per creare snapshot di disco permanente in base a una pianificazione definita, devi associare un criterio delle risorse ogni disco permanente. In questo caso, gli snapshot dei dischi devono essere eseguiti contemporaneamente, quindi utilizzerai lo stesso criterio per entrambi i dischi permanenti collegati della VM di Compute Engine.

1. 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
   

2. 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
   

3. 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 si verificano all'interno della finestra di pianificazione, quindi è improbabile che venga acquisito uno snapshot immediatamente quando hai creato la pianificazione. Se non vuoi attendere lo snapshot pianificato, eseguire manualmente lo snapshot iniziale.

1. 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]}
   

2. Crea uno snapshot dei due dischi permanenti delle istanze 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
   

3. 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 una un errore programmatico.

In questa sezione del tutorial eseguirai un aggiornamento del database per simulare un una catastrofica perdita di dati. Quindi simulerai una risposta nel panico, prima avviando un ripristino fino al momento precedente all'invio del comando errato.

Assicurati che sia possibile eseguire un PITR

Prima di eseguire un PITR, devi concedere tempo sufficiente per le seguenti eseguire:

• I backup binari (snapshot del disco)
• Archiviazione WAL

Per questo tutorial, il valore di archive_timeout è stato impostato su un valore insolitamente basso di 120 secondi per forzare una rotazione frequente dei file WAL. Devi anche attendere fino alle ore venga eseguito almeno uno snapshot del disco pianificato oppure eseguire lo snapshot del disco manualmente.

1. Verifica di aver acquisito almeno uno snapshot:

   1. Nella console Google Cloud, vai alla pagina Snapshot.

      Vai alla pagina Snapshot

   2. Verifica che esistano almeno due snapshot: uno per i dati e uno per il volume WAL, ad esempio instance-pg-pitr--us-central1-a-20190805023535-i3hpw7kn.

2. Verifica che i file dei segmenti siano archiviati in Cloud Storage:

   1. Nella console Google Cloud, vai alla pagina Browser Cloud Storage.

      Vai alla pagina Browser Cloud Storage

   2. Fai clic su archive-bucket.

      

Danneggiare i dati

Per simulare una perdita catastrofica di dati, apri una shell della riga di comando PostgreSQL e danneggiare i dati nella tabella compilata generatore di transazioni.

1. Nella console Google Cloud, vai alla pagina Istanze VM.

   Vai alla pagina Istanze VM

2. Per l'istanza instance-pg-pitr, fai clic su SSH.

3. Nel terminale SSH, esegui il frontend basato su terminale PostgreSQL Container Docker:

   docker exec -it postgres-db psql --dbname=pitr_demo
   

4. Per modificare una riga nella tabella dei clienti, invia un'istruzione DML SQL con un errore di battitura 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 del WHERE. Tutte le righe del database sono state aggiornate. Ora puoi eseguire PITR per recuperare le righe modificate dall'istruzione errata.

Stabilisci l'ora di destinazione per il recupero

Il primo passaggio in un PITR consiste nel determinare l'ora target per il recupero. Questo il tempo viene determinato esaminando i dati per identificare un punto leggermente prima l'evento che danneggia i dati.

1. 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 la destinazione di ripristino più complessa, soprattutto nei casi in cui la tabella interessata è di grandi dimensioni, e la colonna indicativa non è indicizzata.

2. Copia il risultato. utilizzerai 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 un processo automatizzato per recuperare il database e testare periodicamente questo processo.

1. In Cloud Shell, modifica la directory di lavoro attuale in posizione dello script di recupero:

   cd ~/gcs-postgresql-recovery-tutorial/bin
   

2. Imposta le variabili di ambiente richieste per lo script. Sostituisci YYYY-MM-DD HH:MM:SS.999999+00 con l'output della query 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
   

3. Esegui lo script di ripristino:

   ./recover_to_point_in_time.sh
   

Informazioni sullo script di recupero

Questa sezione fornisce alcuni dettagli sui parametri di input e sulla procedura prese dallo script.

Lo script richiede l'impostazione delle seguenti variabili di ambiente:

• PIT_RECOVERY_TARGET: l'ora target per il recupero.
• PROJECT_ID: il progetto in cui L'istanza PG_INSTANCE_NAME è stata trovata.
• ZONE: la zona in cui L'istanza PG_INSTANCE_NAME è stata trovata.
• PG_INSTANCE_NAME: l'istanza in cui produzione PostgreSQL è in esecuzione.
• RECOVER_BUCKET: il bucket Cloud Storage in cui vengono archiviati i file dei segmenti WAL.
• POSTGRES_PASSWORD: la password utilizzata per Utente del database PostgreSQL.

Lo script esegue questi passaggi:

1. Determina gli snapshot del disco più recenti in base alla destinazione di ripristino data e ora.

2. Crea un file cloud-init.yaml fornito a un una VM di archiviazione ottimizzata per il container che esegue il database PITR. La Il file cloud-init.yaml crea file di configurazione ed esegue diversi file di sistema per stabilire il seguente ambiente:

   • Un container gcsfuse che monta l'archivio dei file del segmento WAL del bucket come volume, che viene poi esposto all'host con Base per dockerbind.

   • Un postgres-dbcontainer in cui il motore del database esegue quanto segue:

     • Il file system host in cui si trovano i dischi permanenti collegati come volumi.
     • Il file system host in cui l'istanza di Cloud Storage è collegato come volume.

   • Un file di recupero recovery.conf nella directory dei dati PostgreSQL con le seguenti informazioni:

     • La data target.
     • Il comando restore: un comando di copia con parametri che che il database utilizza per copiare i file dei segmenti WAL in base alle esigenze dal di archiviazione del file system. %f è il file del segmento, mentre %p è il percorso. utilizzata dal database per elaborare i file durante il ripristino.

   • Le impostazioni di archive_ sono state commentate da postgresql.conf delle impostazioni per evitare di danneggiare la directory di archivio WAL.

3. Avvia l'istanza PITR con le seguenti informazioni:

   • Un nome creato combinando l'ambiente $PG_INSTANCE_NAME e i valori alfanumerici della colonna $PIT_RECOVERY_TARGET variabile di ambiente.
   • Dischi permanenti creati dagli snapshot dei dischi identificati in precedenza.

Di seguito è riportato un file recovery.conf di esempio:

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

1. Nella console Google Cloud, vai alla pagina Istanze VM.

   Vai alla pagina Istanze VM

2. Per instance-pg-pitr-YYYYMMDDHHMMSS fai clic su SSH.

3. Nei terminali SSH, esegui il frontend basato su terminale PostgreSQL Container Docker:

   docker exec -it postgres-db psql --dbname=pitr_demo
   

   Se viene visualizzato il seguente errore, attendi che il cluster PostgreSQL il container all'avvio ed esegui nuovamente il comando:

   Error: No such container: postgres-db
   

4. 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. Il finale riga ha un timestamp precedente alla destinazione di recupero (che hai fornito allo script di ripristino in una variabile di ambiente). In base a il numero di record da recuperare, potrebbe essere necessario attendere per l'aggiornamento di tutte le righe.

Esegui la pulizia

Il modo più semplice per eliminare la fatturazione è quello di eliminare il progetto Google Cloud creato per il tutorial. In alternativa, puoi eliminare il singolo Google Cloud.

Elimina il progetto

Attenzione: l'eliminazione di un progetto ha i seguenti effetti:
• L'intero contenuto del progetto viene eliminato. Se hai utilizzato un progetto esistente per le attività in questo documento, quando lo elimini elimini anche qualsiasi altro lavoro svolto nel progetto.
• Gli ID progetto personalizzati non sono più disponibili. Quando hai creato questo progetto, potresti aver creato un ID progetto personalizzato che vuoi utilizzare in futuro. Per conservare gli URL che utilizzano l'ID progetto, ad esempio un URL appspot.com, elimina le risorse selezionate all'interno del progetto anziché eliminare l'intero progetto.
1. Nella console Google Cloud, vai alla pagina Gestisci risorse.

   Vai a Gestisci risorse

2. Nell'elenco dei progetti, seleziona il progetto che vuoi eliminare, quindi fai clic su Elimina.
3. Nella finestra di dialogo, digita l'ID del progetto e fai clic su Chiudi per eliminare il progetto.

Passaggi successivi

• Scopri di più sulle Sistema operativo ottimizzato per il container.
• Scopri di più su cloud-init.
• Scopri di più su Fusibile di Cloud Storage.
• Esplora le architetture di riferimento, i diagrammi e le best practice su Google Cloud. Dai un'occhiata al nostro Centro architetture cloud. .