Affidabilità Amazon Aurora

Il design di Aurora assicura affidabilità, durevolezza e tolleranza agli errori. È possibile sfruttare varie opzioni per configurare l'architettura del cluster database Aurora in modo da ottimizzare la disponibilità, come aggiungere repliche di Aurora e posizionarle in zone di disponibilità diverse. Inoltre Aurora include una serie di caratteristiche automatiche che lo rendono una soluzione database estremamente affidabile.

Riparazione automatica dello storage

Dal momento che Aurora conserva varie copie dei dati in tre zone di disponibilità, il rischio di perdita dei dati a seguito di un problema con un disco è estremamente remoto. Aurora inoltre rileva automaticamente gli errori nei volumi dei dischi che formano il volume di cluster. In caso di errore in un volume del disco, Aurora ripara immediatamente il segmento. Quando Aurora ripara il segmento del disco, utilizza i dati in altri volumi che creano il volume del cluster per garantire che i dati del segmento riparato siano aggiornati. Di conseguenza, Aurora evita la perdita di dati e riduce la necessità di eseguire un point-in-time ripristino per il ripristino da un guasto del disco.

Cache delle pagine superstite

In Aurora, ogni cache delle pagine dell'istanza viene gestita con un processo separato dal database, che consente alla cache di pagina di sopravvivere in modo indipendente dal database. (La cache della pagina è anche chiamata pool di buffer InnoDB su Aurora My SQL e cache buffer su Aurora Postgre.) SQL

Nella remota eventualità di un errore del database, la cache delle pagine rimane in memoria. Questo consente di mantenere le pagine di dati "precaricate" nella cache delle pagine quando il database viene riavviato. Tale espediente consente di migliorare le prestazioni, perché elimina la necessità di query iniziali per eseguire operazioni di I/O di lettura per "precaricare" la cache delle pagine.

Per Aurora MySQL, il comportamento della cache delle pagine durante il riavvio e il failover è il seguente:

• È possibile riavviare l'istanza di writer senza riavviare le istanze del lettore.

  • Se le istanze di lettura non vengono riavviate al riavvio dell'istanza di scrittura, non perdono le cache delle pagine.

  • Se le istanze di lettura vengono riavviate al riavvio dell'istanza di scrittura, perdono le cache delle pagine.

• Quando un'istanza di lettura viene riavviata, entrambe le cache delle pagine sulle istanze di scrittura e lettura sopravvivono.

• Quando il cluster database esegue il failover, l'effetto è simile al riavvio di un'istanza di scrittura. Sulla nuova istanza di scrittura (in precedenza l'istanza di lettura) la cache delle pagine sopravvive, ma sull'istanza di lettura (in precedenza l'istanza di scrittura), la cache delle pagina non sopravvive.

Per Aurora PostgreSQL, è possibile utilizzare la gestione della cache del cluster per conservare la cache della pagina di un'istanza reader designata che diventa l'istanza writer dopo il failover. Per ulteriori informazioni, consulta Ripristino rapido dopo il failover con Cluster Cache Management per Aurora PostgreSQL.

Ripristino in seguito a riavvii non pianificati

Aurora è progettato per eseguire il ripristino quasi istantaneo dopo un riavvio non pianificato per continuare a fornire i dati dell'applicazione senza il log binario. Aurora esegue il ripristino in modo asincrono su thread paralleli, in modo che il database sia aperto e immediatamente disponibile dopo un riavvio non pianificato.

Per ulteriori informazioni, consulta Tolleranza ai guasti di un cluster DB Aurora e Ottimizzazioni per ridurre i tempi di riavvio del database.

Di seguito sono riportate le considerazioni relative alla registrazione binaria e al ripristino da riavvio non pianificato su Aurora My: SQL

• L'attivazione dei log binari in Aurora incide direttamente sui tempi di ripristino dopo un riavvio non pianificato, perché obbliga l'istanza database a eseguire il ripristino dei log binari.

• Il tipo di log binari usati incide sulle dimensioni e sull'efficienza dell'operazione. Partendo dalla stessa quantità di attività del database, alcuni formati inseriscono nei log binari un numero maggiore di informazioni rispetto ad altri. Le seguenti impostazioni del parametro binlog_format modificano la quantità di dati inseriti nei log:

  • ROW– – Massima quantità di dati

  • STATEMENT– – Minima quantità di dati

  • MIXED– – Una quantità di dati moderata che in genere rappresenta il compromesso ottimale fra integrità dei dati e prestazioni

  La quantità di dati dei log binari influisce sui tempi di ripristino. Con l'inserimento di una grande quantità di dati nei log binari, l'istanza database deve elaborare più dati, allungando i tempi di ripristino.

• Per ridurre il sovraccarico di calcolo e migliorare i tempi di ripristino con la registrazione binaria, puoi utilizzare Enhanced binlog. Il binlog avanzato migliora i tempi di ripristino del database fino al 99%. Per ulteriori informazioni, consulta Configurazione di binlog avanzato per Aurora My SQL.

• Aurora non necessita dei log binari per replicare i dati all'interno di un cluster DB o per eseguire point-in-time restore (). PITR

• Se non hai bisogno del log binario per la replica esterna (o di uno stream esterno del log binario), ti consigliamo di impostare il parametro binlog_format su OFF per disattivare i log binari. In questo modo, puoi abbreviare i tempi di ripristino.

Per ulteriori informazioni sui log binari e la replica in Aurora, consulta Replica con Amazon Aurora. Per ulteriori informazioni sulle implicazioni dei diversi tipi di SQL replica My, consulta Vantaggi e svantaggi della replica basata su istruzioni e su righe nella documentazione My. SQL