Cluster e istanze database di Amazon Neptune

Un cluster database Amazon Neptune gestisce l'accesso ai dati tramite query. Un cluster è composto da:

• Un'istanza database primaria.

• Fino a 15 istanze database di replica di lettura.

Tutte le istanze di un cluster condividono lo stesso volume di archiviazione gestito sottostante, progettato per garantire affidabilità e disponibilità elevata.

La connessione alle istanze database del cluster database avviene tramite endpoint Neptune.

Istanza database primaria in un cluster database Neptune

L'istanza database primaria coordina tutte le operazioni di scrittura sul volume di archiviazione sottostante del cluster database. Supporta anche le operazioni di lettura.

Può esserci solo un'istanza database primaria in un cluster database Neptune. Se l'istanza primaria non è più disponibile, Neptune esegue automaticamente il failover su una delle istanze di replica di lettura con una priorità che è possibile specificare.

Istanze database di replica di lettura in un cluster database Neptune

Dopo avere creato l'istanza primaria per un cluster database, puoi creare fino a 15 istanze di replica di lettura nel cluster database, al fine di supportare le query di sola lettura.

Le istanze database di replica di lettura Neptune funzionano bene per il dimensionamento della capacità di lettura perché sono dedicate completamente a operazioni di lettura nel volume cluster. Tutte le operazioni di lettura sono gestite dall'istanza primaria. Ogni istanza database di replica di lettura ha il proprio endpoint.

Poiché il volume di archiviazione del cluster è condiviso tra tutte le istanze di un cluster, tutte le istanze di replica di lettura restituiscono gli stessi dati per i risultati delle query con un ritardo di replica minimo. Questo ritardo è in genere molto inferiore a 100 millisecondi dopo che l'istanza primaria scrive un aggiornamento, sebbene possa essere un po' più lungo quando il volume delle operazioni di scrittura è molto elevato.

La disponibilità di una o più istanze di replica di lettura in diverse zone di disponibilità può aumentare la disponibilità, poiché le repliche di lettura fungono da destinazioni di failover per l'istanza primaria. Pertanto, se si verifica un errore nell'istanza primaria, Neptune promuove un'istanza di replica di lettura a diventare l'istanza primaria. Quando ciò accade, si verifica una breve interruzione mentre l'istanza promossa viene riavviata, durante la quale le richieste di lettura e scrittura effettuate all'istanza primaria hanno esito negativo restituendo un'eccezione.

Al contrario, se il cluster database non include istanze di replica di lettura, il cluster database rimane non disponibile quando l'istanza primaria ha esito negativo finché non viene ricreata. La ricreazione dell'istanza primaria richiede molto più tempo rispetto alla promozione di un'istanza di replica di lettura.

Per garantire un'elevata disponibilità, è consigliabile creare una o più istanze di replica di lettura che abbiano la stessa classe di istanza database dell'istanza primaria e si trovino in zone di disponibilità diverse rispetto all'istanza primaria. Per informazioni, consulta Tolleranza ai guasti di un cluster database Neptune..

Utilizzando la console, puoi creare un'implementazione Multi-AZ semplicemente specificando AZ multiple durante la creazione di un cluster database. Se un cluster database si trova in una sola zona di disponibilità, è possibile renderlo un cluster database Multi-AZ aggiungendo una replica Neptune in una zona di disponibilità diversa.

Nota

Non è possibile creare un'istanza di replica di lettura crittografata per un cluster database Neptune non crittografato o un'istanza di replica di lettura non crittografata per un cluster database Neptune crittografato.

Per informazioni dettagliate su come creare un'istanza database di replica di lettura Neptune, consulta Creazione di un'istanza reader Neptune mediante la console.

Dimensionamento delle istanze database in un cluster database Neptune

Dimensionare le istanze del cluster database Neptune in base ai requisiti di CPU e memoria. Il numero di vCPU di un'istanza determina il numero di thread di query che gestiscono le query in entrata. La quantità di memoria di un'istanza determina la dimensione della cache del buffer, utilizzata per archiviare copie delle pagine di dati recuperate dal volume di archiviazione sottostante.

Ogni istanza database Neptune ha un numero di thread di query pari a 2 volte il numero di vCPU dell'istanza. Un'istanza r5.4xlarge, ad esempio, con 16 vCPU, ha 32 thread di query e può quindi elaborare 32 query contemporaneamente.

Le query aggiuntive che arrivano mentre tutti i thread di query sono occupati vengono inserite in una coda sul lato server ed elaborate in modo FIFO non appena i thread di query diventano disponibili. Questa coda lato server può contenere circa 8000 richieste in sospeso. Una volta piena, Neptune risponde alle richieste aggiuntive con ThrottlingException. Puoi monitorare il numero di richieste in sospeso con la MainRequestQueuePendingRequests CloudWatch metrica o utilizzando l'endpoint Gremlin Query Status con il parametro. includeWaiting

Il tempo di esecuzione delle query dal punto di vista del client include il tempo trascorso in coda, oltre al tempo impiegato per eseguire effettivamente la query.

Un carico di scrittura simultaneo sostenuto che utilizza tutti i thread di query dell'istanza database primaria indica idealmente un utilizzo della CPU pari o superiore al 90%, il che indica che tutti i thread di query sul server sono attivamente impegnati a svolgere un lavoro utile. Tuttavia, l'utilizzo effettivo della CPU è spesso leggermente inferiore, anche con un carico di scrittura simultaneo sostenuto. Ciò è in genere dovuto al fatto che i thread di query sono in attesa del completamento delle operazioni di I/O sul volume di archiviazione sottostante. Neptune utilizza le scritture quorum che creano sei copie dei dati in tre zone di disponibilità e quattro di questi sei nodi di archiviazione devono riconoscere una scrittura perché sia considerata durevole. Mentre un thread di query attende questo quorum dal volume di archiviazione, viene bloccato, riducendo così l'utilizzo della CPU.

Se si ha un carico di scrittura seriale in cui si esegue una scrittura dopo l'altra e si attende il completamento della prima scrittura prima di iniziare la successiva, è possibile aspettarsi che l'utilizzo della CPU sia ancora inferiore. La quantità esatta dipenderà dal numero di vCPU e thread di query (maggiore è il numero di thread di query, minore sarà la CPU complessiva per query), con una certa riduzione causata dall'attesa dell'I/O.

Per ulteriori informazioni su come dimensionare al meglio le istanze database, consulta Scelta del tipo di istanza database Neptune giusto. Per i prezzi di ogni tipo di istanza, consulta la pagina dei prezzi di Neptune.

Monitoraggio delle prestazioni delle istanze database in Neptune

Puoi utilizzare le CloudWatch metriche di Neptune per monitorare le prestazioni delle tue istanze DB e tenere traccia della latenza delle query osservata dal client. Per informazioni, consulta Utilizzo CloudWatch per monitorare le prestazioni delle istanze DB in Neptune.