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à.
Configurazione della Neptune-to-Neptune replica
Il cluster database di produzione primario risiede in un VPC di una determinata regione di origine. Sono tre gli elementi principali che è necessario replicare o emulare in una regione di ripristino diversa ai fini del ripristino di emergenza:
I dati archiviati nel cluster.
La configurazione del cluster primario. Ad esempio, se utilizza l'autenticazione IAM, se è crittografato, i parametri del cluster database, i parametri delle istanze, le dimensioni delle istanze e così via.
La topologia di rete utilizzata, inclusi il VPC di destinazione, i relativi gruppi di sicurezza e così via.
È possibile utilizzare la APIs gestione di Neptune come la seguente per raccogliere tali informazioni:
Con le informazioni raccolte, è possibile utilizzare la seguente procedura per configurare un cluster di backup in una regione diversa, sul quale il cluster di produzione può eseguire il failover in caso di errore.
Abilita i flussi di Neptune
È possibile usare Modificare DBCluster ParameterGroup per impostare il parametro neptune_streams su 1. Quindi, riavviare tutte le istanze del cluster database in modo che la modifica abbia effetto.
È consigliabile eseguire almeno un'operazione di aggiunta o aggiornamento sul cluster database di origine dopo aver abilitato Neptune Streams. In questo modo il flusso di modifiche viene popolato con punti dati a cui è possibile fare riferimento in seguito quando si risincronizza il cluster di produzione con il cluster di backup.
Crea un nuovo VPC nella regione in cui desideri configurare il cluster di backup
Prima di creare un nuovo cluster database Neptune in una regione diversa dal cluster primario, è necessario stabilire un nuovo VPC nella regione di destinazione per ospitare il cluster. La connettività tra i cluster primari e di backup viene stabilita tramite il peering VPC, che utilizza il traffico tra sottoreti private in diversi modi. VPCs Tuttavia, per stabilire il peering VPC tra due VPCs, non devono avere blocchi CIDR o spazi di indirizzi IP sovrapposti. Ciò significa che non è possibile usare il VPC predefinito in entrambe le regioni, perché il blocco CIDR per un VPC predefinito è sempre lo stesso (172.31.0.0/16).
È possibile utilizzare un VPC esistente nella regione di destinazione, purché soddisfi le seguenti condizioni:
Non deve avere un blocco CIDR che si sovrappone al blocco CIDR del VPC in cui si trova il cluster primario.
Non deve essere già connesso tramite peering con un altro VPC con lo stesso blocco CIDR del VPC in cui si trova il cluster primario.
Se non è disponibile un VPC adatto nella regione di destinazione, creane uno utilizzando l'API CreateVpc di Amazon EC2.
Crea un'istantanea del cluster primario e ripristinala nella regione di backup di destinazione
Creare ora un nuovo cluster Neptune in un VPC appropriato nella regione di backup di destinazione che è una copia del cluster di produzione:
Creare una copia del cluster di produzione nella regione di backup
-
Nella regione di backup di destinazione, ricreare i parametri e i gruppi di parametri utilizzati dal cluster database di produzione. A tale scopo, è possibile utilizzare CreateDBClusterParameterGroup, CreateDBParameterGroup, ModifyDBClusterParameterGroup e ModifyDBParameterGroup.
Tieni presente che CopyDBClusterParameterGroupattualmente CopyDBParameterGroup APIs non supportano la copia tra regioni.
Utilizzare CreateDBClusterSnapshot per creare uno snapshot del cluster di produzione nel VPC della regione di produzione.
Utilizzare CopyDBClusterSnapshot per copiare lo snapshot nel VPC della regione di backup di destinazione.
Utilizzare RestoreDBClusterFromSnapshot per creare un nuovo cluster database nel VPC della regione di backup di destinazione utilizzando lo snapshot copiato. Utilizzare le impostazioni e i parametri di configurazione copiati dal cluster di produzione primario.
-
Il nuovo cluster Neptune ora esiste ma non contiene istanze. CreateDBInstanceUtilizzatelo per creare una nuova primary/writer istanza con lo stesso tipo e le stesse dimensioni dell'istanza writer del cluster di produzione. A questo punto non è necessario creare repliche di lettura aggiuntive, a meno che l'istanza di backup non venga utilizzata per eseguire il servizio di lettura I/O nell'area di destinazione prima del failover.
Stabilisci il peering VPC tra il VPC del cluster primario e il VPC del nuovo cluster di backup
Configurando il peering VPC, si consente al VPC del cluster primario di comunicare con il VPC del cluster di backup come se si trattasse di un'unica rete privata. Per questa opzione, effettua la procedura riportata di seguito.
Dal VPC del cluster di produzione, chiamare l'API
CreateVpcPeeringConnectionper stabilire la connessione peering.Dal VPC del cluster di backup di destinazione, chiamare l'API
AcceptVpcPeeringConnectionper accettare la connessione peering.Dal VPC del cluster di produzione, utilizzare l'API
CreateRouteper aggiungere una route alla tabella di routing del VPC che reindirizza tutto il traffico al blocco CIDR del VPC di destinazione in modo che utilizzi l'elenco dei prefissi di peering VPC.Analogamente, dal VPC del cluster di backup di destinazione, utilizzare l'API
CreateRouteper aggiungere una route alla tabella di routing del VPC che instrada il traffico al VPC del cluster primario.
Configurare l'infrastruttura di replica di Neptune Streams
Ora che entrambi i cluster sono stati implementati e la comunicazione di rete tra le due regioni è stata stabilita, utilizza il modello Neptune-to-Neptune CloudFormation per implementare la funzione Lambda consumer Neptune Streams con l'infrastruttura aggiuntiva che supporta la replica dei dati. Eseguire questa operazione nel VPC del cluster di produzione primario.
I parametri CloudFormation che dovrai fornire per questo stack sono:
-
NeptuneStreamEndpoint: endpoint del flusso per il cluster primario, in formato URL. Ad esempio:https://.(cluster name):8182/pg/stream -
QueryEngine: deve esseregremlin,sparqloopenCypher. -
RouteTableIds: consente di aggiungere route sia per un endpoint VPC DynamoDB che per un endpoint VPC di monitoraggio.Anche i due parametri aggiuntivi, vale a dire
CreateMonitoringEndpointeCreateDynamoDBEndpoint, devono essere impostati su true se non sono già presenti nel VPC del cluster primario. Se esistono già, assicurati che siano impostati su false o la CloudFormation creazione avrà esito negativo. -
SecurityGroupIds: specifica il gruppo di sicurezza utilizzato dal consumer Lambda per comunicare con l'endpoint del flusso Neptune del cluster primario.Nel cluster di backup di destinazione, collegare un gruppo di sicurezza che consenta il traffico proveniente da questo gruppo di sicurezza.
-
SubnetIds: elenco di ID di sottorete nel VPC del cluster primario che possono essere utilizzati dal consumer Lambda per comunicare con il cluster primario. -
TargetNeptuneClusterEndpoint: endpoint (solo nome host) del cluster di backup di destinazione. -
TargetAWSRegion— La AWS regione del cluster di backup di destinazione, ad esempious-east-1). È necessario fornire questo parametro solo quando la AWS regione del cluster di backup di destinazione è diversa dalla regione del cluster di origine Neptune, come nel caso della replica tra regioni. Se le regioni di origine e di destinazione coincidono, questo parametro è facoltativo.Nota che se il
TargetAWSRegionvalore non è una AWS regione valida supportata da Neptune, il processo fallisce. -
VPC: ID del VPC del cluster primario.
Tutti gli altri parametri possono essere lasciati con i valori predefiniti.
Una volta distribuito il CloudFormation modello, Neptune inizierà a replicare tutte le modifiche dal cluster primario al cluster di backup. È possibile monitorare questa replica nei CloudWatch log generati dalla funzione consumer Lambda.