Elastic resize (Ridimensionamento elastico)Classic resize (Ridimensionamento classico)

Ridimensionamento di un 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.

Quando si modificano le dimensioni di un cluster, si specifica un numero di nodi o un tipo di nodo diverso dalla configurazione corrente del cluster. Durante il processo di ridimensionamento del cluster, è possibile solo leggere le query, non è possibile eseguire query di scrittura o lettura/scrittura sul cluster.

Per ulteriori informazioni sul ridimensionamento dei cluster, inclusa la descrizione di approcci diversi del processo di ridimensionamento, vedi Ridimensionamento di un cluster.

Per ridimensionare un cluster

Accedi a AWS Management Console e apri la console Amazon Redshift all'indirizzo. https://console.aws.amazon.com/redshiftv2/
Dal menu di navigazione, scegliere Clusters (Cluster).
Scegli il cluster da ridimensionare.
In Actions (Operazioni), scegli Resize (Ridimensiona). Appare la pagina Resize cluster (Ridimensiona cluster).
Segui le istruzioni visualizzate nella pagina. È possibile ridimensionare il cluster ora, una volta in un momento specifico oppure aumentare e diminuire le dimensioni del cluster in base a una pianificazione.
A seconda delle scelte effettuate, scegliere Resize now (Ridimensiona ora) o Schedule resize (Pianifica ridimensionamento).

Se disponi di nodi riservati, puoi eseguire l'upgrade a nodi RA3 riservati. Puoi farlo quando usi la console per eseguire il ripristino da una snapshot o esegui un ridimensionamento elastico. La console può guidarti attraverso questo processo. Per ulteriori informazioni sull'aggiornamento ai RA3 nodi, consulta Aggiornamento ai tipi di nodi. RA3

Un'operazione di ridimensionamento è disponibile in due tipi:

Ridimensionamento elastico: puoi aggiungere o rimuovere nodi dal cluster. Puoi anche cambiare il tipo di nodo, ad esempio da DC2 nodi 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.

Argomenti

Elastic resize (Ridimensionamento elastico)
Classic resize (Ridimensionamento classico)

Elastic resize (Ridimensionamento elastico)

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

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, ad esempioRA3, 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.
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.
Le connessioni delle sessioni vengono reintegrate e le query ripristinate.
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.
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 DC2 riservati, è possibile eseguire l'aggiornamento a nodi RA3 riservati 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 sull'aggiornamento ai RA3 nodi, consulta Aggiornamento ai tipi di nodi. 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. Puoi visualizzare i tuoi backup nell'elenco degli snapshot della console Amazon Redshift, describe-cluster-snapshots CLI nel comando o nell'operazione. DescribeClusterSnapshots API
Restrizione 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 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 CLI comando di esempio 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 delle configurazioni restituite quando si specificano le opzioni del resize-cluster CLI comando.

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
ra3. Large	2x	A metà 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 RA3 cluster: se si tenta di ridimensionare un cluster con RA3 nodi a un altro tipo di nodo, ad esempio, nella console viene visualizzato un messaggio di avviso di convalida e l'operazione di ridimensionamento non viene completata. DC2 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.

Ridimensionamento classico per offrire una migliore disponibilità RA3

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 le migliori prestazioni e risultati quando esegui un ridimensionamento classico su un RA3 cluster, completa questa lista di controllo. Se non segui la checklist, potresti non ottenere alcuni dei vantaggi del ridimensionamento classico con i RA3 nodi, come la possibilità di eseguire operazioni di lettura e scrittura.

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.
Prima di iniziare un ridimensionamento classico, assicurati di avere uno snapshot manuale precedente di 10 ore al massimo. In caso contrario, acquisisci uno snapshot.
Lo snapshot utilizzato per eseguire il ridimensionamento classico non può essere utilizzato per il ripristino di una tabella o per altri scopi.
Il cluster deve trovarsi in un. VPC

Operazioni di ordinamento e distribuzione risultanti dal ridimensionamento classico a RA3

Durante il ridimensionamento classico aRA3, le tabelle con KEY distribuzione che vengono migrate durante la EVEN distribuzione vengono riconvertite allo 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. È possibile visualizzare lo stato di avanzamento della migrazione dei dati visualizzando i risultati delle 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 fa sì che il cluster disponga di più sezioni, le tabelle di KEY distribuzione vengono parzialmente disordinate, ma le EVEN tabelle 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 un minor numero di sezioni nel cluster, sia le tabelle di distribuzione che quelle di KEY distribuzione vengono parzialmente disordinateEVEN. 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 di ridimensionamento classiche quando il cluster di destinazione è RA3

Il ridimensionamento classico prevede i seguenti passaggi, quando il tipo di cluster di destinazione è RA3 e sono stati soddisfatti i prerequisiti descritti nella sezione precedente.

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, vedere. CREATEMATERIALIZEDVIEW
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ù.
I dati vengono migrati al cluster di destinazione. Se il tipo di nodo di destinazione èRA3, le letture e le scritture sono disponibili durante la migrazione dei dati.
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.
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

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

Per monitorare un ridimensionamento classico di un cluster assegnato in corso, inclusa la KEY distribuzione, 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 di ridimensionamento classiche quando il cluster di destinazione non lo è RA3

Il ridimensionamento classico consiste in quanto segue, quando il tipo di nodo di destinazione è diverso daRA3, ad esempioDC2,.

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 CREATEMATERIALIZEDVIEW.
Dopo il riavvio, il database è disponibile in sola lettura. Riprende la condivisione dei dati, il che richiede qualche minuto in più.
I dati vengono migrati al cluster di destinazione. Il database rimane in sola lettura.
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.
Il ridimensionamento viene completato. Amazon Redshift invia una notifica dell'evento.

Nota

Il ridimensionamento di un cluster con una grande quantità di dati può richiedere giorni o forse settimane quando il cluster di destinazione non RA3 lo è oppure non soddisfa i prerequisiti per un cluster di RA3 destinazione 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.

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. Per il ridimensionamento classico di un RA3 cluster, non puoi annullare.

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 le nostre API operazioni AWS CLI di Amazon Redshift per pianificare un ridimensionamento. Per ulteriori informazioni, consulta create-scheduled-action AWS CLICommand Reference o CreateScheduledActionAmazon 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:

Acquisire una snapshot del cluster esistente. Il cluster esistente è il cluster di origine.
Prendere nota dell'ora in cui è stato acquisito lo snapshot. In questo modo è possibile identificare in un secondo momento il momento in cui è necessario eseguire nuovamente i processi extract, transact, load (ETL) per caricare i dati post-snapshot nel database di destinazione.
Ripristinare lo snapshot in un nuovo cluster. Questo nuovo cluster è il cluster target. Verificare la presenza dei dati di esempio nel cluster target.
Ridimensionare il cluster target. Scegliere il nuovo tipo di nodo, il numero di nodi e altre impostazioni per il cluster di destinazione.
Esamina i caricamenti dei ETL processi avvenuti dopo aver scattato un'istantanea 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.
Interrompere tutte le query in esecuzione nel cluster di origine. A tale scopo, è possibile riavviare il cluster oppure accedere come superutente e utilizzare i comandi PG_ _ e PG_ CANCEL _ BACKEND. TERMINATE BACKEND Il riavvio del cluster è il modo più semplice di assicurarsi che il cluster non è disponibile.
Rinominare il cluster di origine. Ad esempio, cambiare il nome da examplecluster a examplecluster-source.
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.
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 (AmazonSNS) 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.

Avvertimento JavaScript è disabilitato o non è disponibile nel tuo browser.

Per usare la documentazione AWS, JavaScript deve essere abilitato. Consulta le pagine della guida del browser per le istruzioni.

Convenzioni dei documenti

Modifica di un cluster

Ridenominazione di un cluster