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

VPCClonazione incrociata con Amazon Aurora

Supponiamo di voler imporre diversi controlli di accesso alla rete al cluster originale e al clone. Ad esempio, è possibile utilizzare la clonazione per creare una copia di un cluster Aurora di produzione in un VPC altro a scopo di sviluppo e test. Oppure potreste 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 archiviazione Aurora, anche da sottoreti diverse o diverse. VPCs 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 le sottoreti e i VPCs gruppi di sottoreti DB, consulta prima. Amazon VPC e 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 RDS passaggio da un EC2 servizio all'altro, negli esempi vengono utilizzati AWS CLI comandi che consentono di comprendere come automatizzare tali operazioni e salvare l'output.

Prima di iniziare

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

Raccolta di informazioni sull'ambiente di rete

Con la VPC clonazione incrociata, l'ambiente di rete può differire notevolmente tra il cluster originale e il relativo clone. Prima di creare il clone, raccogli e registra le informazioni sulle sottoretiVPC, sul gruppo di sottoreti DB e sulle informazioni utilizzate nel cluster originale. AZs In questo modo, è possibile 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 CLI esempi 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 quale tipo di archiviazione viene utilizzato AZs dal cluster originale. Come spiegato inArchiviazione Amazon Aurora, lo storage per ogni cluster Aurora è associato esattamente a tre. AZs 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 CLI comando come il seguente, sostituendo il nome del tuo 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 ne utilizza sempre tre. AZs

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 tali sottoretiAZs, è necessario creare sottoreti associate ad almeno due di queste e quindi creare un gruppo di sottoreti DB contenente queste AZs 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 a quali sottoreti sono AZs associate.

L'esempio seguente mostra come trovare il gruppo di sottoreti DB del cluster originale e quindi tornare al gruppo corrispondente. AZs 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 del cluster originale, AWS CLI esegui comandi simili ai seguenti. È possibile esaminare gli attributi della sottorete, ad esempio gli intervalli di indirizzi IP, il proprietario e così via. In questo modo, è possibile determinare se utilizzare diverse sottoreti nella stessa VPC o creare sottoreti con caratteristiche simili in un'altra. VPC

Trova la sottorete IDs 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 è possibile visualizzare per ogni sottorete, ad esempio la zona Z associata e VPC quella 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 istanze DB AZs utilizzate nel cluster originale. In questo modo, puoi configurare esattamente lo stesso AZs 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. AZs

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

Dopo aver creato il clone e avervi aggiunto delle 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 AZs come nel cluster originale.

Passaggio 5: verifica VPCs che puoi utilizzare per il clone

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

Per elencare tutti i dati VPCs relativi al tuo account, esegui il CLI comando seguente:

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

L'esempio seguente mostra un esempio di output del describe-vpcs comando precedente. L'output dimostra che ce ne sono quattro VPCs nell' AWS account corrente che possono essere usati come origine o destinazione per la clonazione incrociata. VPC

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

È possibile utilizzare la VPC stessa destinazione del clone o un'altra. VPC Se il cluster originale e il clone si trovano nello stesso gruppoVPC, è possibile 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 altro clusterVPC, assicurati che ci siano abbastanza sottoreti nel nuovo cluster VPC e che le sottoreti siano associate al lato destro del cluster originale. AZs

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 sottoreti specifiche o un nuovo gruppo di sottoreti AZs 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 ambiente o quando si apportano altre modifiche alla reteVPC, ad esempio utilizzando sottoreti private anziché sottoreti pubbliche.

AWS genera automaticamente l'ID della sottorete. Sostituisci il nome del clone con. VPC my_vpc Scegliete l'intervallo di indirizzi per consentire almeno 16 indirizzi IP nell'intervallo. --cidr-block È 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 state creando il clone in un set di sottoreti diverso VPC o diverso all'interno della stessaVPC, create un nuovo gruppo di sottoreti DB e lo specificate durante la creazione del clone.

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

Controlla quanti AZs sono entrambi associati all'archiviazione del cluster originale e associati alle sottoreti nella destinazione. VPC Per creare correttamente il clone, devono esserci due o tre AZs elementi in comune. Se ne avete meno di due AZs in comune, tornate aFase 1: Creare le sottoreti per il clone. Crea una, due o tre nuove sottoreti associate all'archiviazione AZs associata al cluster originale.

Scegli le sottoreti nella destinazione VPC che sono associate allo AZs stesso spazio di archiviazione Aurora nel cluster originale. Idealmente, scegline tre. AZs In questo modo avrai la massima flessibilità per distribuire le istanze DB del clone su più istanze AZs per un'elevata disponibilità delle risorse di elaborazione.

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

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. Hai creato tutte le risorse pertinenti VPC e le sottoreti 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

Una volta verificata la corretta configurazione delle sottoreti e dei VPCs gruppi di sottoreti per l'utilizzo del nuovo clusterAZs, è possibile eseguire l'operazione di clonazione vera e propria. CLIGli esempi seguenti 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.

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

Quando crei il clone, puoi configurare tutte le impostazioni rightVPC, subnet e AZ 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 (). ACUs Per informazioni sulla funzionalità Aurora Serverless v2 e su come scegliere l'intervallo di capacità, vedere. Utilizzo 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. AZs L'esempio seguente elenca i AZs comandi associati sia al cluster originale che al clone, per entrambi i comandi degli restore-db-cluster-to-point-in-time esempi precedenti.

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 dei cluster AZs 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 della sottorete IDs o AZs 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 specificato deve appartenere all'insieme di AZs quelli associati al clone. Se il gruppo di sottoreti DB che usi per il clone contiene solo due sottoreti, puoi scegliere solo tra quelle AZs 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 siano diverse. AZs Oppure, se aggiungi altri lettori al cluster, puoi assicurarti che siano distribuiti su tre. AZs In questo modo, anche nel raro caso di errore di AZ, avrete comunque un'istanza Writer e un'altra istanza Reader in altre dueAZs.

L'esempio seguente aggiunge un'istanza DB di cui è stato effettuato il provisioning a un cluster Aurora SQL Postgre 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 SQL clone Aurora My che utilizza un gruppo di sottoreti DB personalizzato. Per poter utilizzare le istanze Serverless v2, assicuratevi di specificare l'--serverless-v2-scaling-configurationopzione per il comando, come mostrato negli 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 o istanza Amazon Cloud9. EC2 Per consentire connessioni dagli stessi sistemi client o da quelli nuovi creati nella destinazioneVPC, configura sottoreti DB e gruppi di VPC sicurezza equivalenti a quelli di. VPC Specificate quindi il gruppo di sottoreti 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 opzioni AZs associate alle sottoreti in quel gruppo di sottoreti. Tale AZ deve inoltre essere una delle aree AZs 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 NAT gateway 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 disponete di sottoreti pubbliche che mappano tutte le AZs sottoreti del cluster originale, ora è necessario verificare di disporre di un numero sufficiente di sottoreti private per un cluster Aurora e che tali sottoreti siano associate a tutte le sottoreti utilizzate per l'archiviazione Aurora nel cluster originale. AZs 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 a quanto richiestoAZs. 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.

End-to-end esempio di creazione di un clone incrociato VPC

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

È 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, 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 AWS CLI operazioni per clonare un cluster Aurora DB da VPC uno all'altro. Alcuni campi non pertinenti agli esempi non vengono visualizzati nell'output del comando.

Innanzitutto, controlliamo l'IDsorigine e la destinazioneVPCs. Il nome descrittivo che assegnate a un oggetto VPC quando lo create è rappresentato come un tag nei metadatiVPC.

$ 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à nell'origine. VPC Per configurare il clone utilizzando lo stesso set AZs di storage Aurora, controlliamo quello usato AZs 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 ci siano sottoreti che corrispondano a quelle AZs utilizzate dal cluster originale:us-east-1c, e. 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 al necessario AZs nella destinazione. VPC

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 inVPC, è necessario disporre di un gruppo di sottoreti DB con sottoreti mappate allo storage utilizzato per AZs Aurora. Quando si crea un cluster normale, è possibile utilizzare qualsiasi set di tre. AZs Quando si clona un cluster esistente, il gruppo di sottoreti deve corrispondere ad almeno due dei tre AZs utilizzati 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 del cluster originale. AZs

$ 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 del AZs 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. Assicuratevi che il gruppo VPC di sicurezza associato a ciascuna istanza consenta le connessioni dagli intervalli di indirizzi IP utilizzati per le EC2 istanze, i server delle applicazioni e così via presenti nella destinazione. VPC