Descrizione di alta disponibilità e di ripristino di emergenza per Databases for PostgreSQL
L' alta disponibilitàLa capacità di un servizio o di un carico di lavoro di resistere ai guasti e di continuare a fornire capacità di elaborazione secondo un livello di servizio predefinito. Per i servizi, la disponibilità è definita nell'Accordo sul livello dei servizi. La disponibilità comprende sia gli eventi pianificati che quelli non pianificati, come manutenzione, guasti e disastri. (HA) è la capacità di un servizio di rimanere operativo e accessibile in presenza di guasti imprevisti. Il disaster recoveryLa capacità di un servizio o di un carico di lavoro di riprendersi da incidenti rari e gravi e da guasti su larga scala, come l'interruzione del servizio. Ciò include un disastro fisico che colpisce un'intera regione, il danneggiamento di un database o la perdita di un servizio che contribuisce a un carico di lavoro. L'impatto supera la capacità del progetto di alta disponibilità di gestirlo. è il processo di ripristino dell'istanza di servizio in uno stato funzionante.
Databases for PostgreSQL è un servizio regionale che soddisfa gli obiettivi di livello di servizio(SLO) definiti con il piano standard. Per ulteriori informazioni, vedere Accordo sul livello di servizio(SLA). Per ulteriori informazioni sulle regioni e sui data center IBM Cloud disponibili per site.data.keyword.databases-for-postgresql, vedere Disponibilità del servizio e dell'infrastruttura per località.
Architettura ad alta disponibilità
Databases for PostgreSQL offre funzioni di replica, failover e alta disponibilità per proteggere i database e i dati dalla manutenzione dell'infrastruttura, dagli aggiornamenti e da alcuni guasti. Le distribuzioni contengono un cluster con due membri dati: leader e replica. La replica viene mantenuta aggiornata utilizzando la replica asincrona. Un meccanismo di consenso distribuito viene utilizzato per mantenere lo stato del cluster e gestire i failover. Se il leader diventa irraggiungibile, il cluster avvia un failover e la replica viene promossa a leader e una nuova replica si unisce al cluster come replica. Il leader e la replica si troveranno sempre in zone diverse di un MZR. Se la replica fallisce, viene creata una nuova replica. Se il guasto di una zona comporta il fallimento di un membro, la nuova replica verrà creata in una zona superstite.
È possibile estendere ulteriormente l'alta disponibilità aggiungendo al cluster i membri di PostgreSQL per una maggiore ridondanza all'interno della regione, oppure fornendo repliche di sola lettura per il failover interregionale o l'offloading di lettura.
Rivedere la documentazione di PostgreSQL sulle tecniche di replica per comprendere i vincoli e i compromessi associati alla strategia di replica asincrona implementata per impostazione predefinita.
Negli scenari in cui un database diventa criticamente non sano, come nel caso di un crash del server sul leader, Databases for PostgreSQL tenta un failover. Questa funzionalità di auto-failover è limitata a 16 MB di ritardo dei dati dal leader alla replica (poche righe di dati una volta che rappresentano più overhead di dati PostgreSQL ) e non viene eseguita se la soglia di ritardo viene superata. Se la perdita potenziale di 16 MB di dati è intollerabile per l'applicazione, vedere la replica sincrona di seguito.
I carichi di lavoro che accedono programmaticamente al cluster devono seguire la logica di retry della disponibilità del client per mantenere la disponibilità.
A volte il servizio esegue failover controllati durante il normale funzionamento. Questi failover sono eventi senza perdita di dati, ma comportano il ripristino delle connessioni attive. La riconnessione può fallire per un periodo massimo di 15 secondi. A volte, i failover non pianificati possono verificarsi a causa di eventi imprevisti nell'ambiente operativo. Questi possono richiedere fino a 45 secondi, ma in genere sono inferiori a 30. La manutenzione del servizio, ad esempio, attiva un failover controllato.
Caratteristiche di alta disponibilità
Databases for PostgreSQL supporta le seguenti funzioni di alta disponibilità:
Funzione | Descrizione | Considerazione |
---|---|---|
Failover automatico | Standard su tutti i cluster e resiliente contro i guasti di una zona o di un singolo membro | |
Conteggio membri | Minimo - 2 membri. L'impostazione predefinita è una distribuzione standard a due membri. Un cluster di due membri si riprenderà automaticamente da un guasto di una singola istanza o zona (con perdita di dati fino alla soglia di ritardo). Durante la sincronizzazione dei dati per una nuova replica, il cluster è esposto a un secondo guasto che causa la perdita di dati. Un sistema a tre membri, vedi aggiunta di membri PostgreSQL, è resistente al guasto di due membri durante lo stesso periodo di guasto | Tre membri necessari per la replica sincrona |
Replica sincrona | Migliora l'RPO aggiungendo la sincronizzazione remota dei membri al percorso di scrittura dei dati. Consultare la sezione Replica sincrona di seguito. | Impatto sulle prestazioni e costi. |
Replica di sola lettura | Le repliche di sola lettura possono fornire un accesso locale nelle regioni remote, migliorando la disponibilità in caso di potenziali problemi di latenza di rete o di connettività. | Tutte le richieste di scrittura devono essere dirette esclusivamente al cluster di lettura-scrittura associato alla replica di lettura |
Replica sincrona Databases for PostgreSQL
Per impostazione predefinita, la replica in streaming è asincrona. Se il leader si blocca, alcune transazioni impegnate potrebbero non essere state sincronizzate con la replica, causando una perdita di dati. Cloud Databases garantisce che
la perdita di dati sia mantenuta al minimo; tuttavia, la replica sincrona offre la possibilità di confermare che tutte le modifiche apportate da una transazione sono state sincronizzate con la replica. Questo garantisce la coerenza in
un cluster. Questa coerenza deriva dalla conferma che le scritture sono state scritte su un secondario prima di tornare al client che si connette con success
. Per le variabili relative alla replica sincrona, vedere synchronous_commit
nella pagina Modifica della configurazione.
La replica sincrona porta la disponibilità della replica nel percorso di scrittura primario. Se non c'è una replica che riconosce una scrittura, questa si blocca finché non è disponibile una replica. Per funzionare in modo affidabile, sono necessari almeno tre membri, poiché la replica sincrona non è supportata da distribuzioni a due membri. È necessario scalare orizzontalmente ad almeno tre membri prima di abilitare la replica sincrona. Vedere Aggiunta di membri di PostgreSQL.
Anche se è improbabile, è possibile che più di una replica diventi indisponibile contemporaneamente. In questo caso, il database primario non sarà in grado di completare alcuna scrittura fino a quando una replica non tornerà online, bloccando di fatto tutto il traffico di scrittura verso il database. Quando decidete di utilizzare la replica sincrona, valutate i costi e i benefici relativi di una maggiore durabilità dei dati rispetto ai potenziali problemi di disponibilità.
La configurazione della replica sincrona può aumentare significativamente la latenza di scrittura e ridurre il throughput complessivo. Per ottenere prestazioni ottimali, si consiglia di utilizzare la replica sincrona solo su database o carichi di lavoro specifici che richiedono il massimo grado di durabilità dei dati.
Architettura di disaster recovery
La strategia generale per il ripristino di emergenza consiste nel creare un nuovo database, come il database Restore
riportato di seguito. Il contenuto del nuovo database può essere un backup del database di origine creato prima
del disastro. È possibile creare un nuovo database utilizzando la funzione point-in-time se il database di produzione è disponibile.
Funzionalità di disaster recovery
Databases for PostgreSQL supporta le seguenti funzioni di disaster recovery:
Funzione | Descrizione | Considerazione |
---|---|---|
Ripristino del backup | Creare il database da un backup precedentemente creato; vedere Gestione dei backup di Cloud Databases. | Le nuove stringhe di connessione per il database ripristinato devono essere referenziate in tutto il carico di lavoro. |
Ripristino del punto temporale | Creare il database dalla produzione live utilizzando il ripristino point-in-time | Ciò è possibile solo se il database attivo è disponibile e l'RPO (disastro) rientra nella finestra supportata. Non è utile se il cluster di produzione non è disponibile. Le nuove stringhe di connessione per il database ripristinato devono essere referenziate in tutto il carico di lavoro. |
Promuovere la replica di lettura | Creare repliche di sola lettura quando si pianifica un disastro nella stessa regione o in una regione remota. Promuovere la replica di sola lettura per il ripristino da un disastro. | La replica di lettura creata in precedenza deve essere disponibile. Le nuove stringhe di connessione per il database ripristinato devono essere referenziate in tutto il carico di lavoro. |
Pianificazione del ripristino in caso di disastro
Le fasi di disaster recovery devono essere praticate regolarmente. Nel costruire il vostro piano, considerate i seguenti scenari di fallimento e le relative soluzioni.
Operazione non riuscita | Risoluzione |
---|---|
Guasto hardware (punto singolo) | IBM fornisce un database resistente a un singolo punto di guasto hardware all'interno di una zona, senza necessità di configurazione. |
malfunzionamento zona | Failover automatico (#postgresql-high-availability). I membri del database sono distribuiti tra le zone. La configurazione di tre membri fornirà una maggiore resilienza in caso di guasti multipli della zona.
La replica sincrona riduce l'RPO a scapito delle prestazioni. |
Dati danneggiati | Ripristino del backup. Utilizzare il database ripristinato in produzione o per i dati di origine per correggere la corruzione nel database ripristinato.
Ripristino point-in-time. Utilizzare il database ripristinato in produzione o per i dati di origine per correggere la corruzione nel database ripristinato. |
Fallimento regionale | Ripristino del backup. Utilizzare il database ripristinato in produzione.
Promuovere la replica della lettura. Promuovere una replica di sola lettura a un database di lettura/scrittura. Utilizzare il database ripristinato in produzione |
Alta disponibilità a livello di applicazione
Le applicazioni che comunicano sulle reti e i servizi cloud sono soggette ad errori di connessione temporanei. Le applicazioni devono essere progettate in modo da riprovare le connessioni quando gli errori sono causati da una perdita temporanea di connettività con l'installazione o con IBM Cloud.
Poiché Databases for PostgreSQL è un servizio gestito, gli aggiornamenti regolari e la manutenzione del database fanno parte delle normali operazioni. Questo può occasionalmente causare brevi intervalli in cui il database non è disponibile. Può anche far sì che il database attivi un fail-over aggraziato, un tentativo e una riconnessione. Il database impiega un po' di tempo per determinare quale membro è una replica e quale è il leader, quindi potrebbe verificarsi una breve interruzione della connessione. I failover richiedono generalmente meno di 30 secondi.
Le applicazioni devono essere progettate per gestire le interruzioni temporanee del database, implementare la gestione degli errori per i comandi del database non riusciti e implementare la logica di retry per recuperare da un'interruzione temporanea.
Non sono previsti diversi minuti di indisponibilità del database o di interruzione della connessione. Aprire un caso di assistenza con i dettagli se si verificano periodi superiori a un minuto senza connettività, in modo da poter indagare.
Limiti connessioni
Databases for PostgreSQL imposta a 115 il numero massimo di connessioni al database PostgreSQL. 15 connessioni sono riservate al superutente per mantenere lo stato e l'integrità del database, mentre 100 connessioni sono disponibili per l'utente e le sue applicazioni. Dopo aver raggiunto il limite di connessione, qualsiasi tentativo di avviare una nuova connessione provoca un errore. Per evitare di sovraccaricare il deployment di connessioni, utilizzare il pooling delle connessioni o scalare il deployment e aumentare il limite di connessioni. Per ulteriori informazioni, consultare la pagina Gestione delle connessioni di PostgreSQL.
Le vostre responsabilità per HA e DR
Le seguenti informazioni possono aiutarvi a creare e a mettere in pratica costantemente il vostro piano per l'HA e il DR.
Quando si ripristina un database dai backup o si usa il ripristino point-in-time, viene creato un nuovo database con nuove stringhe di connessione. I carichi di lavoro e i processi esistenti devono essere adattati per utilizzare le nuove stringhe di connessione. La promozione di una replica di lettura in un cluster avrà un impatto simile, anche se le porzioni esistenti di sola lettura del carico di lavoro non saranno interessate.
Un database recuperato può anche avere bisogno delle stesse dipendenze create dal cliente del database danneggiato: accertatevi che questi e altri servizi esistano nella regione recuperata:
- IBM® Key Protect for IBM Cloud®
- Hyper Protect Crypto Services
Ricordate che l'eliminazione di un database elimina anche i backup ad esso associati. Tuttavia, i database eliminati possono essere recuperati entro un periodo di tempo limitato. Per informazioni specifiche sulle procedure di ripristino del database, consultare la documentazione.
Non è possibile copiare i backup dal sito IBM Cloud, quindi si consiglia di utilizzare gli strumenti specifici del database per ulteriori backup. Può essere necessario per ripristinare l'eliminazione di un database da parte di un malintenzionato, seguita da una bonifica di un database. Un'attenta gestione dell'accesso IAM ai database può contribuire a ridurre l'esposizione a questo problema.
La seguente lista di controllo associata a ciascuna caratteristica può aiutarvi a creare e mettere in pratica il vostro piano.
- Ripristino del backup
- Verificare che i backup siano disponibili con la frequenza desiderata per soddisfare i requisiti RPO. Gestione dei backup Cloud Databases documenta la frequenza dei backup. Considerare uno script utilizzando IBM Cloud® Code Engine- Lavorare con il produttore di eventi Periodic timer(cron) per creare backup aggiuntivi su richiesta per migliorare l'RPO se la criticità e le dimensioni del database lo consentono. Tuttavia, date le capacità del PITR di PostgreSQL's, valutare attentamente la necessità di backup aggiuntivi.
- Esistono alcune restrizioni sulle regioni di ripristino dei database: verificare che gli obiettivi di ripristino possano essere raggiunti leggendo Gestione dei backup di Cloud Databases.
- Verificate che il periodo di conservazione dei backup soddisfi i vostri requisiti.
- Pianificare regolarmente ripristini di prova per verificare che i tempi di ripristino effettivi rispettino l'RTO definito. Ricordate che le dimensioni del database influiscono in modo significativo sui tempi di ripristino. Considerate le strategie per ridurre al minimo i tempi di ripristino, come ad esempio la suddivisione di database di grandi dimensioni in unità più piccole e gestibili e l'eliminazione dei dati inutilizzati.
- Verificare il servizio Key Protect.
- Ripristino del punto temporale
- Verificare le procedure descritte in precedenza.
- Verificare che il backup desiderato sia presente nella finestra.
- Promuovere la replica di lettura
- Verificare l'esistenza di una replica di lettura nella regione di recupero.
- Esercitarsi nel processo di promozione: creare una replica di lettura temporanea nella regione desiderata. La replica temporanea può essere promossa in lettura/scrittura e si possono eseguire alcuni test con un impatto minimo sulla produzione.
Per saperne di più sulla responsabilità tra il cliente e IBM Cloud per l'utilizzo di Databases for PostgreSQL, vedere Responsabilità condivise per Cloud Databases.
Rimanete informati: notifiche su IBM
Gli aggiornamenti che interessano i carichi di lavoro dei clienti sono comunicati attraverso le notifiche di IBM Cloud. Per essere informati sulla manutenzione programmata, sugli annunci e sulle note di rilascio relative a questo servizio, consultate la pagina delle notifiche e dello stato del monitoraggio. Inoltre, consultate regolarmente la pagina della Politica delle versioni per gli ultimi aggiornamenti sulle versioni e sulle date di fine vita.