Clonazione di un volume per un cluster di database Amazon Aurora - Amazon Aurora
Panoramica sulla clonazione AuroraLimitazioni della clonazione AuroraCome funziona la clonazione AuroraCreazione di un clone AuroraClonazione tra VPCClonazione tra più account

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à.

Clonazione di un volume per un cluster di database Amazon Aurora

La clonazione di Aurora ti consente di creare un nuovo cluster che abbia inizialmente le stesse pagine di dati dell'originale, ma sia un volume separato e indipendente. Il processo è progettato per essere veloce e conveniente. Il nuovo cluster con il relativo volume di dati associato è noto come clone. La creazione di un clone è più veloce ed efficiente in termini di spazio rispetto alla copia fisica dei dati utilizzando una tecnica diversa, ad esempio con il ripristino di uno snapshot.

Panoramica sulla clonazione Aurora

Aurora utilizza un copy-on-write protocollo per creare un clone. Questo meccanismo utilizza uno spazio aggiuntivo minimo per creare un clone iniziale. Quando il clone viene creato per la prima volta, Aurora conserva una singola copia dei dati utilizzati dal cluster database Aurora di origine e dal nuovo cluster database Aurora (clonato). L'archiviazione aggiuntiva viene allocata solo quando vengono apportate modifiche ai dati (sul volume di archiviazione Aurora) dal cluster database Aurora di origine o dal clone del cluster database Aurora. Per ulteriori informazioni sul copy-on-write protocollo, consulta. Come funziona la clonazione Aurora

La clonazione Aurora è particolarmente utile per configurare rapidamente ambienti di test utilizzando i dati di produzione, senza rischiare il danneggiamento dei dati. È possibile utilizzare i cloni per molti tipi di applicazioni di breve durata, ad esempio:

  • Sperimenta potenziali cambiamenti (modifiche allo schema e modifiche ai gruppi di parametri, ad esempio) per valutare tutti gli impatti.

  • Esegui operazioni che utilizzano in modo intensivo i carichi di lavoro, come l'esportazione di dati o l'esecuzione di query analitiche sul clone.

  • Creare una copia del cluster database di produzione per lo sviluppo, il test o altri scopi.

È possibile creare più di un clone dallo stesso cluster database Aurora. È anche possibile creare più cloni da un altro clone.

Dopo aver creato un clone Aurora, è possibile configurare le istanze database Aurora in modo diverso dal cluster database Aurora di origine. Ad esempio, potrebbe non essere necessario un clone per scopi di sviluppo per soddisfare gli stessi requisiti di alta disponibilità del cluster database Aurora di produzione di origine. In questo caso, è possibile configurare il clone con una singola istanza database Aurora anziché con più istanze database utilizzate dal cluster database Aurora.

Quando si crea un clone utilizzando una configurazione di distribuzione diversa da quella di origine, il clone viene creato utilizzando l'ultima versione secondaria del motore Aurora DB della sorgente.

Quando crei cloni dai tuoi cluster Aurora DB, i cloni vengono creati nel AWS tuo account, lo stesso account che possiede il cluster Aurora DB di origine. Tuttavia, puoi anche condividere Aurora Serverless v2 e fornire cluster e cloni Aurora DB con altri account. AWS Per ulteriori informazioni, consulta Clonazione tra account con AWS RAM e Amazon Aurora.

Una volta terminato di utilizzare il clone per test, sviluppo o altri scopi, è possibile eliminarlo.

Limitazioni della clonazione Aurora

La clonazione Aurora presenta le seguenti limitazioni:

  • Puoi creare tutti i cloni che desideri, fino al numero massimo di cluster database consentito nella Regione AWS.

    È possibile creare i cloni utilizzando il protocollo o il copy-on-write protocollo di copia completa. Il protocollo di copia completa funziona come un ripristino. point-in-time

  • Non è possibile creare un clone in una AWS regione diversa dal cluster Aurora DB di origine.

  • Non è possibile creare un clone da un cluster database Aurora senza la funzionalità di query parallela a un cluster che utilizza query parallela. Per inserire dati in un cluster che usa la query parallela, crea uno snapshot del cluster originale ed eseguine il ripristino nel cluster in cui è abilitata l'opzione per la query parallela.

  • Non è possibile creare un clone da un cluster database Aurora che non ha istanze database. È possibile clonare solo cluster database Aurora con almeno un'istanza database.

  • È possibile creare un clone in un cloud privato virtuale (VPC) diverso da quello del cluster database Aurora. Tuttavia, le sottoreti in quei VPC devono essere associate alle stesse zone di disponibilità.

  • È possibile creare un clone con provisioning Aurora da un cluster database Aurora con provisioning.

  • I cluster con le istanze Aurora Serverless v2 seguono le stesse regole dei cluster con provisioning.

  • Per Aurora Serverless v1:

    • È possibile creare un clone predisposto da un cluster DB. Aurora Serverless v1

    • È possibile creare un Aurora Serverless v1 clone da un cluster DB Aurora Serverless v1 o fornito.

    • Non è possibile creare un Aurora Serverless v1 clone da un cluster Aurora DB non crittografato e fornito.

    • La clonazione tra più account al momento non supporta la clonazione di cluster database Aurora Serverless v1. Per ulteriori informazioni, consulta Restrizioni della clonazione tra più account.

    • Un cluster database Aurora Serverless v1 clonato ha lo stesso comportamento e le stesse limitazioni di qualsiasi altro cluster database Aurora Serverless v1. Per ulteriori informazioni, consulta Utilizzo di Amazon Aurora Serverless v1.

    • I cluster database Aurora Serverless v1 sono sempre crittografati. Quando si clona un cluster database Aurora Serverless v1 in un cluster database Aurora con provisioning, il cluster database Aurora con provisioning è crittografato. Puoi scegliere la chiave di crittografia, ma non è possibile disabilitare la crittografia. Per clonare da un cluster Aurora DB con provisioning a un cluster Aurora DBAurora Serverless v1, è necessario iniziare con un cluster Aurora DB con provisioning crittografato.

Come funziona la clonazione Aurora

La clonazione Aurora funziona a livello di archiviazione di un cluster database Aurora. Utilizza un protocollo copy-on-write, veloce ed efficiente in termini di spazio per il supporto durevole sottostante che supporta il volume di archiviazione Aurora. Per ulteriori informazioni, consulta la sezione relativa ai volumi cluster Aurora in Panoramica dell'archiviazione di Amazon Aurora.

Comprensione del protocollo copy-on-write

Un cluster database Aurora memorizza i dati nelle pagine del volume di archiviazione Aurora sottostante.

Ad esempio, nel diagramma seguente puoi vedere un cluster database Aurora (A) con quattro pagine dati, 1, 2, 3 e 4. Immagina che un clone, B, venga creato dal cluster database Aurora. Quando viene creato il clone, non viene copiato alcun dato. Piuttosto, il clone punta allo stesso insieme di pagine del cluster database Aurora di origine.

Volume del cluster Amazon Aurora con 4 pagine per il cluster di origine, A, e il clone, B

Quando viene creato il clone, in genere non è necessario alcuno spazio di archiviazione aggiuntivo. Il copy-on-write protocollo utilizza lo stesso segmento sul supporto di archiviazione fisico del segmento di origine. Lo spazio di archiviazione aggiuntivo è necessario solo se la capacità del segmento di origine non è sufficiente per l'intero segmento di clone. In questo caso, il segmento di origine viene copiato su un altro dispositivo fisico.

Nei diagrammi seguenti, è possibile trovare un esempio del copy-on-write protocollo in azione che utilizza lo stesso cluster A e il suo clone, B, come mostrato in precedenza. Supponiamo che si apporti una modifica al cluster database Aurora (A) che si traduce in una modifica ai dati contenuti a pagina 1. Invece di scrivere sulla pagina originale 1, Aurora crea una nuova pagina 1[A]. Il volume del cluster database Aurora per cluster (A) punta ora alla pagina 1[A], 2, 3 e 4, mentre il clone (B) fa ancora riferimento alle pagine originali.

Volume del cluster database di origine Amazon Aurora e il suo clone, entrambi con modifiche.

Sul clone, viene apportata una modifica a pagina 4 sul volume di archiviazione. Invece di scrivere sulla pagina originale 4, Aurora crea una nuova pagina 4[B]. Il clone punta ora alle pagine 1, 2, 3 e alla pagina 4[B], mentre il cluster (A) continua a puntare a 1[A], 2, 3 e 4.

Volume del cluster database di origine Amazon Aurora e il suo clone, entrambi con modifiche.

Quando nel corso del tempo si verificano altre modifiche sia nel volume del cluster database Aurora di origine che nel clone, avrai bisogno di più spazio di archiviazione per acquisire e archiviare tali modifiche.

Eliminazione di un volume cluster di origine

Inizialmente, il volume clone condivide le stesse pagine di dati del volume originale da cui viene creato il clone. Finché esiste il volume originale, il volume clone viene considerato solo il proprietario delle pagine che il clone ha creato o modificato. Pertanto, la VolumeBytesUsed metrica per il volume clone all'inizio è piccola e cresce solo quando i dati divergono tra il cluster originale e il clone. Per le pagine identiche tra il volume di origine e il clone, i costi di archiviazione si applicano solo al cluster originale. Per ulteriori informazioni sul parametro VolumeBytesUsed, consulta Parametri a livello di cluster per Amazon Aurora.

Quando si elimina un volume del cluster di origine a cui sono associati uno o più cloni, i dati nei volumi del cluster dei cloni non vengono modificati. Aurora conserva le pagine che in precedenza erano di proprietà del volume del cluster di origine. Aurora ridistribuisce la fatturazione dello spazio di archiviazione per le pagine di proprietà del cluster eliminato. Ad esempio, supponiamo che un cluster originale avesse due cloni e che quindi il cluster originale sia stato eliminato. La metà delle pagine di dati di proprietà del cluster originale ora sarebbe di proprietà di un clone. L'altra metà delle pagine sarebbe di proprietà dell'altro clone.

Se elimini il cluster originale, man mano che crei o elimini altri cloni, Aurora continua a ridistribuire la proprietà delle pagine di dati tra tutti i cloni che condividono le stesse pagine. Pertanto, è possibile che il valore della VolumeBytesUsed metrica cambi per il volume del cluster di un clone. Il valore della metrica può diminuire man mano che vengono creati più cloni e la proprietà della pagina viene distribuita su più cluster. Il valore della metrica può inoltre aumentare man mano che i cloni vengono eliminati e la proprietà della pagina viene assegnata a un numero inferiore di cluster. Per informazioni su come le operazioni di scrittura influiscono sulle pagine di dati sui volumi clonati, consulta. Comprensione del protocollo copy-on-write

Quando il cluster originale e i cloni sono di proprietà dello stesso AWS account, tutti i costi di archiviazione per tali cluster si applicano allo stesso account. AWS Se alcuni cluster sono cloni con più account, l'eliminazione del cluster originale può comportare costi di archiviazione aggiuntivi per gli account che possiedono i cloni su più AWS account.

Ad esempio, supponiamo che un volume del cluster contenga 1000 pagine di dati utilizzate prima di creare qualsiasi clone. Quando clonate quel cluster, inizialmente il volume clone ha zero pagine utilizzate. Se il clone apporta modifiche a 100 pagine di dati, solo quelle 100 pagine vengono memorizzate nel volume clone e contrassegnate come utilizzate. Le altre 900 pagine invariate del volume principale sono condivise da entrambi i cluster. In questo caso, il cluster principale prevede costi di archiviazione per 1000 pagine e il volume clone per 100 pagine.

Se si elimina il volume di origine, i costi di archiviazione per il clone includono le 100 pagine modificate, più le 900 pagine condivise del volume originale, per un totale di 1000 pagine.

Creazione di un clone Amazon Aurora

È possibile creare un clone nello stesso AWS account del cluster Aurora DB di origine. A tale scopo, è possibile utilizzare AWS Management Console o AWS CLI le procedure seguenti.

Per consentire a un altro AWS account di creare un clone o di condividere un clone con un altro AWS account, utilizzare le procedure riportate in. Clonazione tra account con AWS RAM e Amazon Aurora

La procedura seguente descrive come clonare un cluster database Aurora utilizzando la AWS Management Console.

Creazione di un clone utilizzando i AWS Management Console risultati in un cluster Aurora DB con un'istanza Aurora DB.

Queste istruzioni si applicano ai cluster DB di proprietà dello stesso AWS account che sta creando il clone. Se il cluster DB è di proprietà di un AWS account diverso, vedi Clonazione tra account con AWS RAM e Amazon Aurora invece.

Per creare un clone di un cluster DB di proprietà del tuo AWS account utilizzando il AWS Management Console

  1. Accedi AWS Management Console e apri la console Amazon RDS all'indirizzo https://console.aws.amazon.com/rds/.

  2. Nel riquadro di navigazione, scegliere Databases (Database).

  3. Seleziona il cluster database Aurora dall'elenco, quindi in Operazioni, seleziona Crea clone.

    La creazione di un clone inizia selezionando il cluster database Aurora.

    Verrà visualizzata la pagina Crea clone, dove è possibile configurare le opzioni Impostazioni, Connettività e altre opzioni per il clone del cluster database Aurora.

  4. Per Identificatore istanza database, immettere il nome che si desidera assegnare al cluster database Aurora clonato.

  5. Per i cluster Aurora Serverless v1 DB, scegli Provisioned o Serverless for Capacity.

    È possibile scegliere Serverless solo se il cluster database Aurora di origine è un cluster database Aurora Serverless v1 o è un cluster database Aurora con provisioning crittografato.

  6. Per i cluster DB Aurora Serverless v2 o per i quali è stato effettuato il provisioning, scegli uno dei due Aurora I/O-Optimizedo Aurora Standardper la configurazione Cluster Storage.

    Per ulteriori informazioni, consulta Configurazioni dell'archiviazione per i cluster database Amazon Aurora.

  7. Scegliere la dimensione dell'istanza database o la capacità del cluster database:

    • Per un clone predisposto, scegli una classe di istanza DB.

      Per creare un clone di cui è stato effettuato il provisioning, specificate la dimensione dell'istanza DB.

      È possibile accettare l'impostazione predefinita oppure utilizzare una classe di istanza database diversa per il clone.

    • Per un Aurora Serverless v2 clone Aurora Serverless v1 or, scegliete le impostazioni di capacità.

      Per creare un clone Serverless da un cluster database Aurora, specificare la capacità.

      Puoi accettare le impostazioni fornite oppure modificarle per il tuo clone.

  8. Scegliete le altre impostazioni necessarie per il clone. Per ulteriori informazioni sulle impostazioni di cluster e istanza database Aurora, consulta Creazione di un cluster database Amazon Aurora.

  9. Scegli Crea clone.

Quando viene creato il clone, viene elencato con gli altri cluster database Aurora nella sezione Database e se ne visualizza lo stato corrente. Il clone è pronto per l'utilizzo quando lo stato diventa Disponibile.

L'utilizzo AWS CLI per la clonazione del cluster Aurora DB richiede un paio di passaggi.

Il restore-db-cluster-to-point-in-time AWS CLI comando utilizzato genera un cluster Aurora DB vuoto con 0 istanze Aurora DB. In altre parole, il comando ripristina solo il cluster database Aurora, non le istanze database per tale cluster. Sarà possibile farlo separatamente una volta che il clone è disponibile. Le due fasi del processo sono descritte di seguito:

  1. Creare il clone utilizzando il comando restore-db-cluster-to-point-in-time della CLI. I parametri utilizzati con questo comando controllano il tipo di capacità e altri dettagli del cluster database Aurora vuoto (clone) in fase di creazione.

  2. Creare l'istanza database Aurora per il clone utilizzando il comando create-db-instance della CLI per ricreare l'istanza database Aurora nel cluster database Aurora ripristinato.

Creazione del clone

I parametri specifici che vengono inviati al comando della CLI restore-db-cluster-to-point-in-time variano. Ciò che si invia dipende dal tipo di modalità motore del cluster database di origine: Serverless o con provisioning, e dal tipo di clone che si desidera creare.

Come creare un clone della stessa modalità motore del cluster database Aurora di origine

  • Utilizzare il comando restore-db-cluster-to-point-in-time della CLI e specificare i valori per i seguenti parametri:

    • --db-cluster-identifier: scegliere un nome significativo per il clone. Il nome del clone viene assegnato utilizzando il comando restore-db-cluster-to-point-in-time della CLI. Il nome del clone viene quindi inviato nel comando create-db-instance della CLI.

    • --restore-type: utilizza copy-on-write per creare un clone del cluster database di origine. Senza questo parametro, il parametro restore-db-cluster-to-point-in-time ripristina il cluster database Aurora anziché creare un clone.

    • --source-db-cluster-identifier: utilizza il nome del cluster database Aurora di origine che si desidera clonare.

    • --use-latest-restorable-time— Questo valore indica i dati di volume ripristinabili più recenti per il cluster DB di origine. Utilizzatelo per creare cloni.

Nell'esempio seguente viene creato un clone denominato my-clone da un cluster denominato my-source-cluster.

Per LinuxmacOS, oUnix:

aws rds restore-db-cluster-to-point-in-time \
    --source-db-cluster-identifier my-source-cluster \
    --db-cluster-identifier my-clone \
    --restore-type copy-on-write \
    --use-latest-restorable-time

Per Windows:

aws rds restore-db-cluster-to-point-in-time ^
    --source-db-cluster-identifier my-source-cluster ^
    --db-cluster-identifier my-clone ^
    --restore-type copy-on-write ^
    --use-latest-restorable-time

Il comando restituisce l'oggetto JSON contenente i dettagli del clone. Prima di provare a creare l'istanza database per il clone, verificare che il cluster database clonato sia disponibile. Per ulteriori informazioni, consulta Controllo dello stato e ottenimento deii dettagli del clone.

Per creare un clone con una modalità motore diversa dal cluster Aurora DB di origine

  • Utilizzare il comando restore-db-cluster-to-point-in-time della CLI e specificare i valori per i seguenti parametri:

    • --db-cluster-identifier: scegliere un nome significativo per il clone. Il nome del clone viene assegnato utilizzando il comando restore-db-cluster-to-point-in-time della CLI. Il nome del clone viene quindi inviato nel comando create-db-instance della CLI.

    • --source-db-cluster-identifier: utilizza il nome del cluster database Aurora di origine che si desidera clonare.

    • --restore-type: utilizza copy-on-write per creare un clone del cluster database di origine. Senza questo parametro, il parametro restore-db-cluster-to-point-in-time ripristina il cluster database Aurora anziché creare un clone.

    • --use-latest-restorable-time— Questo valore indica i dati di volume ripristinabili più recenti per il cluster DB di origine. Utilizzatelo per creare cloni.

    • --engine-mode— (Facoltativo) Utilizzate questo parametro solo per creare cloni di tipo diverso dal cluster Aurora DB di origine. Scegli il valore da inviare con --engine-mode come riportato di seguito:

      • Utilizzare provisioned per creare un clone del cluster database Aurora da un cluster database Aurora Serverless.

      • Utilizza serverless per creare un clone del cluster database Aurora Serverless v1 da un cluster database Aurora con provisioning. Quando si specifica la modalità serverless del motore, è anche possibile scegliere. --scaling-configuration

    • --scaling-configuration— (Facoltativo) Utilizzare with --engine-mode serverless per configurare la capacità minima e massima per un Aurora Serverless v1 clone. Se non si utilizza questo parametro, Aurora crea il clone utilizzando i valori di capacità predefiniti per il motore DB.

    • --serverless-v2-scaling-configuration— (Facoltativo) Utilizzate questo parametro per configurare la capacità minima e massima per un Aurora Serverless v2 clone. Se non si utilizza questo parametro, Aurora crea il clone utilizzando i valori di capacità predefiniti per il motore DB.

L'esempio seguente crea un Aurora Serverless v1 clone denominatomy-clone, da un cluster Aurora DB di cui è stato effettuato il provisioning denominato. my-source-cluster Il cluster database Aurora sottoposto a provisioning è crittografato.

PerLinux, o: macOS Unix

aws rds restore-db-cluster-to-point-in-time \
    --source-db-cluster-identifier my-source-cluster \
    --db-cluster-identifier my-clone \
    --engine-mode serverless \
    --scaling-configuration MinCapacity=8,MaxCapacity=64 \
    --restore-type copy-on-write \
    --use-latest-restorable-time

Per Windows:

aws rds restore-db-cluster-to-point-in-time ^
    --source-db-cluster-identifier my-source-cluster ^
    --db-cluster-identifier my-clone ^
    --engine-mode serverless ^
    --scaling-configuration MinCapacity=8,MaxCapacity=64 ^
    --restore-type copy-on-write ^
    --use-latest-restorable-time

Questi comandi restituiscono l'oggetto JSON contenente i dettagli del clone necessari per creare l'istanza database. Non puoi farlo finché lo stato del clone (il cluster database Aurora vuoto) non diventa Disponibile.

Nota

Il comando restore-db-cluster-to-point-in-time della CLI AWS ripristina solo il cluster DB e non le istanze database per quel cluster. Devi utilizzare il comando create-db-instance per creare le istanze database per il cluster di database ripristinato, specificando l'identificatore del cluster di database ripristinato in --db-cluster-identifier. Puoi creare le istanze database solo dopo che il comando restore-db-cluster-to-point-in-time è terminato e il cluster database è disponibile.

Si supponga, ad esempio, di disporre di un cluster denominato tpch100g che si desidera clonare. Nell'esempio seguente viene creato un cluster clonato denominato tpch100g-clone e un'istanza primaria denominata tpch100g-clone-instance per il nuovo cluster. Non è necessario fornire alcun parametro, come --master-username e --master-user-password. Aurora determina automaticamente quelli dal cluster originale. È necessario specificare il motore database da utilizzare. Pertanto, l'esempio verifica il nuovo cluster per determinare il valore corretto da utilizzare per il parametro --engine.

$ aws rds restore-db-cluster-to-point-in-time \
  --source-db-cluster-identifier tpch100g \
  --db-cluster-identifier tpch100g-clone \
  --restore-type copy-on-write \
  --use-latest-restorable-time

$ aws rds describe-db-clusters \
  --db-cluster-identifier tpch100g-clone \
    --query '*[].[Engine]' \
    --output text
aurora-mysql

$ aws rds create-db-instance \
  --db-instance-identifier tpch100g-clone-instance \
  --db-cluster-identifier tpch100g-clone \
  --db-instance-class db.r5.4xlarge \
  --engine aurora-mysql

Controllo dello stato e ottenimento deii dettagli del clone

È possibile utilizzare il seguente comando per controllare lo stato del cluster database vuoto appena creato.

$ aws rds describe-db-clusters --db-cluster-identifier my-clone --query '*[].[Status]' --output text

Oppure puoi ottenere lo stato e gli altri valori necessari per creare l'istanza DB per il tuo clone utilizzando la seguente AWS CLI query.

Per LinuxmacOS, oUnix:

aws rds describe-db-clusters --db-cluster-identifier my-clone \
  --query '*[].{Status:Status,Engine:Engine,EngineVersion:EngineVersion,EngineMode:EngineMode}'

Per Windows:

aws rds describe-db-clusters --db-cluster-identifier my-clone ^
  --query "*[].{Status:Status,Engine:Engine,EngineVersion:EngineVersion,EngineMode:EngineMode}"

Questa query restituisce un output simile al seguente:

[
  {
        "Status": "available",
        "Engine": "aurora-mysql",
        "EngineVersion": "8.0.mysql_aurora.3.04.1",
        "EngineMode": "provisioned"
    }
]

Creazione dell'istanza database Aurora per il clone

Usa il comando CLI create-db-instance per creare l'istanza DB per il tuo clone o per il tuo clone fornito. Aurora Serverless v2 Non si crea un'istanza DB per un clone. Aurora Serverless v1

L'istanza DB eredita le --master-user-password proprietà --master-username and dal cluster DB di origine.

L'esempio seguente crea un'istanza DB per un clone di cui è stato eseguito il provisioning.

PerLinux, omacOS: Unix

aws rds create-db-instance \
    --db-instance-identifier my-new-db \
    --db-cluster-identifier my-clone \
    --db-instance-class db.r5.4xlarge \
    --engine aurora-mysql

Per Windows:

aws rds create-db-instance ^
    --db-instance-identifier my-new-db ^
    --db-cluster-identifier my-clone ^
    --db-instance-class db.r5.4xlarge ^
    --engine aurora-mysql

Parametri da utilizzare per la clonazione

La tabella seguente riepiloga i vari parametri utilizzati con restore-db-cluster-to-point-in-time per clonare i cluster database Aurora.

Parametro Descrizione

--source-db-cluster-identifier

Utilizza il nome del cluster database Aurora di origine che si desidera clonare.

--db-cluster-identifier

Scegli un nome significativo per il tuo clone quando lo crei con il restore-db-cluster-to-point-in-time comando. Quindi questo nome viene inviato al comando create-db-instance.

--restore-type

Specifica copy-on-write come --restore-type per creare un clone del cluster database di origine anziché ripristinare il cluster database Aurora di origine.
--use-latest-restorable-time

Questo valore indica i dati di volume ripristinabili più recenti per il cluster DB di origine. Usalo per creare cloni.

--engine-mode

Utilizzate questo parametro per creare cloni di tipo diverso dal cluster Aurora DB di origine, con uno dei seguenti valori:

  • Utilizzato provisioned per creare un provisioning o un Aurora Serverless v2 clone da un cluster DB. Aurora Serverless v1

  • serverlessDa utilizzare per creare un Aurora Serverless v1 clone da un cluster di database o di cui è stato eseguito il provisioning. Aurora Serverless v2

    Quando si specifica la modalità serverless del motore, è anche possibile scegliere. --scaling-configuration

--scaling-configuration

Utilizzate questo parametro per configurare la capacità minima e massima per un Aurora Serverless v1 clone. Se non specificate questo parametro, Aurora crea il clone utilizzando i valori di capacità predefiniti per il motore DB.
--serverless-v2-scaling-configuration

Utilizzate questo parametro per configurare la capacità minima e massima per un Aurora Serverless v2 clone. Se non specificate questo parametro, Aurora crea il clone utilizzando i valori di capacità predefiniti per il motore DB.

Clonazione tra VPC con Amazon Aurora

Supponiamo di voler imporre diversi controlli di accesso alla rete sul cluster originale e sul clone. Ad esempio, è possibile utilizzare la clonazione per creare una copia di un cluster Aurora di produzione in un VPC diverso per lo sviluppo e il test. Oppure potresti creare un clone come parte di una migrazione da sottoreti pubbliche a sottoreti private, per migliorare la sicurezza del database.

Le sezioni seguenti mostrano come configurare la configurazione di rete per il clone in modo che il cluster originale e il clone possano entrambi accedere agli stessi nodi di storage Aurora, anche da sottoreti diverse o VPC diversi. La verifica preventiva delle risorse di rete può evitare errori durante la clonazione che potrebbero essere difficili da diagnosticare.

Se non conosci il modo in cui Aurora interagisce con VPC, sottoreti e gruppi di sottoreti DB, consulta prima. VPC di Amazon VPC e Amazon Aurora Puoi seguire i tutorial in quella sezione per creare questo tipo di risorse nella AWS console e capire come si integrano tra loro.

Poiché i passaggi prevedono il passaggio tra i servizi RDS ed EC2, gli esempi utilizzano i comandi AWS CLI per aiutarti a capire come automatizzare tali operazioni e salvare l'output.

Prima di iniziare

Prima di iniziare a configurare un clone cross-VPC, assicurati di disporre delle seguenti risorse:

Raccolta di informazioni sull'ambiente di rete

Con la clonazione cross-VPC, l'ambiente di rete può differire sostanzialmente tra il cluster originale e il relativo clone. Prima di creare il clone, raccogli e registra informazioni sul VPC, sulle sottoreti, sul gruppo di sottoreti DB e sulle AZ utilizzate nel cluster originale. In questo modo, puoi ridurre al minimo le possibilità di problemi. Se si verifica un problema di rete, non sarà necessario interrompere alcuna attività di risoluzione dei problemi per cercare informazioni diagnostiche. Le sezioni seguenti mostrano esempi CLI per raccogliere questi tipi di informazioni. È possibile salvare i dettagli nel formato più comodo da consultare durante la creazione del clone e la risoluzione dei problemi.

Fase 1: Verificare le zone di disponibilità del cluster originale

Prima di creare il clone, verifica quali AZ utilizza il cluster originale per lo storage. Come spiegato inStorage e affidabilità di Amazon Aurora, lo storage per ogni cluster Aurora è associato esattamente a tre AZ. Poiché Cluster database Amazon Aurora sfrutta la separazione tra elaborazione e archiviazione, questa regola è valida indipendentemente dal numero di istanze presenti nel cluster.

Ad esempio, esegui un comando CLI come il seguente, sostituendo il tuo nome di cluster con. my_cluster L'esempio seguente produce un elenco ordinato alfabeticamente in base al nome AZ. 

aws rds describe-db-clusters \
  --db-cluster-identifier my_cluster \
  --query 'sort_by(*[].AvailabilityZones[].{Zone:@},&Zone)' \
  --output text

L'esempio seguente mostra un esempio di output del comando precedente. describe-db-clusters Dimostra che lo storage per il cluster Aurora utilizza sempre tre AZ. 

us-east-1c
us-east-1d
us-east-1e

Per creare un clone in un ambiente di rete che non dispone di tutte le risorse necessarie per connettersi a queste AZ, è necessario creare sottoreti associate ad almeno due di tali AZ e quindi creare un gruppo di sottoreti DB contenente queste due o tre sottoreti. Gli esempi seguenti mostrano come.

Fase 2: Controllare il gruppo di sottoreti DB del cluster originale

Se si desidera utilizzare per il clone lo stesso numero di sottoreti del cluster originale, è possibile ottenere il numero di sottoreti dal gruppo di sottoreti DB del cluster originale. Un gruppo di sottoreti Aurora DB contiene almeno due sottoreti, ciascuna associata a una AZ diversa. Prendi nota delle AZ a cui sono associate le sottoreti.

L'esempio seguente mostra come trovare il gruppo di sottoreti DB del cluster originale e quindi tornare alle AZ corrispondenti. Sostituisci il nome del cluster con quello my_cluster nel primo comando. Sostituisci il nome del gruppo di sottoreti DB con il secondo my_subnet comando. 

aws rds describe-db-clusters --db-cluster-identifier my_cluster \
  --query '*[].DBSubnetGroup' --output text

aws rds describe-db-subnet-groups --db-subnet-group-name my_subnet_group \
  --query '*[].Subnets[].[SubnetAvailabilityZone.Name]' --output text

L'output di esempio potrebbe essere simile al seguente, per un cluster con un gruppo di sottoreti DB contenente due sottoreti. In questo caso, two-subnets è un nome specificato durante la creazione del gruppo di sottoreti DB. 

two-subnets

us-east-1d
us-east-1c

Per un cluster in cui il gruppo di sottoreti DB contiene tre sottoreti, l'output potrebbe essere simile al seguente. 

three-subnets

us-east-1f
us-east-1d
us-east-1c

Fase 3: Controllare le sottoreti del cluster originale

Se hai bisogno di maggiori dettagli sulle sottoreti nel cluster originale, esegui comandi AWS CLI simili ai seguenti. È possibile esaminare gli attributi della sottorete come gli intervalli di indirizzi IP, il proprietario e così via. In questo modo, puoi determinare se utilizzare sottoreti diverse nello stesso VPC o creare sottoreti con caratteristiche simili in un VPC diverso.

Trova gli ID di sottorete di tutte le sottoreti disponibili nel tuo VPC. 

aws ec2 describe-subnets --filters Name=vpc-id,Values=my_vpc \
  --query '*[].[SubnetId]' --output text

Trova le sottoreti esatte utilizzate nel tuo gruppo di sottoreti DB. 

aws rds describe-db-subnet-groups --db-subnet-group-name my_subnet_group \
  --query '*[].Subnets[].[SubnetIdentifier]' --output text

Quindi specifica le sottoreti che desideri esaminare in un elenco, come nel comando seguente. Sostituisci i nomi delle tue sottoreti e così via. my_subnet_1 

aws ec2 describe-subnets \
  --subnet-ids '["my_subnet_1","my_subnet2","my_subnet3"]'

L'esempio seguente mostra l'output parziale di tale comando. describe-subnets L'output mostra alcuni degli attributi importanti che puoi vedere per ogni sottorete, come l'AZ associata e il VPC di cui fa parte. 

{
    'Subnets': [
        {
            'AvailabilityZone': 'us-east-1d',
            'AvailableIpAddressCount': 54,
            'CidrBlock': '10.0.0.64/26',
            'State': 'available',
            'SubnetId': 'subnet-000a0bca00e0b0000',
            'VpcId': 'vpc-3f3c3fc3333b3ffb3',
            ...
        },
        {
            'AvailabilityZone': 'us-east-1c',
            'AvailableIpAddressCount': 55,
            'CidrBlock': '10.0.0.0/26',
            'State': 'available',
            'SubnetId': 'subnet-4b4dbfe4d4a4fd4c4',
            'VpcId': 'vpc-3f3c3fc3333b3ffb3',
            ...

Fase 4: Verificare le zone di disponibilità delle istanze DB nel cluster originale

È possibile utilizzare questa procedura per comprendere le AZ utilizzate per le istanze DB nel cluster originale. In questo modo, puoi configurare esattamente le stesse AZ per le istanze DB nel clone. È inoltre possibile utilizzare più o meno istanze DB nel clone a seconda che il clone venga utilizzato per la produzione, lo sviluppo e il test e così via.

Per ogni istanza del cluster originale, esegui un comando come il seguente. Assicurati che l'istanza abbia terminato la creazione e che si trovi prima nello Available stato in cui si trova. Sostituite l'identificatore di istanza con. my_instance 

aws rds describe-db-instances --db-instance-identifier my_instance \
  --query '*[].AvailabilityZone' --output text

L'esempio seguente mostra l'output dell'esecuzione del comando precedentedescribe-db-instances. Il cluster Aurora dispone di quattro istanze di database. Pertanto, eseguiamo il comando quattro volte, sostituendo ogni volta un identificatore di istanza DB diverso. L'output mostra come tali istanze DB sono distribuite su un massimo di tre AZ. 

us-east-1a
us-east-1c
us-east-1d
us-east-1a

Dopo aver creato il clone e avervi aggiunto istanze DB, potete specificare gli stessi nomi AZ nei comandi. create-db-instance È possibile farlo per configurare le istanze DB nel nuovo cluster configurato esattamente per le stesse AZ del cluster originale.

Passaggio 5: Controlla i VPC che puoi usare per il clone

Se intendi creare il clone in un VPC diverso dall'originale, puoi ottenere un elenco degli ID VPC disponibili per il tuo account. È possibile eseguire questo passaggio anche se è necessario creare sottoreti aggiuntive nello stesso VPC del cluster originale. Quando si esegue il comando per creare una sottorete, si specifica l'ID VPC come parametro.

Per elencare tutti i VPC del tuo account, esegui il seguente comando CLI: 

aws ec2 describe-vpcs --query '*[].[VpcId]' --output text

L'esempio seguente mostra un esempio di output del comando precedentedescribe-vpcs. L'output dimostra che nell' AWS account corrente sono presenti quattro VPC che possono essere utilizzati come origine o destinazione per la clonazione tra VPC. 

vpc-fd111111
vpc-2222e2cd2a222f22e
vpc-33333333a33333d33
vpc-4ae4d4de4a4444dad

Puoi utilizzare lo stesso VPC come destinazione per il clone o un VPC diverso. Se il cluster originale e il clone si trovano nello stesso VPC, puoi riutilizzare lo stesso gruppo di sottoreti DB per il clone. È inoltre possibile creare un gruppo di sottoreti DB diverso. Ad esempio, il nuovo gruppo di sottoreti DB potrebbe utilizzare sottoreti private, mentre il gruppo di sottoreti DB del cluster originale potrebbe utilizzare sottoreti pubbliche. Se crei il clone in un VPC diverso, assicurati che ci siano abbastanza sottoreti nel nuovo VPC e che le sottoreti siano associate alle AZ corrette del cluster originale.

Creazione di risorse di rete per il clone

Se durante la raccolta delle informazioni di rete avete scoperto che per il clone sono necessarie risorse di rete aggiuntive, potete creare tali risorse prima di provare a configurare il clone. Ad esempio, potrebbe essere necessario creare più sottoreti, sottoreti associate a AZ specifici o un nuovo gruppo di sottoreti DB.

Fase 1: Creare le sottoreti per il clone

Se devi creare nuove sottoreti per il clone, esegui un comando simile al seguente. Potrebbe essere necessario eseguire questa operazione quando si crea il clone in un altro VPC o quando si apportano altre modifiche alla rete, ad esempio utilizzando sottoreti private anziché sottoreti pubbliche.

AWS genera automaticamente l'ID della sottorete. Sostituisci il nome del VPC del clone con. my_vpc Scegli l'intervallo di indirizzi per --cidr-block consentire almeno 16 indirizzi IP nell'intervallo. È possibile includere qualsiasi altra proprietà che si desidera specificare. Esegui il comando aws ec2 create-subnet help per visualizzare tutte le scelte. 

aws ec2 create-subnet --vpc-id my_vpc \
  --availability-zone AZ_name --cidr-block IP_range

L'esempio seguente mostra alcuni attributi importanti di una sottorete appena creata. 

{
    'Subnet': {
        'AvailabilityZone': 'us-east-1b',
        'AvailableIpAddressCount': 59,
        'CidrBlock': '10.0.0.64/26',
        'State': 'available',
        'SubnetId': 'subnet-44b4a44f4e44db444',
        'VpcId': 'vpc-555fc5df555e555dc',
        ...
        }
}

Fase 2: Creare il gruppo di sottoreti DB per il clone

Se stai creando il clone in un VPC diverso o in un diverso set di sottoreti all'interno dello stesso VPC, crei un nuovo gruppo di sottoreti DB e lo specifichi durante la creazione del clone.

Assicurati di conoscere tutti i seguenti dettagli. Puoi trovarli tutti nell'output degli esempi precedenti.

  1. VPC del cluster originale. Per istruzioni, consulta Fase 3: Controllare le sottoreti del cluster originale.

  2. VPC del clone, se lo stai creando in un VPC diverso. Per istruzioni, consulta Passaggio 5: Controlla i VPC che puoi usare per il clone.

  3. Tre AZ associate allo storage Aurora per il cluster originale. Per istruzioni, consulta Fase 1: Verificare le zone di disponibilità del cluster originale.

  4. Due o tre AZ associati al gruppo di sottoreti DB per il cluster originale. Per istruzioni, consulta Fase 2: Controllare il gruppo di sottoreti DB del cluster originale.

  5. Gli ID di sottorete e le AZ associate di tutte le sottoreti nel VPC che intendi utilizzare per il clone. Usa lo stesso describe-subnets comando utilizzatoFase 3: Controllare le sottoreti del cluster originale, sostituendo l'ID VPC del VPC di destinazione.

Verifica quante AZ sono associate allo storage del cluster originale e alle sottoreti nel VPC di destinazione. Per creare correttamente il clone, devono esserci due o tre AZ in comune. Se avete meno di due AZ in comune, tornate a. Fase 1: Creare le sottoreti per il clone Crea una, due o tre nuove sottoreti associate alle AZ associate allo storage del cluster originale.

Scegli le sottoreti nel VPC di destinazione associate agli stessi AZ dello storage Aurora nel cluster originale. Idealmente, scegli tre AZ. In questo modo avrai la massima flessibilità per distribuire le istanze DB del clone su più AZ per un'elevata disponibilità delle risorse di calcolo.

Esegui un comando simile al seguente per creare il nuovo gruppo di sottoreti DB. Sostituisci gli ID delle tue sottoreti nell'elenco. Se specificate gli ID delle sottoreti utilizzando variabili di ambiente, fate attenzione a citare l'elenco dei --subnet-ids parametri in modo da preservare le virgolette doppie intorno agli ID. 

aws rds create-db-subnet-group --db-subnet-group-name my_subnet_group \
  --subnet-ids '["my_subnet_1","my_subnet_2","my_subnet3"]' \
  --db-subnet-group-description 'DB subnet group with 3 subnets for clone'

L'esempio seguente mostra l'output parziale del comando. create-db-subnet-group 

{
    'DBSubnetGroup': {
        'DBSubnetGroupName': 'my_subnet_group',
        'DBSubnetGroupDescription': 'DB subnet group with 3 subnets for clone',
        'VpcId': 'vpc-555fc5df555e555dc',
        'SubnetGroupStatus': 'Complete',
        'Subnets': [
            {
                'SubnetIdentifier': 'my_subnet_1',
                'SubnetAvailabilityZone': {
                    'Name': 'us-east-1c'
                },
                'SubnetStatus': 'Active'
            },
            {
                'SubnetIdentifier': 'my_subnet_2',
                'SubnetAvailabilityZone': {
                    'Name': 'us-east-1d'
                },
                'SubnetStatus': 'Active'
            }
            ...
        ],
        'SupportedNetworkTypes': [
            'IPV4'
        ]
    }
}

A questo punto, non avete ancora creato il clone. Sono state create tutte le risorse VPC e subnet pertinenti in modo da poter specificare i parametri appropriati per i create-db-instance comandi restore-db-cluster-to-point-in-time and durante la creazione del clone.

Creazione di un clone di Aurora con nuove impostazioni di rete

Dopo esserti assicurato che sia disponibile la configurazione corretta di VPC, sottoreti, AZ e gruppi di sottoreti per l'utilizzo del nuovo cluster, puoi eseguire l'operazione di clonazione effettiva. I seguenti esempi CLI evidenziano le opzioni quali --db-subnet-group-name--availability-zone, e --vpc-security-group-ids che specificate nei comandi per configurare il clone e le relative istanze DB.

Fase 1: Specificare il gruppo di sottoreti DB per il clone

Quando crei il clone, puoi configurare tutte le impostazioni VPC, subnet e AZ corrette specificando un gruppo di sottoreti DB. Utilizzate i comandi degli esempi precedenti per verificare tutte le relazioni e le mappature che entrano nel gruppo di sottoreti DB.

Ad esempio, i comandi seguenti dimostrano la clonazione di un cluster originale in un clone. Nel primo esempio, il cluster di origine è associato a due sottoreti e il clone è associato a tre sottoreti. Il secondo esempio mostra il caso opposto, la clonazione da un cluster con tre sottoreti a un cluster con due sottoreti. 

aws rds restore-db-cluster-to-point-in-time \
  --source-db-cluster-identifier cluster-with-3-subnets \
  --db-cluster-identifier cluster-cloned-to-2-subnets \
  --restore-type copy-on-write --use-latest-restorable-time \
  --db-subnet-group-name two-subnets

Se intendi utilizzare istanze Aurora Serverless v2 nel clone, includi un'--serverless-v2-scaling-configurationopzione quando crei il clone, come mostrato. In questo modo è possibile utilizzare la db.serverless classe durante la creazione di istanze DB nel clone. È inoltre possibile modificare il clone in un secondo momento per aggiungere questo attributo di configurazione di scalabilità. I numeri di capacità in questo esempio consentono a ciascuna istanza Serverless v2 nel cluster di scalare tra 2 e 32 unità di capacità Aurora (ACU). Per informazioni sulla funzionalità Aurora Serverless v2 e su come scegliere l'intervallo di capacità, vedere. Uso di Aurora Serverless v2 

aws rds restore-db-cluster-to-point-in-time \
  --source-db-cluster-identifier cluster-with-2-subnets \
  --db-cluster-identifier cluster-cloned-to-3-subnets \
  --restore-type copy-on-write --use-latest-restorable-time \
  --db-subnet-group-name three-subnets \
  --serverless-v2-scaling-configuration 'MinCapacity=2,MaxCapacity=32'

Indipendentemente dal numero di sottoreti utilizzate dalle istanze DB, lo storage Aurora per il cluster di origine e il clone è associato a tre AZ. L'esempio seguente elenca le AZ associate sia al cluster originale che al clone, per entrambi i comandi degli esempi precedenti. restore-db-cluster-to-point-in-time 

aws rds describe-db-clusters --db-cluster-identifier cluster-with-3-subnets \
  --query 'sort_by(*[].AvailabilityZones[].{Zone:@},&Zone)' --output text

us-east-1c
us-east-1d
us-east-1f

aws rds describe-db-clusters --db-cluster-identifier cluster-cloned-to-2-subnets \
  --query 'sort_by(*[].AvailabilityZones[].{Zone:@},&Zone)' --output text

us-east-1c
us-east-1d
us-east-1f

aws rds describe-db-clusters --db-cluster-identifier cluster-with-2-subnets \
  --query 'sort_by(*[].AvailabilityZones[].{Zone:@},&Zone)' --output text

us-east-1a
us-east-1c
us-east-1d

aws rds describe-db-clusters --db-cluster-identifier cluster-cloned-to-3-subnets \
  --query 'sort_by(*[].AvailabilityZones[].{Zone:@},&Zone)' --output text

us-east-1a
us-east-1c
us-east-1d

Poiché almeno due AZ si sovrappongono tra ogni coppia di cluster originali e cloni, entrambi i cluster possono accedere allo stesso storage Aurora sottostante.

Passaggio 2: Specificare le impostazioni di rete per le istanze nel clone

Quando si creano istanze DB nel clone, per impostazione predefinita queste ereditano il gruppo di sottoreti DB dal cluster stesso. In questo modo, Aurora assegna automaticamente ogni istanza a una particolare sottorete e la crea nell'AZ associata alla sottorete. Questa scelta è comoda, soprattutto per i sistemi di sviluppo e test, perché non è necessario tenere traccia degli ID di sottorete o degli AZ mentre si aggiungono nuove istanze al clone.

In alternativa, è possibile specificare l'AZ quando si crea un'istanza Aurora DB per il clone. L'AZ che specificate deve appartenere al set di AZ associati al clone. Se il gruppo di sottoreti DB che usi per il clone contiene solo due sottoreti, puoi scegliere solo tra le AZ associate a quelle due sottoreti. Questa scelta offre flessibilità e resilienza per sistemi ad alta disponibilità, perché potete assicurarvi che l'istanza writer e l'istanza standby reader si trovino in AZ diversi. Oppure, se aggiungi altri lettori al cluster, puoi assicurarti che siano distribuiti su tre AZ. In questo modo, anche nel raro caso di un errore AZ, avrete comunque un'istanza writer e un'altra istanza reader in altre due AZ.

L'esempio seguente aggiunge un'istanza DB con provisioning a un cluster Aurora PostgreSQL clonato che utilizza un gruppo di sottoreti DB personalizzato. 

aws rds create-db-instance --db-cluster-identifier my_aurora_postgresql_clone \
  --db-instance-identifier my_postgres_instance \
  --db-subnet-group-name my_new_subnet \
  --engine aurora-postgresql \
  --db-instance-class db.t4g.medium

L'esempio seguente mostra l'output parziale di tale comando. 

{
  'DBInstanceIdentifier': 'my_postgres_instance',
  'DBClusterIdentifier': 'my_aurora_postgresql_clone',
  'DBInstanceClass': 'db.t4g.medium',
  'DBInstanceStatus': 'creating'
  ...
}

L'esempio seguente aggiunge un'istanza DB Aurora Serverless v2 a un clone Aurora MySQL che utilizza un gruppo di sottoreti DB personalizzato. Per poter utilizzare le istanze Serverless v2, assicuratevi di specificare l'opzione per il comando, come mostrato negli --serverless-v2-scaling-configuration esempi precedenti. restore-db-cluster-to-point-in-time 

aws rds create-db-instance --db-cluster-identifier my_aurora_mysql_clone \
  --db-instance-identifier my_mysql_instance \
  --db-subnet-group-name my_other_new_subnet \
  --engine aurora-mysql \
  --db-instance-class db.serverless

L'esempio seguente mostra l'output parziale di tale comando. 

{
  'DBInstanceIdentifier': 'my_mysql_instance',
  'DBClusterIdentifier': 'my_aurora_mysql_clone',
  'DBInstanceClass': 'db.serverless',
  'DBInstanceStatus': 'creating'
  ...
}

Fase 3: Stabilire la connettività da un sistema client a un clone

Se ti stai già connettendo a un cluster Aurora da un sistema client, potresti voler consentire lo stesso tipo di connettività a un nuovo clone. Ad esempio, potresti connetterti al cluster originale da un'istanza Amazon Cloud9 o da un'istanza EC2. Per consentire connessioni dagli stessi sistemi client o da quelli nuovi creati nel VPC di destinazione, configura sottoreti DB e gruppi di sicurezza VPC equivalenti a quelli del VPC. Specificate quindi il gruppo di sottorete e i gruppi di sicurezza quando create il clone.

I seguenti esempi configurano un clone Aurora Serverless v2. Tale configurazione si basa sulla combinazione di --engine-mode provisioned e --serverless-v2-scaling-configuration durante la creazione del cluster DB e quindi sulla --db-instance-class db.serverless creazione di ogni istanza DB nel cluster. La modalità provisioned motore è l'impostazione predefinita, quindi puoi omettere questa opzione se preferisci. 

aws rds restore-db-cluster-to-point-in-time \
  --source-db-cluster-identifier serverless-sql-postgres\
  --db-cluster-identifier serverless-sql-postgres-clone \
  --db-subnet-group-name 'default-vpc-1234' \
  --vpc-security-group-ids 'sg-4567' \
  --serverless-v2-scaling-configuration 'MinCapacity=0.5,MaxCapacity=16' \
  --restore-type copy-on-write \
  --use-latest-restorable-time

Quindi, quando create le istanze DB nel clone, specificate la stessa opzione. --db-subnet-group-name Facoltativamente, è possibile includere l'--availability-zoneopzione e specificare una delle AZ associate alle sottoreti in quel gruppo di sottoreti. Tale AZ deve inoltre essere una delle AZ associate al cluster originale. 

aws rds create-db-instance \
  --db-cluster-identifier serverless-sql-postgres-clone \
  --db-instance-identifier serverless-sql-postgres-clone-instance \
  --db-instance-class db.serverless \
  --db-subnet-group-name 'default-vpc-987zyx654' \
  --availability-zone 'us-east-1c' \
  --engine aurora-postgresql

Spostamento di un cluster da sottoreti pubbliche a sottoreti private

È possibile utilizzare la clonazione per migrare un cluster tra sottoreti pubbliche e private. È possibile eseguire questa operazione aggiungendo ulteriori livelli di sicurezza all'applicazione prima di distribuirla in produzione. Per questo esempio, dovresti avere già configurato le sottoreti private e il gateway NAT prima di iniziare il processo di clonazione con Aurora.

Per i passaggi che coinvolgono Aurora, puoi seguire gli stessi passaggi generali degli esempi precedenti di e. Raccolta di informazioni sull'ambiente di rete Creazione di un clone di Aurora con nuove impostazioni di rete La differenza principale è che, anche se disponi di sottoreti pubbliche mappate a tutte le AZ del cluster originale, ora devi verificare di disporre di sottoreti private sufficienti per un cluster Aurora e che tali sottoreti siano associate a tutte le stesse AZ utilizzate per l'archiviazione Aurora nel cluster originale. Analogamente ad altri casi d'uso della clonazione, è possibile creare il gruppo di sottoreti DB per il clone con tre o due sottoreti private associate alle AZ richieste. Tuttavia, se si utilizzano due sottoreti private nel gruppo di sottoreti DB, è necessario disporre di una terza sottorete privata associata alla terza AZ utilizzata per l'archiviazione Aurora nel cluster originale.

È possibile consultare questa lista di controllo per verificare che siano soddisfatti tutti i requisiti per eseguire questo tipo di operazione di clonazione.

Quando tutti i prerequisiti sono soddisfatti, è possibile sospendere l'attività del database sul cluster originale durante la creazione del clone e cambiare l'applicazione per utilizzarlo. Dopo aver creato il clone e aver verificato di potervi connettere, aver eseguito il codice dell'applicazione e così via, potete interrompere l'uso del cluster originale.

nd-to-end Un esempio di creazione di un clone cross-VPC

La creazione di un clone in un VPC diverso da quello originale utilizza gli stessi passaggi generali degli esempi precedenti. Poiché l'ID VPC è una proprietà delle sottoreti, in realtà non si specifica l'ID VPC come parametro quando si esegue uno dei comandi CLI RDS. La differenza principale è che è più probabile che sia necessario creare nuove sottoreti, nuove sottoreti mappate su AZ specifici, un gruppo di sicurezza VPC e un nuovo gruppo di sottoreti DB. Ciò è particolarmente vero se si tratta del primo cluster Aurora creato in quel VPC.

Puoi consultare questa lista di controllo per verificare che siano soddisfatti tutti i requisiti per eseguire questo tipo di operazione di clonazione.

Quando tutti i prerequisiti sono soddisfatti, è possibile sospendere l'attività del database sul cluster originale durante la creazione del clone e cambiare l'applicazione per utilizzarlo. Dopo aver creato il clone e aver verificato di potervi connettere, eseguire il codice dell'applicazione e così via, potete valutare se mantenere attivi sia l'originale che i cloni oppure interrompere l'uso del cluster originale.

I seguenti esempi Linux mostrano la sequenza di operazioni AWS CLI per clonare un cluster Aurora DB da un VPC a un altro. Alcuni campi che non sono pertinenti agli esempi non vengono visualizzati nell'output del comando.

Innanzitutto, controlliamo gli ID dei VPC di origine e di destinazione. Il nome descrittivo che assegni a un VPC quando lo crei è rappresentato come tag nei metadati VPC. 

$ aws ec2 describe-vpcs --query '*[].[VpcId,Tags]'
[
    [
        'vpc-0f0c0fc0000b0ffb0',
        [
            {
                'Key': 'Name',
                'Value': 'clone-vpc-source'
            }
        ]
    ],
    [
        'vpc-9e99d9f99a999bd99',
        [
            {
                'Key': 'Name',
                'Value': 'clone-vpc-dest'
            }
        ]
    ]
]

Il cluster originale esiste già nel VPC di origine. Per configurare il clone utilizzando lo stesso set di AZ per l'archiviazione Aurora, controlliamo gli AZ utilizzati dal cluster originale. 

$ aws rds describe-db-clusters --db-cluster-identifier original-cluster \
  --query 'sort_by(*[].AvailabilityZones[].{Zone:@},&Zone)' --output text

us-east-1c
us-east-1d
us-east-1f

Ci assicuriamo che esistano sottoreti che corrispondano alle AZ utilizzate dal cluster originale:, e. us-east-1c us-east-1d us-east-1f 

$ aws ec2 create-subnet --vpc-id vpc-9e99d9f99a999bd99 \
  --availability-zone us-east-1c --cidr-block 10.0.0.128/28
{
    'Subnet': {
        'AvailabilityZone': 'us-east-1c',
        'SubnetId': 'subnet-3333a33be3ef3e333',
        'VpcId': 'vpc-9e99d9f99a999bd99',
    }
}

$ aws ec2 create-subnet --vpc-id vpc-9e99d9f99a999bd99 \
--availability-zone us-east-1d --cidr-block 10.0.0.160/28
{
    'Subnet': {
        'AvailabilityZone': 'us-east-1d',
        'SubnetId': 'subnet-4eeb444cd44b4d444',
        'VpcId': 'vpc-9e99d9f99a999bd99',
    }
}

$ aws ec2 create-subnet --vpc-id vpc-9e99d9f99a999bd99 \
--availability-zone us-east-1f --cidr-block 10.0.0.224/28
{
    'Subnet': {
        'AvailabilityZone': 'us-east-1f',
        'SubnetId': 'subnet-66eea6666fb66d66c',
        'VpcId': 'vpc-9e99d9f99a999bd99',
    }
}

Questo esempio conferma che esistono sottoreti mappate alle AZ necessarie nel VPC di destinazione. 

aws ec2 describe-subnets --query 'sort_by(*[] | [?VpcId == `vpc-9e99d9f99a999bd99`] |
[].{SubnetId:SubnetId,VpcId:VpcId,AvailabilityZone:AvailabilityZone}, &AvailabilityZone)' --output table

---------------------------------------------------------------------------
|                             DescribeSubnets                             |
+------------------+----------------------------+-------------------------+
| AvailabilityZone |         SubnetId           |          VpcId          |
+------------------+----------------------------+-------------------------+
|  us-east-1a      |  subnet-000ff0e00000c0aea  |  vpc-9e99d9f99a999bd99  |
|  us-east-1b      |  subnet-1111d111111ca11b1  |  vpc-9e99d9f99a999bd99  |
|  us-east-1c      | subnet-3333a33be3ef3e333   |  vpc-9e99d9f99a999bd99  |
|  us-east-1d      | subnet-4eeb444cd44b4d444   |  vpc-9e99d9f99a999bd99  |
|  us-east-1f      | subnet-66eea6666fb66d66c   |  vpc-9e99d9f99a999bd99  |
+------------------+----------------------------+-------------------------+

Prima di creare un cluster Aurora DB nel VPC, è necessario disporre di un gruppo di sottoreti DB con sottoreti mappate alle AZ utilizzate per l'archiviazione Aurora. Quando si crea un cluster normale, è possibile utilizzare qualsiasi set di tre AZ. Quando si clona un cluster esistente, il gruppo di sottoreti deve corrispondere ad almeno due delle tre AZ utilizzate per l'archiviazione Aurora. 

$ aws rds create-db-subnet-group \
  --db-subnet-group-name subnet-group-in-other-vpc \
  --subnet-ids '["subnet-3333a33be3ef3e333","subnet-4eeb444cd44b4d444","subnet-66eea6666fb66d66c"]' \
  --db-subnet-group-description 'DB subnet group with 3 subnets: subnet-3333a33be3ef3e333,subnet-4eeb444cd44b4d444,subnet-66eea6666fb66d66c'

{
    'DBSubnetGroup': {
        'DBSubnetGroupName': 'subnet-group-in-other-vpc',
        'DBSubnetGroupDescription': 'DB subnet group with 3 subnets: subnet-3333a33be3ef3e333,subnet-4eeb444cd44b4d444,subnet-66eea6666fb66d66c',
        'VpcId': 'vpc-9e99d9f99a999bd99',
        'SubnetGroupStatus': 'Complete',
        'Subnets': [
            {
                'SubnetIdentifier': 'subnet-4eeb444cd44b4d444',
                'SubnetAvailabilityZone': { 'Name': 'us-east-1d' }
            },
            {
                'SubnetIdentifier': 'subnet-3333a33be3ef3e333',
                'SubnetAvailabilityZone': { 'Name': 'us-east-1c' }
            },
            {
                'SubnetIdentifier': 'subnet-66eea6666fb66d66c',
                'SubnetAvailabilityZone': { 'Name': 'us-east-1f' }
            }
        ]
    }
}

Ora le sottoreti e il gruppo di sottoreti DB sono a posto. L'esempio seguente mostra restore-db-cluster-to-point-in-time che clona il cluster. L'--db-subnet-group-nameopzione associa il clone al set corretto di sottoreti mappate al set corretto di AZ del cluster originale. 

$ aws rds restore-db-cluster-to-point-in-time \
  --source-db-cluster-identifier original-cluster \
  --db-cluster-identifier clone-in-other-vpc \
  --restore-type copy-on-write --use-latest-restorable-time \
  --db-subnet-group-name subnet-group-in-other-vpc

{
  'DBClusterIdentifier': 'clone-in-other-vpc',
  'DBSubnetGroup': 'subnet-group-in-other-vpc',
  'Engine': 'aurora-postgresql',
  'EngineVersion': '15.4',
  'Status': 'creating',
  'Endpoint': 'clone-in-other-vpc.cluster-c0abcdef.us-east-1.rds.amazonaws.com'
}

L'esempio seguente conferma che lo storage Aurora nel clone utilizza lo stesso set di AZ del cluster originale. 

$ aws rds describe-db-clusters --db-cluster-identifier clone-in-other-vpc \
  --query 'sort_by(*[].AvailabilityZones[].{Zone:@},&Zone)' --output text

us-east-1c
us-east-1d
us-east-1f

A questo punto, è possibile creare istanze DB per il clone. Assicurati che il gruppo di sicurezza VPC associato a ciascuna istanza consenta le connessioni dagli intervalli di indirizzi IP che usi per le istanze EC2, i server delle applicazioni e così via che si trovano nel VPC di destinazione.

Clonazione tra account con AWS RAM e Amazon Aurora

Utilizzando AWS Resource Access Manager (AWS RAM) con Amazon Aurora, puoi condividere i cluster e i cloni di Aurora DB che appartengono al tuo AWS account con un altro account o organizzazione. AWS La clonazione tra più account è più veloce in queste situazioni piuttosto che con la creazione e il ripristino di uno snapshot di un database. Puoi creare un clone di uno dei tuoi cluster database Aurora e condividerlo. Oppure puoi condividere il tuo cluster Aurora DB con un altro AWS account e consentire al titolare dell'account di creare il clone. L’approccio scelto varia a seconda del caso d'uso.

Ad esempio, potrebbe essere necessario condividere regolarmente un clone del database finanziario con il team di verifica interno dell'organizzazione. In questo caso, il team di verifica utilizza il suo account AWS per le applicazioni. Puoi concedere all' AWS account del team di controllo l'autorizzazione ad accedere al tuo cluster Aurora DB e clonarlo secondo necessità.

D'altra parte, se un fornitore esterno verifica i tuoi dati finanziari, potresti preferire creare il clone da solo. È quindi possibile concedere al fornitore esterno solo l'accesso al clone.

Puoi anche utilizzare la clonazione tra account per supportare molti degli stessi casi d'uso per la clonazione all'interno dello stesso AWS account, ad esempio sviluppo e test. Ad esempio, l'organizzazione potrebbe utilizzare AWS account diversi per la produzione, lo sviluppo, i test e così via. Per ulteriori informazioni, consulta Panoramica sulla clonazione Aurora.

Pertanto, potresti voler condividere un clone con un altro AWS account o consentire a un altro AWS account di creare cloni dei tuoi cluster Aurora DB. In entrambi i casi, iniziate a usare per creare un oggetto AWS RAM di condivisione. Per informazioni complete sulla condivisione di AWS risorse tra AWS account, consulta la Guida AWS RAM per l'utente.

La creazione di un clone tra più account richiede azioni da parte dell' AWS account proprietario del cluster originale e dell' AWS account che crea il clone. Innanzitutto, il proprietario modifica il cluster per permettere a uno o più account di poterlo clonare. Se uno degli account appartiene a un' AWS organizzazione diversa, AWS genera un invito alla condivisione. L'altro account deve accettare l'invito prima di procedere. Dunque, ogni account autorizzato può clonare il cluster. Durante questo processo, il cluster è definito dal suo unico Amazon Resource Name (ARN).

Come per la clonazione all'interno dello stesso AWS account, lo spazio di archiviazione aggiuntivo viene utilizzato solo se vengono apportate modifiche ai dati dall'origine o dal clone. Gli addebiti per l’archiviazione vengono quindi applicati da quel momento. Se si elimina il cluster di origine, i costi di storage sono distribuiti equamente tra i cluster clonati rimanenti.

Restrizioni della clonazione tra più account

La clonazione tra più account di Aurora presenta le restrizioni seguenti:

  • Non puoi clonare un Aurora Serverless v1 cluster su più account. AWS

  • Non puoi visualizzare o accettare inviti a risorse condivise con. AWS Management Console Usa l' AWS CLI API Amazon RDS o la AWS RAM console per visualizzare e accettare inviti a risorse condivise.

  • Puoi creare solo un nuovo clone da un clone condiviso con il tuo account. AWS

  • Non puoi condividere risorse (cloni o cluster Aurora DB) che sono state condivise con il tuo account. AWS

  • Non è possibile creare più di 15 cloni tra account da un singolo cluster di database Aurora.

  • Ciascuno dei 15 cloni di più account deve appartenere a un account diverso. AWS In altre parole, è possibile creare solo un clone multiaccount di un cluster all'interno di qualsiasi account. AWS

  • Dopo la clonazione, il cluster originale e il relativo clone sono considerati identici ai fini dell'applicazione dei limiti sui cloni tra account. Non è possibile creare cloni tra più account sia del cluster originale che del cluster clonato all'interno dello stesso account. AWS Il numero totale di cloni tra account per il cluster originale e uno dei suoi cloni non può superare 15.

  • Non puoi condividere un cluster Aurora DB con altri AWS account a meno che il cluster non si trovi in uno ACTIVE stato.

  • Non è possibile rinominare un cluster Aurora DB condiviso con AWS altri account.

  • Non puoi creare un clone tra più account di un cluster crittografato con una chiave RDS predefinita.

  • Non è possibile creare cloni non crittografati in un AWS account da cluster Aurora DB crittografati che sono stati condivisi da un altro account. AWS Il proprietario del cluster deve inoltre concedere l'autorizzazione per accedere alla AWS KMS key del cluster di origine. Puoi tuttavia utilizzare una chiave differente quando crei il clone.

Consentire ad altri AWS account di clonare il cluster

Per consentire ad altri AWS account di clonare un cluster di tua proprietà, utilizza AWS RAM per impostare l'autorizzazione di condivisione. In questo modo viene inoltre inviato un invito a ciascuno degli altri account che fanno parte di un' AWS organizzazione diversa.

Per le procedure per condividere le risorse di tua proprietà nella AWS RAM console, consulta Condivisione delle risorse di tua proprietà nella Guida per l'AWS RAM utente.

Concessione dell'autorizzazione ad altri AWS account per clonare il cluster

Se il cluster che condividi è crittografato, condividi anche la AWS KMS key per il cluster. Puoi consentire agli utenti o ai ruoli AWS Identity and Access Management (IAM) di un AWS account di utilizzare una chiave KMS in un account diverso.

Per fare ciò, devi prima aggiungere l'account esterno (utente root) alla politica chiave della chiave KMS tramite. AWS KMS Non aggiungi singoli utenti o ruoli alla policy delle chiavi, ma solo l'account proprietario esterno. Puoi condividere solamente una chiave KMS che hai creato tu stesso, non la chiave del servizio RDS di default. Per ulteriori informazioni sul controllo accessi per le chiavi KMS, consulta Autenticazione e controllo degli accessi per AWS KMS.

Come concedere l'autorizzazione per clonare il tuo cluster

  1. Accedi AWS Management Console e apri la console Amazon RDS all'indirizzo https://console.aws.amazon.com/rds/.

  2. Nel riquadro di navigazione, scegliere Databases (Database).

  3. Scegli il cluster database che desideri condividere per visualizzare la pagina Dettagli e scegli la scheda Connectivity & security (Connessione e sicurezza).

  4. Nella sezione Condividi il cluster DB con altri AWS account, inserisci l'ID numerico dell'account a cui desideri consentire la AWS clonazione di questo cluster. Per gli ID degli account nella stessa organizzazione, puoi iniziare a digitare nel riquadro e poi scegliere dal menu.

    Importante

    In alcuni casi, potresti volere la clonazione di un cluster da parte di un account che non appartiene alla stessa organizzazione AWS del tuo account. In questi casi, per ragioni di sicurezza la console non segnala chi sia il proprietario dell'ID account o se l'account esiste.

    Fai attenzione a inserire numeri di conto che non appartengono alla stessa AWS organizzazione del tuo AWS account. Verifica immediatamente che la condivisione sia avvenuta con l'account desiderato.

  5. Nella pagina di conferma, verifica che l'ID dell'account specificato sia corretto. Inserisci share nel riquadro di conferma per confermare.

    Nella pagina Dettagli, viene visualizzata una voce che mostra l'ID dell' AWS account specificato in Account con cui è condiviso questo cluster DB. La colonna Stato mostra inizialmente lo stato Pending (In attesa).

  6. Contatta il proprietario dell'altro AWS account o accedi a quell'account se possiedi entrambi. Fornisci istruzioni al proprietario dell'altro account per accettare l'invito di condivisione e clonare il cluster database, nel modo descritto di seguito.

Come concedere l'autorizzazione per clonare il tuo cluster

  1. Raccogli le informazioni per i parametri richiesti. È necessario l'ARN per il cluster e l'ID numerico per l'altro account. AWS

  2. Esegui il comando AWS RAM CLI. create-resource-share

    Per LinuxmacOS, oUnix:

    aws ram create-resource-share --name descriptive_name \
  --region region \
  --resource-arns cluster_arn \
  --principals other_account_ids

    Per Windows:

    aws ram create-resource-share --name descriptive_name ^
  --region region ^
  --resource-arns cluster_arn ^
  --principals other_account_ids

    Per includere più ID di account per il parametro --principals, separa i singoli ID tramite spazi. Per specificare se gli ID degli account consentiti possono essere esterni alla tua organizzazione AWS , includi i parametri --allow-external-principals o --no-allow-external-principals per create-resource-share.

Come concedere l'autorizzazione per clonare il tuo cluster

  1. Raccogli le informazioni per i parametri richiesti. È necessario l'ARN per il cluster e l'ID numerico per l'altro account. AWS

  2. Chiama l'operazione AWS RAM API CreateResourceShare e specifica i seguenti valori:

    • Specificate l'ID dell'account per uno o più AWS account come principals parametro.

    • Specifica l’ARN di uno o più cluster database Aurora come parametro resourceArns.

    • Specifica se gli ID account consentiti possono essere esterni alla tua organizzazione AWS o meno includendo il valore booleano per il parametro allowExternalPrincipals.

Nuova creazione di un cluster che usa la chiave RDS predefinita

Se il cluster crittografato che desideri condividere utilizza la chiave RDS predefinita, assicurati di creare nuovamente il cluster. A tale scopo, crea uno snapshot manuale del cluster DB, utilizza una AWS KMS key e quindi ripristina il cluster in un nuovo cluster. Quindi condividi il nuovo cluster. Per eseguire questo processo, procedi come indicato di seguito.

Ricreare un cluster crittografato che usa una chiave RDS predefinita

  1. Accedi AWS Management Console e apri la console Amazon RDS all'indirizzo https://console.aws.amazon.com/rds/.

  2. Scegli Snapshots (Snapshot) dal riquadro di navigazione.

  3. Scegli il tuo snapshot.

  4. Sotto Operazioni, scegli Copy Snapshot (Copia snapshot) e poi Enable encryption (Abilita crittografia).

  5. Per AWS KMS key, scegli la nuova chiave di crittografia che desideri usare.

  6. Ripristina lo snapshot copiato. A tale scopo, segui la procedura in Ripristino da uno snapshot cluster database. La nuova istanza database usa la nuova chiave di crittografia.

  7. (Opzionale) Elimina il vecchio cluster database se non ne hai più bisogno. A tale scopo, segui la procedura in Eliminazione di una snapshot del cluster di database. Prima di farlo, conferma che il tuo nuovo cluster abbia tutti i dati necessari e che la tua applicazione può accedere correttamente.

Verifica se un cluster di tua proprietà è condiviso con altri account AWS

Puoi controllare se altri utenti hanno autorizzazione a condividere un cluster. Farlo ti aiuta a capire se il cluster si sta avvicinando al limite massimo di numeri di cloni tra più account.

Per le procedure per condividere le risorse utilizzando la AWS RAM console, consulta Condivisione delle risorse di tua proprietà nella Guida per l'AWS RAM utente.

Per scoprire se un cluster di tua proprietà è condiviso con altri AWS account

  • Chiama il comando AWS RAM CLI list-principals, utilizzando l'ID dell'account come proprietario della risorsa e l'ARN del cluster come ARN della risorsa. Puoi visualizzare tutte le condivisioni con il comando seguente. I risultati indicano a quali AWS account è consentito clonare il cluster. 

    aws ram list-principals \
    --resource-arns your_cluster_arn \
    --principals your_aws_id
Per scoprire se un cluster di tua proprietà è condiviso con altri AWS account

  • Chiama l'operazione AWS RAM API ListPrincipals. Usa il tuo ID dell'account come proprietario di risorse e l'ARN del tuo cluster come l'ARN di risorse.

Clonazione di un cluster di proprietà di un altro account AWS

Per clonare un cluster di proprietà di un altro AWS account, usa AWS RAM per ottenere l'autorizzazione a creare il clone. Dopo aver ottenuto l'autorizzazione richiesta, puoi usare la procedura standard per clonare un cluster Aurora.

Puoi anche verificare se un cluster di tua proprietà è un clone di un cluster di proprietà di un account diverso. AWS

Per le procedure di utilizzo delle risorse di proprietà di altri utenti nella AWS RAM console, vedi Accesso alle risorse condivise con te nella Guida per l'AWS RAM utente.

Visualizzazione degli inviti a clonare i cluster di proprietà di altri account AWS

Per gestire gli inviti a clonare i cluster di proprietà di AWS account di altre AWS organizzazioni, usa la AWS CLI, la console o l' AWS RAM API. AWS RAM Al momento, non puoi eseguire questa procedura utilizzando la console Amazon RDS.

Per le procedure di utilizzo degli inviti nella AWS RAM console, consulta Accesso alle risorse condivise con te nella Guida per l'utente.AWS RAM

Per visualizzare gli inviti a clonare i cluster di proprietà di altri account AWS

  1. Esegui il comando AWS RAM CLI. get-resource-share-invitations 

    aws ram get-resource-share-invitations --region region_name

    I risultati del comando precedente mostrano tutti gli inviti per clonare cluster, inclusi gli inviti già accettati o rifiutati.

  2. (Opzionale) Filtra l'elenco per vedere solamente gli inviti che necessitano una tua azione. A tale scopo, aggiungi il parametro --query 'resourceShareInvitations[?status==`PENDING`]'.

Per visualizzare gli inviti a clonare i cluster di proprietà di altri account AWS

  1. Chiama l'operazione API AWS RAM . GetResourceShareInvitations Questa operazione restituisce tutti questi inviti, inclusi gli inviti già accettati o rifiutati.

  2. (Opzionale) Trova solamente gli inviti che necessitano una tua azione verificando il campo di restituzione resourceShareAssociations per un valore status di PENDING.

Accettare inviti a condividere cluster di proprietà di altri account AWS

Puoi accettare inviti a condividere cluster di proprietà di altri AWS account appartenenti a organizzazioni diverse. AWS Per utilizzare questi inviti, usa le API AWS CLI, the AWS RAM e RDS o la console. AWS RAM Al momento, non puoi eseguire questa procedura utilizzando la console RDS.

Per le procedure di utilizzo degli inviti nella AWS RAM console, consulta Accesso alle risorse condivise con te nella Guida per l'utente.AWS RAM

Per accettare un invito a condividere un cluster da un altro account AWS

  1. Trova l'ARN dell'invito eseguendo il comando AWS RAM CLI get-resource-share-invitations, come mostrato in precedenza.

  2. Accetta l'invito chiamando il comando AWS RAM CLI accept-resource-share-invitation, come illustrato di seguito.

    Per LinuxmacOS, oUnix:

    aws ram accept-resource-share-invitation \
  --resource-share-invitation-arn invitation_arn \
  --region region

    Per Windows:

    aws ram accept-resource-share-invitation ^
  --resource-share-invitation-arn invitation_arn ^
  --region region
Come accettare inviti per condividere il cluster di qualcuno

  1. Trova l'ARN dell'invito chiamando l'operazione AWS RAM API GetResourceShareInvitations, come mostrato in precedenza.

  2. Passa quell'ARN come resourceShareInvitationArn parametro all'operazione API RDS. AcceptResourceShareInvitation

Clonazione di un cluster Aurora di proprietà di un altro account AWS

Dopo aver accettato l'invito dall' AWS account proprietario del cluster DB, come illustrato in precedenza, è possibile clonare il cluster.

Per clonare un cluster Aurora di proprietà di un altro account AWS

  1. Accedi AWS Management Console e apri la console Amazon RDS all'indirizzo https://console.aws.amazon.com/rds/.

  2. Nel riquadro di navigazione, scegliere Databases (Database).

    In cima all'elenco database, dovresti visualizzare uno o più elementi con un valore Ruolo di Shared from account #account_id. Per ragioni di sicurezza, puoi visualizzare solamente informazioni limitate riguardo i cluster originali. Puoi visualizzare le proprietà, come motore di database e versione, che devono essere uguali nel tuo cluster clonato.

  3. Scegli il cluster che desideri clonare.

  4. In Actions (Operazioni), selezionare Create clone (Crea clone).

  5. Segui la procedura in Console per completare la configurazione del cluster clonato.

  6. Abilita la crittografia per il cluster clonato come necessario. Se il cluster che stai clonando è crittografato, devi abilitare la crittografia per il cluster clonato. L'account AWS che ha condiviso con te il cluster deve condividere anche la chiave KMS utilizzata per crittografare il cluster. È possibile utilizzare la stessa chiave KMS per crittografare il clone o la propria chiave KMS. Non puoi creare un clone tra più account per un cluster crittografato con una chiave KMS di default.

    L'account che possiede la chiave di crittografia deve concedere l'autorizzazione per utilizzare la chiave all'account di destinazione utilizzando la policy delle chiavi. Questo processo è simile a quello per condividere gli snapshot crittografati, utilizzando una policy delle chiavi per concedere l'autorizzazione all'account di destinazione per utilizzare la chiave.

Per clonare un cluster Aurora di proprietà di un altro account AWS

  1. Accetta l'invito dell' AWS account proprietario del cluster DB, come mostrato in precedenza.

  2. Clona il cluster specificando l'ARN completo del cluster di origine nel parametro source-db-cluster-identifier del comando RDS CLI restore-db-cluster-to-point-in-time, come mostrato di seguito.

    Se l'ARN passato come source-db-cluster-identifier non è stato condiviso, si presenterà lo stesso errore del caso in cui il cluster indicato non esista.

    Per LinuxmacOS, oUnix:

    aws rds restore-db-cluster-to-point-in-time \
  --source-db-cluster-identifier=arn:aws:rds:arn_details \
  --db-cluster-identifier=new_cluster_id \
  --restore-type=copy-on-write \
  --use-latest-restorable-time

    Per Windows:

    aws rds restore-db-cluster-to-point-in-time ^
  --source-db-cluster-identifier=arn:aws:rds:arn_details ^
  --db-cluster-identifier=new_cluster_id ^
  --restore-type=copy-on-write ^
  --use-latest-restorable-time

  3. Se il cluster da clonare è crittografato, devi crittografare il tuo cluster clonato includendo un parametro kms-key-id. Questo valore kms-key-id può essere lo stesso di quello utilizzato per crittografare il cluster database originale o in alternativa la tua chiave KMS. Il tuo account deve avere l'autorizzazione a utilizzare la chiave di crittografia.

    Per LinuxmacOS, oUnix:

    aws rds restore-db-cluster-to-point-in-time \
  --source-db-cluster-identifier=arn:aws:rds:arn_details \
  --db-cluster-identifier=new_cluster_id \
  --restore-type=copy-on-write \
  --use-latest-restorable-time \
  --kms-key-id=arn:aws:kms:arn_details

    Per Windows:

    aws rds restore-db-cluster-to-point-in-time ^
  --source-db-cluster-identifier=arn:aws:rds:arn_details ^
  --db-cluster-identifier=new_cluster_id ^
  --restore-type=copy-on-write ^
  --use-latest-restorable-time ^
  --kms-key-id=arn:aws:kms:arn_details

    L'account che possiede la chiave di crittografia deve concedere l'autorizzazione per utilizzare la chiave all'account di destinazione utilizzando la policy delle chiavi. Questo processo è simile a quello per condividere gli snapshot crittografati, utilizzando una policy delle chiavi per concedere l'autorizzazione all'account di destinazione per utilizzare la chiave. Di seguito, un esempio di una policy delle chiavi. 

    {
  "Id": "key-policy-1",
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Allow use of the key",
      "Effect": "Allow",
      "Principal": {"AWS": [
        "arn:aws:iam::account_id:user/KeyUser",
        "arn:aws:iam::account_id:root"
      ]},
      "Action": [
        "kms:CreateGrant",
        "kms:Encrypt",
        "kms:Decrypt",
        "kms:ReEncrypt*",
        "kms:GenerateDataKey*",
        "kms:DescribeKey"
      ],
      "Resource": "*"
    },
    {
      "Sid": "Allow attachment of persistent resources",
      "Effect": "Allow",
      "Principal": {"AWS": [
        "arn:aws:iam::account_id:user/KeyUser",
        "arn:aws:iam::account_id:root"
      ]},
      "Action": [
        "kms:CreateGrant",
        "kms:ListGrants",
        "kms:RevokeGrant"
      ],
      "Resource": "*",
      "Condition": {"Bool": {"kms:GrantIsForAWSResource": true}}
    }
  ]
}
Nota

Il comando restore-db-cluster-to-point-in-time di AWS CLI ripristina solo il cluster database e non le istanze database per quel cluster. Per creare istanze database per il cluster database ripristinato, emetti il comando create-db-instance. Specifica l'identificatore del cluster database ripristinato in --db-cluster-identifier.

Puoi creare le istanze database solo dopo che il comando restore-db-cluster-to-point-in-time è terminato e il cluster database è disponibile.

Per clonare un cluster Aurora di proprietà di un altro account AWS

  1. Accetta l'invito dell' AWS account proprietario del cluster DB, come mostrato in precedenza.

  2. Clona il cluster specificando l'ARN completo del cluster di origine nel parametro SourceDBClusterIdentifier dell'operazione API RDS RestoreDBClusterToPointInTime.

    Se l'ARN passato come SourceDBClusterIdentifier non è stato condiviso, allora si presenterà lo stesso errore del caso in cui il cluster indicato non esista.

  3. Se il cluster da clonare è crittografato, includi un parametro KmsKeyId per crittografare il tuo cluster clonato. Questo valore kms-key-id può essere lo stesso di quello utilizzato per crittografare il cluster database originale o in alternativa la tua chiave KMS. Il tuo account deve avere l'autorizzazione a utilizzare la chiave di crittografia.

    Durante la clonazione di un volume, l'account di destinazione deve essere autorizzato all'utilizzo della chiave di crittografia usata per crittografare il cluster di origine. Aurora crittografa il nuovo cluster clonato con la chiave di crittografia specificata in KmsKeyId.

    L'account che possiede la chiave di crittografia deve concedere l'autorizzazione per utilizzare la chiave all'account di destinazione utilizzando la policy delle chiavi. Questo processo è simile a quello per condividere gli snapshot crittografati, utilizzando una policy delle chiavi per concedere l'autorizzazione all'account di destinazione per utilizzare la chiave. Di seguito, un esempio di una policy delle chiavi. 

    {
  "Id": "key-policy-1",
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Allow use of the key",
      "Effect": "Allow",
      "Principal": {"AWS": [
        "arn:aws:iam::account_id:user/KeyUser",
        "arn:aws:iam::account_id:root"
      ]},
      "Action": [
        "kms:CreateGrant",
        "kms:Encrypt",
        "kms:Decrypt",
        "kms:ReEncrypt*",
        "kms:GenerateDataKey*",
        "kms:DescribeKey"
      ],
      "Resource": "*"
    },
    {
      "Sid": "Allow attachment of persistent resources",
      "Effect": "Allow",
      "Principal": {"AWS": [
        "arn:aws:iam::account_id:user/KeyUser",
        "arn:aws:iam::account_id:root"
      ]},
      "Action": [
        "kms:CreateGrant",
        "kms:ListGrants",
        "kms:RevokeGrant"
      ],
      "Resource": "*",
      "Condition": {"Bool": {"kms:GrantIsForAWSResource": true}}
    }
  ]
}
Nota

L'operazione dell'API RestoreDB ClusterTo PointIn Time RDS ripristina solo il cluster DB, non le istanze DB per quel cluster DB. Per creare istanze database per il cluster database ripristinato, richiama l’operazione API RDS CreateDBInstance. Specifica l'identificatore del cluster database ripristinato in DBClusterIdentifier. È possibile creare le istanze database solo dopo che l'operazione RestoreDBClusterToPointInTime è completata e il cluster di database è disponibile.

Verifica se un cluster database è un clone tra più account

L'oggetto DBClusters identifica se ciascun cluster è un clone tra più account. Puoi visualizzare il cluster che puoi clonare utilizzando l'opzioneinclude-shared quando esegui il comando RDS CLI describe-db-clusters. Tuttavia, non puoi visualizzare la maggior parte dei dettagli di configurazione per tali cluster.

Come verificare se un cluster database è un clone tra più account

  • Denomina il comando RDS CLI describe-db-clusters.

    I seguenti esempi mostrano come sono visualizzati i cluster database effettivi o potenziali di cloni tra più account nell'output describe-db-clusters. Per i cluster esistenti di proprietà AWS dell'account, il CrossAccountClone campo indica se il cluster è un clone di un cluster DB di proprietà di un altro account. AWS

    In alcuni casi, una voce potrebbe avere un numero di AWS account diverso dal tuo nel DBClusterArn campo. In questo caso, quella voce rappresenta un cluster di proprietà di un AWS account diverso e che puoi clonare. Tali voci presentano pochi campi oltre DBClusterArn. Quando crei un cluster clonato, specifica che i valori per StorageEncrypted, Engine e EngineVersion siano gli stessi del cluster originale. 

    $aws rds describe-db-clusters --include-shared --region us-east-1
{
  "DBClusters": [
      {
          "EarliestRestorableTime": "2023-02-01T21:17:54.106Z",
          "Engine": "aurora-mysql",
          "EngineVersion": "8.0.mysql_aurora.3.02.0",
          "CrossAccountClone": false,
...
      },
      {
          "EarliestRestorableTime": "2023-02-09T16:01:07.398Z",
          "Engine": "aurora-mysql",
          "EngineVersion": "8.0.mysql_aurora.3.02.0",
          "CrossAccountClone": true,
...
      },
      {
          "StorageEncrypted": false,
          "DBClusterArn": "arn:aws:rds:us-east-1:12345678:cluster:cluster-abcdefgh",
          "Engine": "aurora-mysql",
          "EngineVersion": "8.0.mysql_aurora.3.02.0
  ]
}
Come verificare se un cluster database è un clone tra più account

  • Denomina l'operazione API RDSDescribeDBClusters.

    Per i cluster esistenti di proprietà del tuo AWS account, il CrossAccountClone campo indica se il cluster è un clone di un cluster DB di proprietà di un altro account. AWS Le voci con un numero di AWS account diverso nel DBClusterArn campo rappresentano cluster che è possibile clonare e che sono di proprietà di altri account. AWS Tali voci presentano pochi campi oltre DBClusterArn. Quando crei un cluster clonato, specifica che i valori per StorageEncrypted, Engine e EngineVersion siano gli stessi del cluster originale.

    Il seguente esempio mostra un valore di ritorno che dimostra sia i cluster clonati effettivi che potenziali. 

    {
  "DBClusters": [
      {
          "EarliestRestorableTime": "2023-02-01T21:17:54.106Z",
          "Engine": "aurora-mysql",
          "EngineVersion": "8.0.mysql_aurora.3.02.0",
          "CrossAccountClone": false,
...
      },
      {
          "EarliestRestorableTime": "2023-02-09T16:01:07.398Z",
          "Engine": "aurora-mysql",
          "EngineVersion": "8.0.mysql_aurora.3.02.0",
          "CrossAccountClone": true,
...
      },
      {
          "StorageEncrypted": false,
          "DBClusterArn": "arn:aws:rds:us-east-1:12345678:cluster:cluster-abcdefgh",
          "Engine": "aurora-mysql",
          "EngineVersion": "8.0.mysql_aurora.3.02.0"
      }
  ]
}