Ridimensionamento di cluster - Amazon Redshift
Elastic resize (Ridimensionamento elastico)Classic resize (Ridimensionamento classico)

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Ridimensionamento di cluster

Con l'evolversi delle esigenze prestazionali e di capacità del data warehouse, puoi ridimensionare il cluster per usufruire al meglio delle opzioni di calcolo e archiviazione fornite da Amazon Redshift.

Un'operazione di ridimensionamento è disponibile in due tipi:

  • Ridimensionamento elastico: puoi aggiungere o rimuovere nodi dal cluster. È inoltre possibile modificare il tipo di nodo, ad esempio da nodi DC2 a nodi RA3. Un ridimensionamento elastico viene in genere completato rapidamente, impiegando in media dieci minuti. Per questo motivo, la consigliamo come prima opzione. Quando esegui un ridimensionamento elastico, vengono ridistribuite le sezioni dei dati, ovvero le partizioni in cui sono allocati memoria e spazio su disco in ogni nodo. Il ridimensionamento elastico è appropriato quando:

    • Aggiungi o riduci nodi in un cluster esistente, ma non modifichi il tipo di nodo: questo è comunemente chiamato ridimensionamento locale. Quando si esegue questo tipo di ridimensionamento, alcune query in esecuzione vengono completate correttamente, ma altre possono essere eliminate come parte dell'operazione.

    • Cambi il tipo di nodo per un cluster: quando modifichi il tipo di nodo, viene creato uno snapshot e i dati vengono ridistribuiti dal cluster di origine a un cluster costituito dal nuovo tipo di nodo. Al termine, le query in esecuzione vengono eliminate. Come il ridimensionamento locale, si completa rapidamente.

  • Ridimensionamento classico: puoi modificare il tipo, il numero di nodi oppure entrambi, come nel ridimensionamento elastico. Il ridimensionamento classico richiede più tempo per essere completato, ma può essere utile nei casi in cui la modifica del conteggio dei nodi o del tipo di nodo verso cui migrare non rientra nei limiti per il ridimensionamento elastico. Ciò può essere applicato, ad esempio, quando la modifica del numero di nodi è molto grande.

Elastic resize (Ridimensionamento elastico)

Un'operazione di ridimensionamento elastico, quando si aggiungono o rimuovono nodi dello stesso tipo, prevede le seguenti fasi:

  1. Il ridimensionamento elastico acquisisce lo snapshot di un cluster. Questo snapshot include sempre tabelle senza backup per i nodi in cui è applicabile. (Alcuni tipi di nodi, come RA3, non hanno tabelle senza backup). Se il cluster non dispone di uno snapshot recente perché sono stati disabilitati gli snapshot automatici, l'operazione di backup richiederà più tempo. Per ridurre al mimino i tempi prima che inizi l'operazione di ridimensionamento, consigliamo di abilitare gli snapshot automatici o creare uno snapshot manuale. Quando avvii un ridimensionamento elastico ed è in corso un'operazione di snapshot, il ridimensionamento potrebbe non riuscire se l'operazione di snapshot non viene completata entro pochi minuti. Per ulteriori informazioni, consulta Snapshot e backup di Amazon Redshift.

  2. L'operazione esegue la migrazione dei metadati del cluster. Questo cluster non è disponibile per alcuni minuti. La maggior parte delle query viene temporaneamente sospesa e le connessioni vengono mantenute aperte. Tuttavia, è possibile che alcune query vengano eliminate. Questa fase è breve.

  3. Le connessioni delle sessioni vengono reintegrate e le query ripristinate.

  4. Il ridimensionamento elastico ridistribuisce i dati alle sezioni dei nodi in background. Il cluster è disponibile per le operazioni di lettura e scrittura, ma l'esecuzione di alcune query potrebbe richiedere più tempo.

  5. Al termine dell'operazione, Amazon Redshift invia una notifica di evento.

Il ridimensionamento elastico per modificare il tipo di nodo funziona in modo simile all'aggiunta o alla rimozione di nodi dello stesso tipo. Innanzitutto, viene creata uno snapshot. A un nuovo cluster di destinazione vengono forniti i dati più recenti dello snapshot; tali dati vengono trasferiti nel nuovo cluster in background. Durante questo periodo, i dati sono di sola lettura. Quando il processo di ridimensionamento è prossimo alla conclusione, Amazon Redshift aggiorna l'endpoint in modo da fare riferimento al nuovo cluster e tutte le connessioni al cluster di origine vengono eliminate.

È improbabile che un ridimensionamento elastico fallisca. Tuttavia, in caso di errore, il rollback avviene automaticamente nella maggior parte dei casi senza bisogno di alcun intervento manuale.

Se si dispone di nodi riservati, ad esempio nodi riservati DC2, è possibile eseguire l'aggiornamento ai nodi riservati RA3 quando si esegue un ridimensionamento. Puoi farlo quando esegui un ridimensionamento elastico o se utilizzi la console per eseguire il ripristino da uno snapshot. Tutto il processo può essere eseguito nella console. Per ulteriori informazioni sulla creazione di nodi RA3, consultare Aggiornamento ai tipi di nodo RA3.

Il ridimensionamento elastico non ordina le tabelle né recupera spazio sul disco, pertanto non deve essere considerato come sostituzione di un'operazione di vacuum. Per ulteriori informazioni, consultare Vacuum delle tabelle.

Il ridimensionamento elastico presenta le seguenti limitazioni:

  • Cluster di condivisione dati e ridimensionamento elastico: quando si aggiungono o si sottraggono nodi in un cluster producer di condivisione dati, non è possibile connettersi a tale cluster dai consumer mentre Amazon Redshift esegue la migrazione dei metadati del cluster. Analogamente, se si esegue un ridimensionamento elastico e si sceglie un nuovo tipo di nodo, la condivisione dati non è disponibile mentre le connessioni vengono interrotte e trasferite al nuovo cluster di destinazione. In entrambi i tipi di ridimensionamento elastico, il producer non è disponibile per diversi minuti.

  • Trasferimento dei dati da uno snapshot condiviso: per eseguire un ridimensionamento elastico in un cluster che trasferisce dati da uno snapshot condiviso, deve essere disponibile almeno un backup per il cluster. È possibile visualizzare i backup nell'elenco snapshot della console Amazon Redshift, mediante il comando describe-cluster-snapshots della CLI oppure mediante l'operazione API DescribeClusterSnapshots.

  • Limitazione della piattaforma: il ridimensionamento elastico è disponibile solo per i cluster che utilizzano la piattaforma EC2-VPC. Per ulteriori informazioni, consulta UsaEC2: VPC quando crei il tuo cluster.

  • Considerazioni sull'archiviazione: assicurati che la nuova configurazione del nodo disponga di spazio di archiviazione sufficiente per i dati esistenti. Potrebbe essere necessario aggiungere altri nodi o modificare la configurazione.

  • Dimensioni del cluster di origine e di destinazione: il numero e il tipo di nodi consentiti dal ridimensionamento elastico sono determinati dal numero di nodi nel cluster di origine e dal tipo di nodi scelto per il cluster ridimensionato. Per determinare le possibili configurazioni disponibili, è possibile utilizzare la console. Oppure puoi usare il describe-node-configuration-options AWS CLI comando con l'opzione. action-type resize-cluster Per ulteriori informazioni sul ridimensionamento tramite la console Amazon Redshift, consultare Ridimensionamento di un cluster.

    Il comando della CLI seguente descrive le opzioni di configurazione disponibili. In questo esempio, il cluster denominato mycluster è un cluster dc2.large a 8 nodi.

    aws redshift describe-node-configuration-options --cluster-identifier mycluster --region eu-west-1 --action-type resize-cluster

    Questo comando restituisce un elenco di opzioni con tipi di nodi consigliati, numero di nodi e utilizzo del disco per ogni opzione. Le configurazioni restituite possono variare in base al cluster di input specifico. È possibile scegliere una di queste configurazioni quando si specificano le opzioni del comando resize-cluster della CLI.

  • Limite massimo sui nodi aggiuntivi: il ridimensionamento elastico ha dei limiti sui nodi che puoi aggiungere a un cluster. Ad esempio, un cluster dc2 supporta il ridimensionamento elastico fino a raddoppiare il numero di nodi. Ad esempio, puoi aggiungere un nodo a un cluster dc2.8xlarge a 4 nodi per renderlo un cluster a 5 nodi o aggiungere altri nodi fino a raggiungerne 8.

    Nota

    I limiti di crescita e riduzione si basano sul tipo di nodo originale e sul numero di nodi del cluster originale o dell'ultimo ridimensionamento classico. Se il ridimensionamento elastico supera il limite di crescita o riduzione, utilizza un ridimensionamento classico.

    Con alcuni tipi di nodi ra3, è possibile aumentare il numero di nodi fino a quattro volte il numero esistente. In particolare, si supponga che il cluster sia costituito da nodi ra3.4xlarge o ra3.16xlarge. È quindi possibile utilizzare il ridimensionamento elastico per aumentare il numero di nodi in un cluster a 8 nodi a 32. Oppure è possibile scegliere un valore al di sotto del limite. La possibilità di aumentare il cluster di 4 volte dipende dalle dimensioni del cluster di origine. Se il cluster ha nodi ra3.xlplus, il limite è il doppio.

    Tutti i tipi di nodi ra3 supportano una diminuzione del numero di nodi fino a un quarto del numero esistente. Ad esempio, è possibile ridurre la dimensione di un cluster con nodi ra3.4xlarge da 12 nodi a 3 o a un numero superiore al minimo.

    Nella tabella seguente sono elencati i limiti di crescita e riduzione per ogni tipo di nodo che supporta il ridimensionamento elastico.

    Tipo di nodo originale Limite di crescita Limite di riduzione

    ra3.16xlarge

    		 4x (da 4 a 16 nodi, ad esempio)

    A un quarto del numero (da 16 a 4 nodi, ad esempio)

    ra3.4xlarge

    4x

    		 A un quarto del numero

    ra3.xlplus

    2x (da 4 a 8 nodi, ad esempio)

    A un quarto del numero

    dc2.8xlarge

    2x

    A metà del numero (da 16 a 8 nodi, ad esempio)

    dc2.large

    2x

    A metà del numero
    Nota

    Scelta dei tipi di nodi precedenti quando si ridimensiona un cluster RA3: se si tenta di ridimensionare un cluster con nodi RA3 a un altro tipo di nodo, ad esempio DC2, nella console viene visualizzato un messaggio di avviso di convalida e l'operazione di ridimensionamento non verrà completata. Ciò si verifica perché il ridimensionamento in base ai tipi di nodi legacy non è supportato. Questo serve a impedire a un cliente di ridimensionare un tipo di nodo obsoleto oppure obsoleto a breve. Questo vale sia per il ridimensionamento elastico che per il ridimensionamento classico.

Classic resize (Ridimensionamento classico)

Il ridimensionamento classico gestisce i casi in cui la modifica della dimensione del cluster o del tipo di nodo non è supportata dal ridimensionamento elastico. Quando esegui un ridimensionamento classico, Amazon Redshift crea un cluster di destinazione ed esegue la migrazione dei dati e dei metadati dal cluster di origine.

Il ridimensionamento classico a RA3 può fornire una migliore disponibilità

Il ridimensionamento classico è stato migliorato quando il tipo di nodo di destinazione è RA3. Ciò è stato possibile grazie all'utilizzo di un'operazione di backup e ripristino tra il cluster di origine e quello di destinazione. Quando il ridimensionamento inizia, il cluster di origine si riavvia e non è disponibile per alcuni minuti. Dopodiché, il cluster diventa disponibile per le operazioni di lettura e scrittura mentre il ridimensionamento continua in background.

Controllo del cluster

Per assicurarti di ottenere prestazioni e risultati ottimali quando esegui un ridimensionamento classico su un cluster RA3, completa questo elenco di controllo. Se non segui l'elenco di controllo, potresti non ottenere alcuni dei vantaggi del ridimensionamento classico con i nodi RA3, come la possibilità di eseguire operazioni di lettura e scrittura.

  1. La dimensione dei dati deve essere inferiore a due petabyte (un petabyte equivale a 1.000 terabyte). Per convalidare la dimensione dei dati, crea uno snapshot e controlla le dimensioni. Puoi anche eseguire la seguente query per verificare le dimensioni: 

    SELECT
sum(case when lower(diststyle) like ('%key%') then size else 0 end) distkey_blocks,
sum(size) as total_blocks,
((distkey_blocks/(total_blocks*1.00)))*100 as Blocks_need_redist
FROM svv_table_info;

    La tabella svv_table_info è visibile solo per gli utenti con privilegi avanzati.

  2. Prima di iniziare un ridimensionamento classico, assicurati di avere uno snapshot manuale precedente di 10 ore al massimo. In caso contrario, acquisisci uno snapshot.

  3. Lo snapshot utilizzato per eseguire il ridimensionamento classico non può essere utilizzato per il ripristino di una tabella o per altri scopi.

  4. Il cluster deve trovarsi in un VPC.

Operazioni di ordinamento e distribuzione derivanti dal ridimensionamento classico a RA3

Durante il ridimensionamento classico a RA3, le tabelle con distribuzione delle chiavi migrate con la distribuzione uniforme vengono riconvertite nel loro stile di distribuzione originale. La durata dipende dalla dimensione dei dati e dal carico di lavoro del cluster. Durante la migrazione dei dati viene data maggiore priorità all'esecuzione dei carichi di lavoro delle query. Per ulteriori informazioni, consulta Piani di distribuzione. Le operazioni di lettura e scrittura nel database funzionano durante questo processo di migrazione, tuttavia potrebbe essere necessario più tempo per il completamento delle query. Il dimensionamento simultaneo può migliorare le prestazioni durante il processo, aggiungendo risorse per i carichi di lavoro delle query. Puoi vedere l'avanzamento della migrazione dei dati visualizzando i risultati nelle viste SYS_RESTORE_STATE e SYS_RESTORE_LOG. Seguono ulteriori informazioni sul monitoraggio.

Dopo il completo ridimensionamento del cluster, si verifica il seguente comportamento di ordinamento:

  • Se il ridimensionamento comporta che il cluster abbia più sezioni, le tabelle di distribuzione KEY sono parzialmente non ordinate, ma le tabelle EVEN rimangono ordinate. Inoltre, le informazioni sulla quantità di dati ordinati potrebbero non essere aggiornate subito dopo il ridimensionamento. Dopo il recupero della chiave, il vacuum automatico ordina la tabella nel tempo.

  • Se il ridimensionamento comporta che una riduzione del numero di sezioni del cluster, le tabelle di distribuzione KEY e EVEN sono parzialmente non ordinate. Il vacuum automatico ordina la tabella nel tempo.

Per ulteriori informazioni sul vacuum automatico della tabella, consulta Vacuum delle tabelle. Per ulteriori informazioni sulle sezioni dei nodi di calcolo, consulta Architettura del sistema di data warehouse.

Fasi del ridimensionamento classico quando il cluster di destinazione è RA3

Il ridimensionamento classico consiste nelle seguenti fasi, quando il tipo di cluster di destinazione è RA3 e sono soddisfatti i prerequisiti descritti nella sezione precedente.

  1. La migrazione inizia dal cluster di origine verso il cluster di destinazione. Dopo aver effettuato il provisioning del nuovo cluster di destinazione, Amazon Redshift invia un evento di notifica che indica l'inizio del ridimensionamento, quindi riavvia il cluster esistente, interrompendo tutte le connessioni. Se il cluster esistente è un cluster producer di condivisione dati, anche le connessioni ai cluster consumer vengono chiuse. Il riavvio richiede alcuni minuti.

    Tieni presente che qualsiasi relazione del database, come una tabella o una vista materializzata, creata con BACKUP NO non viene mantenuta durante il ridimensionamento classico. Per ulteriori informazioni, consulta CREATE MATERIALIZED VIEW.

  2. Dopo il riavvio, il database è disponibile per le operazioni di lettura e scrittura. Riprende anche la condivisione dei dati, il che richiede qualche minuto in più.

  3. I dati vengono migrati al cluster di destinazione. Quando il tipo di nodo di destinazione è RA3, le operazioni di lettura e scrittura sono disponibili durante la migrazione dei dati.

  4. Quando il processo di ridimensionamento è prossimo alla conclusione, Amazon Redshift aggiorna l'endpoint sul cluster di destinazione e tutte le connessioni al cluster di origine vengono eliminate. Il cluster di destinazione diventa il producer della condivisione dei dati.

  5. Il ridimensionamento viene completato. Amazon Redshift invia una notifica dell'evento.

È possibile visualizzare lo stato di avanzamento del processo di dimensionamento nella console Amazon Redshift. L'intervallo di tempo necessario per ridimensionare un cluster dipende dalla quantità di dati.

Nota

Scelta dei tipi di nodi precedenti quando si ridimensiona un cluster RA3: se si tenta di ridimensionare da un cluster con nodi RA3 a un altro tipo di nodo, ad esempio DC2, nella console viene visualizzato un messaggio di avviso di convalida e l'operazione di ridimensionamento non verrà completata. Ciò si verifica perché il ridimensionamento in base ai tipi di nodi legacy non è supportato. Questo serve a impedire a un cliente di ridimensionare un tipo di nodo obsoleto oppure obsoleto a breve. Questo vale sia per il ridimensionamento elastico che per il ridimensionamento classico.

Monitoraggio di un ridimensionamento classico quando il cluster di destinazione è RA3

Per monitorare il ridimensionamento classico in esecuzione di un cluster con provisioning, inclusa la distribuzione delle chiavi, usa SYS_RESTORE_STATE. Mostra la percentuale di completamento della tabella in fase di conversione. Devi essere un utente con privilegi avanzati per poter accedere ai dati.

Elimina le tabelle che non ti servono quando esegui un ridimensionamento classico. In questo modo, le tabelle esistenti possono essere distribuite più rapidamente.

Fasi del ridimensionamento classico quando il cluster di destinazione non è RA3

Il ridimensionamento classico prevede quanto segue, quando il tipo di nodo di destinazione è diverso da RA3, ad esempio DC2.

  1. La migrazione inizia dal cluster di origine verso il cluster di destinazione. Dopo aver effettuato il provisioning del nuovo cluster di destinazione, Amazon Redshift invia un evento di notifica che indica l'inizio del ridimensionamento, quindi riavvia il cluster esistente, interrompendo tutte le connessioni. Se il cluster esistente è un cluster producer di condivisione dati, anche le connessioni ai cluster consumer vengono chiuse. Il riavvio richiede alcuni minuti.

    Tieni presente che qualsiasi relazione del database, come una tabella o una vista materializzata, creata con BACKUP NO non viene mantenuta durante il ridimensionamento classico. Per ulteriori informazioni, consulta CREATE MATERIALIZED VIEW.

  2. Dopo il riavvio, il database è disponibile in sola lettura. Riprende la condivisione dei dati, il che richiede qualche minuto in più.

  3. I dati vengono migrati al cluster di destinazione. Il database rimane in sola lettura.

  4. Quando il processo di ridimensionamento è prossimo alla conclusione, Amazon Redshift aggiorna l'endpoint sul cluster di destinazione e tutte le connessioni al cluster di origine vengono eliminate. Il cluster di destinazione diventa il producer della condivisione dei dati.

  5. Il ridimensionamento viene completato. Amazon Redshift invia una notifica dell'evento.

È possibile visualizzare lo stato di avanzamento del processo di dimensionamento nella console Amazon Redshift. L'intervallo di tempo necessario per ridimensionare un cluster dipende dalla quantità di dati.

Nota

Possono essere necessari giorni o anche settimane per ridimensionare un cluster con una grande quantità di dati quando il cluster di destinazione non è RA3 o non soddisfa i prerequisiti di un cluster di destinazione RA3 descritti nella sezione precedente.

Tieni inoltre presente che la capacità di archiviazione utilizzata per il cluster può aumentare dopo un ridimensionamento classico. Si tratta di un normale comportamento del sistema quando il cluster contiene porzioni di dati aggiuntive risultanti dal ridimensionamento classico. Questo uso di capacità aggiuntiva può verificarsi anche quando il numero di nodi nel cluster rimane invariato.

Ridimensionamento elastico e ridimensionamento classico

Nella tabella seguente viene confrontato il comportamento tra i due tipi di ridimensionamento.

Ridimensionamento elastico e ridimensionamento classico
Comportamento Elastic resize (Ridimensionamento elastico) Classic resize (Ridimensionamento classico) Commenti
Conservazione dei dati di sistema Il ridimensionamento elastico conserva i dati dei log di sistema. Il ridimensionamento classico non conserva tabelle e dati di sistema. Se hai abilitato la registrazione di controllo nel tuo cluster di origine, puoi continuare ad accedere ai log in Amazon S3 o CloudWatch in Amazon S3, dopo un ridimensionamento. Puoi conservare o eliminare questi log, in base a quanto specificato nelle policy dei dati.
Modifica dei tipi di nodo

Ridimensionamento elastico, quando il tipo di nodo non cambia: ridimensionamento sul posto e la maggior parte delle query vengono conservate.

Ridimensionamento elastico, con un nuovo tipo di nodo selezionato: viene creato un nuovo cluster. Le query vengono eliminate al termine del processo di ridimensionamento.

 Ridimensionamento classico: viene creato un nuovo cluster. Le query vengono eliminate al termine del processo di ridimensionamento.
Conservazione di sessioni e query Il ridimensionamento elastico conserva sessioni e query quando il tipo di nodo è lo stesso nel cluster di origine e di destinazione. Se si sceglie un nuovo tipo di nodo, le query vengono eliminate. Il ridimensionamento classico non conserva sessioni e query. Le query vengono eliminate. Quando le query vengono eliminate, ci si può aspettare un certo peggioramento delle prestazioni. È meglio eseguire un'operazione di ridimensionamento durante un periodo di utilizzo leggero.
Annullamento di un'operazione di ridimensionamento

Non è possibile annullare un ridimensionamento elastico.

È possibile annullare l'operazione di ridimensionamento classico prima che sia completata, scegliendo Annulla ridimensionamento nei dettagli dei cluster nella console Amazon Redshift.

La durata dell'annullamento dell'operazione di ridimensionamento dipende dalla fase in cui si trova il ridimensionamento al momento in cui viene annullato. Il cluster non sarà disponibile fino al completamento dell'operazione di annullamento. Se il ridimensionamento si trova nella fase finale, non potrai annullare l'operazione.

Il ridimensionamento classico in un cluster RA3 non può essere annullato.

Pianificazione di un ridimensionamento

Puoi pianificare le operazioni di ridimensionamento per il cluster in modo da aumentarlo per anticipare un utilizzo elevato o ridurlo per diminuire i costi. La pianificazione funziona sia per il ridimensionamento elastico che per il ridimensionamento classico. Puoi pianificare una query sulla console Amazon Redshift. Per ulteriori informazioni, consulta Ridimensionamento di un cluster in Gestione dei cluster tramite la console. Puoi anche utilizzare AWS CLI le nostre operazioni API di Amazon Redshift per pianificare un ridimensionamento. Per ulteriori informazioni, consulta create-scheduled-action nel AWS CLI Command Reference o CreateScheduledAction nel Amazon Redshift API Reference.

Snapshot, ripristino e ridimensionamento

Il ridimensionamento elastico è il metodo più rapido per ridimensionare un cluster Amazon Redshift. Se il ridimensionamento elastico non è facoltativo per te e hai bisogno di un accesso in scrittura quasi costante al cluster, puoi utilizzare le operazioni di snapshot e ripristino con ridimensionamento classico descritte nella seguente sezione. Questo approccio richiede che tutti i dati scritti sul cluster di origine dopo l'acquisizione dello snapshot siano copiati manualmente nel cluster target dopo lo switch. A seconda della durata della copia, potrebbe essere necessario ripetere l'operazione varie volte fino a che non avrai gli stessi dati in entrambi i cluster. Quindi, puoi effettuare lo switch al cluster di destinazione. Questo processo può avere un impatto negativo sulle query esistenti fino a che il set di dati completo non è disponibile nel cluster di destinazione, ma riduce al minimo la durata per la quale non puoi scrivere sul database.

L'approccio mediante snapshot, ripristino e ridimensionamento classico utilizza il seguente processo:

  1. Acquisire una snapshot del cluster esistente. Il cluster esistente è il cluster di origine.

  2. Prendere nota dell'ora in cui è stato acquisito lo snapshot. In questo modo sarà possibile individuare in un secondo momento il punto in cui eseguire nuovamente i processi di estrazione, transazione e caricamento (ETL) per caricare i dati post-snapshot nel database di destinazione.

  3. Ripristinare lo snapshot in un nuovo cluster. Questo nuovo cluster è il cluster target. Verificare la presenza dei dati di esempio nel cluster target.

  4. Ridimensionare il cluster target. Scegliere il nuovo tipo di nodo, il numero di nodi e altre impostazioni per il cluster di destinazione.

  5. Esaminare i caricamenti dai processi ETL avvenuti dopo l'acquisizione dello snapshot del cluster di origine. Accertarsi di ricaricare gli stessi dati nello stesso ordine nel cluster di destinazione. Nel caso di caricamenti in esecuzione, ripetere questo processo varie volte fino a che i dati non saranno gli stessi in entrambi i cluster.

  6. Interrompere tutte le query in esecuzione nel cluster di origine. A questo proposito, è possibile riavviare il cluster oppure accedere come utente con privilegi avanzati e utilizzare i comandi PG_CANCEL_BACKEND e PG_TERMINATE_BACKEND. Il riavvio del cluster è il modo più semplice di assicurarsi che il cluster non è disponibile.

  7. Rinominare il cluster di origine. Ad esempio, cambiare il nome da examplecluster a examplecluster-source.

  8. Rinominare il cluster con il nome del cluster di origine prima che venisse cambiato, ad esempio, rinominare il cluster di destinazione da precedente a examplecluster. Da questo momento, tutte le applicazioni che utilizzano l'endpoint contenente examplecluster si connettono al cluster di destinazione.

  9. Eliminare il cluster di origine dopo lo switch al cluster target e verificare che tutti i processi funzionino come previsto.

In alternativa, puoi rinominare i cluster di origine e destinazione prima di ricaricare i dati nel cluster di destinazione. Questo approccio funziona se non hai la necessità di aggiornare immediatamente i sistemi e i report dipendenti con quelli del cluster di destinazione. In questo caso, la fase 6 è l'ultima del processo descritto precedentemente.

Il processo di assegnazione di un nuovo nome è necessario solo se vuoi che le applicazioni continuino a utilizzare lo stesso endpoint per connettersi al cluster. Se non c'è questa necessità, puoi invece aggiornare le applicazioni che si connettono al cluster per utilizzare l'endpoint del cluster di destinazione senza assegnare un nuovo nome al cluster.

Riutilizzare un nome di cluster presenta due vantaggi. Il primo è che non è necessario aggiornare le stringhe di connessione delle applicazioni in quanto l'endpoint non cambia, anche se ciò avviene per il cluster sottostante. In secondo luogo, gli elementi correlati come gli CloudWatch allarmi Amazon e le notifiche di Amazon Simple Notification Service (Amazon SNS) sono legati al nome del cluster. Ciò significa che puoi continuare a utilizzare gli stessi allarmi e le stesse notifiche che hai configurato per il cluster. L'esigenza di un utilizzo continuo è motivo di preoccupazione soprattutto negli ambienti di produzione, dove è necessario disporre della flessibilità di ridimensionare il cluster senza dover riconfigurare gli elementi correlati come gli allarmi e le notifiche.