PostgreSQL
 sql >> Database >  >> RDS >> PostgreSQL

Creazione di un Cold Standby per PostgreSQL utilizzando Amazon AWS

La necessità di ottenere un'elevata disponibilità del database è un'attività piuttosto comune e spesso un must. Se la tua azienda ha un budget limitato, mantenere uno slave di replica (o più di uno) in esecuzione sullo stesso provider cloud (solo in attesa se un giorno sarà necessario) può essere costoso. A seconda del tipo di applicazione, ci sono alcuni casi in cui è necessario uno slave di replica per migliorare l'RTO (Recovery Time Objective).

C'è un'altra opzione, tuttavia, se la tua azienda può accettare un breve ritardo per riportare i tuoi sistemi online.

Cold Standby, è un metodo di ridondanza in cui hai un nodo standby (come backup) per quello primario. Questo nodo viene utilizzato solo durante un errore principale. Il resto del tempo il nodo Cold Standby viene spento e utilizzato solo per caricare un backup quando necessario.

Per utilizzare questo metodo, è necessario disporre di una policy di backup predefinita (con ridondanza) secondo un RPO (Recovery Point Objective) accettabile per l'azienda. Può darsi che perdere 12 ore di dati sia accettabile per l'azienda o perdere solo un'ora potrebbe essere un grosso problema. Ogni azienda e applicazione deve determinare il proprio standard.

In questo blog imparerai come creare una policy di backup e come ripristinarla su un server Cold Standby utilizzando ClusterControl e la sua integrazione con Amazon AWS.

Per questo blog, supponiamo che tu abbia già un account AWS e ClusterControl installati. Anche se in questo esempio utilizzeremo AWS come provider cloud, puoi utilizzarne uno diverso. Utilizzeremo la seguente topologia PostgreSQL distribuita utilizzando ClusterControl:

  • 1 nodo primario PostgreSQL
  • 2 nodi PostgreSQL Hot-Standby
  • 2 Load Balancer (HAProxy + Keepalived)

Creazione di una politica di backup accettabile

La procedura migliore per creare questo tipo di policy è archiviare i file di backup in tre posizioni diverse, una archiviata localmente sul server di database (per un ripristino più rapido), un'altra in un server di backup centralizzato e l'ultimo nel cloud.

Puoi migliorarlo utilizzando anche backup completi, incrementali e differenziali. Con ClusterControl puoi eseguire tutte le best practice di cui sopra, tutte dallo stesso sistema, con un'interfaccia utente intuitiva e facile da usare. Iniziamo creando l'integrazione AWS in ClusterControl.

Configurazione dell'integrazione AWS ClusterControl

Vai a ClusterControl -> Integrazioni -> Fornitori cloud -> Aggiungi credenziali cloud.

Scegli un provider cloud. Supportiamo AWS, Google Cloud o Azure. In questo caso, scegli AWS e continua.

Qui devi aggiungere un nome, una regione predefinita e un AWS ID chiave e chiave segreta. Per ottenere o creare questi ultimi, dovresti andare alla sezione IAM (Identity and Access Management) sulla console di gestione AWS. Per ulteriori informazioni, puoi fare riferimento alla nostra documentazione o alla documentazione di AWS.

Ora che hai creato l'integrazione, andiamo a pianificare il primo backup utilizzando ClusterControl.

Pianificazione di un backup con ClusterControl

Vai a ClusterControl -> Seleziona il cluster PostgreSQL -> Backup -> Crea backup.

Puoi scegliere se creare un backup singolo istantaneamente o pianificare un nuovo backup. Quindi, scegliamo la seconda opzione e proseguiamo.

Quando pianifichi un backup, devi prima specificare la pianificazione /frequenza. Quindi, è necessario scegliere un metodo di backup (pg_dumpall, pg_basebackup, pgBackRest), il server da cui verrà eseguito il backup e dove si desidera archiviare il backup. Puoi anche caricare il nostro backup sul cloud (AWS, Google o Azure) abilitando il pulsante corrispondente.

Quindi specifica l'uso della compressione, il livello di compressione, la crittografia e il periodo di conservazione per il tuo backup. C'è un'altra funzione chiamata "Verifica backup" che vedrai più dettagliatamente presto in questo post del blog.

Se l'opzione "Carica backup nel cloud" è stata abilitata, tu' Verrà visualizzato questo passaggio in cui è necessario selezionare le credenziali cloud e creare o selezionare un bucket S3 in cui archiviare il backup. Devi anche specificare il periodo di conservazione.

Ora avrai il backup pianificato nella sezione ClusterControl Schedule Backups. Per coprire le migliori pratiche menzionate in precedenza, puoi pianificare un backup per archiviarlo in un server esterno (server ClusterControl) e nel cloud, quindi pianificare un altro backup per archiviarlo localmente nel nodo del database per un ripristino più rapido.

Ripristino di un backup su Amazon EC2

Una volta terminato il backup, puoi ripristinarlo utilizzando ClusterControl nella sezione Backup.

Creazione dell'istanza Amazon EC2

Prima di tutto, per ripristinarlo, avrai bisogno di un posto dove farlo, quindi creiamo un'istanza Amazon EC2 di base. Vai a "Avvia istanza" nella console di gestione AWS nella sezione EC2 e configura la tua istanza.

Quando l'istanza viene creata, dovrai copiare il public SSH chiave dal server ClusterControl.

Ripristino del backup utilizzando ClusterControl

Ora hai la nuova istanza EC2, usiamola per ripristinare il backup lì. Per questo, nel tuo ClusterControl vai nella sezione backup (ClusterControl -> Seleziona Cluster -> Backup), e lì puoi selezionare "Ripristina backup" o direttamente "Ripristina" sul backup che vuoi ripristinare.

Sono disponibili tre opzioni per ripristinare il backup. È possibile ripristinare il backup in un nodo di database esistente, ripristinare e verificare il backup su un host autonomo o creare un nuovo cluster dal backup. Poiché desideri creare un nodo di standby a freddo, utilizziamo la seconda opzione "Ripristina e verifica su host autonomo".

Avrai bisogno di un host dedicato (o VM) che non faccia parte del cluster per ripristinare il backup, quindi utilizziamo l'istanza EC2 creata per questo lavoro. ClusterControl installerà il software e ripristinerà il backup in questo host.

Se l'opzione "Spegni il server dopo il ripristino del backup" è abilitata, ClusterControl arresterà il nodo del database al termine del processo di ripristino, ed è esattamente ciò di cui abbiamo bisogno per questa creazione di standby a freddo.

Puoi monitorare l'avanzamento del backup nella sezione ClusterControl Activity.

Utilizzo della funzione di verifica del backup di ClusterControl

Un backup non è un backup se non è ripristinabile. Quindi, dovresti assicurarti che il backup funzioni e ripristinarlo frequentemente nel nodo di standby freddo.

Questa funzione di backup di ClusterControl Verify Backup è un modo per automatizzare la manutenzione di un nodo cold standby ripristinando un backup recente per mantenerlo il più aggiornato possibile evitando il processo di backup di ripristino manuale. Vediamo come funziona.

Come attività "Ripristina e verifica su host standalone", richiederà un host dedicato (o VM) che non fa parte del cluster per ripristinare il backup, quindi utilizziamo la stessa istanza EC2 qui.

La funzione di verifica automatica del backup è disponibile per i backup pianificati. Quindi, vai su ClusterControl -> Seleziona il cluster PostgreSQL -> Backup -> Crea backup e ripeti i passaggi che hai visto in precedenza per pianificare un nuovo backup.

Nel secondo passaggio, avrai a disposizione la funzione "Verifica backup" per abilitarlo.

Utilizzando le opzioni precedenti, ClusterControl installerà il software e ripristinerà il backup su il padrone di casa. Dopo averlo ripristinato, se tutto è andato bene, vedrai l'icona di verifica nella sezione Backup ClusterControl.

Conclusione

Se hai un budget limitato, ma richiedi l'alta disponibilità, puoi utilizzare un nodo PostgreSQL in standby freddo che potrebbe essere valido o meno a seconda dell'RTO e dell'RPO dell'azienda. In questo blog, ti abbiamo mostrato come pianificare un backup (in base alla tua politica aziendale) e come ripristinarlo manualmente. Abbiamo anche mostrato come ripristinare automaticamente il backup in un server Cold Standby utilizzando ClusterControl, Amazon S3 e Amazon EC2.