Switchover di un'implementazione blu/verde

Uno switchover promuove il cluster di database, comprese le relative istanze database, nell'ambiente verde come cluster di database di produzione. Prima dello switchover, il traffico di produzione viene indirizzato al cluster nell'ambiente blu. Dopo lo switchover, il traffico di produzione viene indirizzato al cluster di database nell'ambiente verde.

Timeout dello switchover

È possibile specificare un timeout per lo switchover compreso tra 30 secondi e 3.600 secondi (un'ora). Se lo switchover richiede più tempo della durata specificata, viene eseguito il rollback di tutte le modifiche e non viene apportata alcuna modifica agli ambienti. L'impostazione predefinita del timeout è 300 secondi (cinque minuti).

Guardrail dello switchover

Quando avvii uno switchover, Amazon RDS esegue alcuni controlli di base per verificare la preparazione degli ambienti blu e verdi per lo switchover. Questi controlli sono noti come guardrail dello switchover e impediscono lo switchover se gli ambienti non sono pronti per farlo. Pertanto, evitano tempi di inattività più lunghi del previsto e impediscono la perdita di dati tra gli ambienti blu e quelli verdi che potrebbe verificarsi se lo switchover venisse avviato.

Amazon RDS esegue i seguenti controlli guardrail sull'ambiente verde:

• Integrità della replica: verifica se lo stato della replica del cluster di database verde è integro. Il cluster di database verde è una replica del cluster di database blu.

• Ritardo della replica: verifica se il ritardo della replica del cluster di database verde rientra nei limiti consentiti per lo switchover. I limiti consentiti si basano sul periodo di timeout specificato. Il ritardo della replica indica il ritardo del cluster di database verde rispetto al cluster di database blu. Per ulteriori informazioni, consulta Diagnosi e risoluzione del ritardo tra repliche di lettura per Aurora MySQL e Monitoraggio della replica Aurora PostgreSQL. per Aurora PostgreSQL.

• Scritture attive: assicura che non vi siano scritture attive nel cluster di database verde.

Amazon RDS esegue i seguenti controlli guardrail sull'ambiente blu:

• Replica esterna: per Aurora , assicura che l'ambiente blu non sia una fonte logica autogestita (editore) o una replica (sottoscrittore). In tal caso, si consiglia di eliminare gli slot e gli abbonamenti di replica autogestiti su tutti i database nell'ambiente blu, procedere con il passaggio al digitale e quindi ricrearli per riprendere la replica. Per Aurora MySQL RDS for MySQL non sia una replica binlog esterna.

• Scritture attive di lunga durata: assicura che non vi siano scritture attive di lunga durata nel cluster di database blu perché possono aumentare il ritardo della replica.

• Istruzioni DDL di lunga durata: assicura che non vi siano istruzioni DLL di lunga durata nel cluster di database blu perché possono aumentare il ritardo della replica.

• Modifiche PostgreSQL non supportate: per i cluster di database Aurora PostgreSQL, assicura che non siano state eseguite modifiche DDL, aggiunte o modifiche di oggetti di grandi dimensioni nell'ambiente blu. Per ulteriori informazioni, consulta Limitazioni della replica logica di PostgreSQL per le implementazioni blu/verde.

  Se Amazon RDS rileva modifiche PostgreSQL non supportate, modifica lo stato di replica su Replication degraded e ti avvisa che lo switchover non è disponibile per l'implementazione blu/verde. Per procedere con lo switchover, ti consigliamo di eliminare e ricreare l'implementazione blu/verde e tutti i database verdi. A tale scopo, scegli Operazioni, Elimina con database verdi.

Azioni dello switchover

Quando si effettua lo switchover per un'implementazione blu/verde, RDS esegue le seguenti azioni:

1. Esegue controlli guardrail per verificare se gli ambienti blu e verdi sono pronti per lo switchover.

2. Interrompe le nuove operazioni di scrittura nel cluster di database in entrambi gli ambienti.

3. Elimina le connessioni alle istanze database in entrambi gli ambienti e non consente nuove connessioni.

4. Attende che la replica recuperi l'ambiente verde in modo che sia sincronizzato con l'ambiente blu.

5. Rinomina il cluster di database e le istanze database in entrambi gli ambienti.

   RDS rinomina il cluster di database e le istanze database nell'ambiente verde in modo che corrispondano al cluster di database e alle istanze database nell'ambiente blu. Ad esempio, supponi che il nome dell'istanza database nell'ambiente blu sia mydb. Supponi anche che il nome dell'istanza database corrispondente nell'ambiente verde sia mydb-green-abc123. Durante lo switchover, il nome dell'istanza database nell'ambiente verde viene modificato in mydb.

   RDS rinomina il cluster di database e le istanze database nell'ambiente blu aggiungendo -oldn al nome corrente, dove n è un numero. Ad esempio, supponi che il nome dell'istanza database nell'ambiente blu sia mydb. Dopo lo switchover, il nome dell'istanza database diventa mydb-old1.

   RDS rinomina anche gli endpoint nell'ambiente verde in modo che corrispondano agli endpoint nell'ambiente blu, per non apportare modifiche all'applicazione.

6. Consente le connessioni ai database in entrambi gli ambienti.

7. Consente le operazioni di scrittura nel cluster di database nel nuovo ambiente di produzione.

   Anche se disabiliti il read_only parametro sul cluster DB, rimane di sola lettura finché non elimini la distribuzione blu/verde.

Puoi monitorare lo stato di uno switchover utilizzando Amazon. EventBridge Per ulteriori informazioni, consulta Eventi di implementazione blu/verde.

Se configurati nell'ambiente blu, i tag vengono spostati nel nuovo ambiente di produzione durante lo switchover. Anche l'ambiente di produzione precedente mantiene questi tag. Per ulteriori informazioni sui tag, consulta Tagging delle risorse Amazon RDS.

Se lo switchover inizia e poi si interrompe prima del termine per un qualsiasi motivo, viene eseguito il rollback di tutte le modifiche e non viene apportata alcuna modifica agli ambienti.

Best practice per lo switchover

Prima di effettuare lo switchover, ti consigliamo vivamente di seguire le best practice completando le seguenti attività:

• Esegui accuratamente il test delle risorse nell'ambiente verde. Assicurati che funzionino correttamente ed efficacemente.

• Monitora i CloudWatch parametri Amazon pertinenti. Per ulteriori informazioni, consulta Verifica CloudWatch delle metriche prima del passaggio al digitale.

• Identifica il momento migliore per lo switchover.

  Durante lo switchover, le scritture dei database vengono interrotte in entrambi gli ambienti. Identifica il momento in cui il traffico è più basso nell'ambiente di produzione. Le transazioni di lunga durata, come le DDL attive, possono aumentare i tempi dello switchover, con conseguenti tempi di inattività più lunghi per i carichi di lavoro di produzione.

  Se è presente un numero elevato di connessioni a cluster database e istanze database, valutare la possibilità di ridurre tale numero manualmente alla quantità minima necessaria per l'applicazione prima di effettuare lo switchover all'implementazione blu/verde. A tale scopo, creare uno script che monitora lo stato dell'implementazione blu/verde e inizia a rimuovere le connessioni quando rileva che lo stato è cambiato in SWITCHOVER_IN_PROGRESS.

• Assicurati che il cluster di database e le istanze database siano nello stato Available in entrambi gli ambienti.

• Assicurati che il cluster di database nell'ambiente verde sia nello stato integro e in grado di replicare.

• Assicurati che le configurazioni di rete e client non aumentino il Time-To-Live (TTL) della cache DNS di oltre cinque secondi, ovvero l'impostazione predefinita per le zone DNS Aurora.
 Altrimenti, le applicazioni continueranno a inviare traffico di scrittura all'ambiente blu dopo lo switchover.

• Non è possibile ripristinare una distribuzione blu/verde dopo il passaggio al digitale. Per i carichi di lavoro di produzione critici, valuta la possibilità di effettuare il provisioning di un cluster DB di del passaggio.

• Per i cluster Aurora PostgreSQL DB per le istanze DB PostgreSQL, procedi come segue:

  • Esamina i limiti della replica logica e intraprendi le azioni necessarie prima del passaggio. Per ulteriori informazioni, consulta Limitazioni della replica logica di PostgreSQL per le implementazioni blu/verde.

  • Eseguire l'operazione ANALYZE per aggiornare la tabella pg_statistics. Ciò riduce il rischio di problemi di prestazioni dopo il passaggio al digitale.

Nota

Durante uno switchover non è possibile modificare il cluster di database incluso nello switchover.

Verifica CloudWatch delle metriche prima del passaggio al digitale

Prima di passare a una distribuzione blu/verde, ti consigliamo di controllare i valori delle seguenti metriche all'interno di Amazon. CloudWatch

• DatabaseConnections: utilizza questo parametro per stimare il livello di attività dell'implementazione blu/verde e assicurarti che il valore sia a un livello accettabile per la tua implementazione prima dello switchover. Se Approfondimenti sulle prestazioni è attivato, DBLoad è un parametro più accurato.

• ActiveTransactions: se innodb_monitor_enable è impostato su all nel gruppo di parametri del database per una qualsiasi istanza database, usa questo parametro per vedere se c'è un numero elevato di transazioni attive che possono bloccare lo switchover.

Per ulteriori informazioni su questi parametri, consulta CloudWatch Parametri Amazon per Amazon Aurora.

Monitoraggio del ritardo nella replica prima del passaggio al digitale

Prima di passare a una distribuzione blu/verde, assicurati che il ritardo di replica sul database verde sia vicino allo zero per ridurre i tempi di inattività.

• Per Aurora MySQL, usa la AuroraBinlogReplicaLag CloudWatch metrica per identificare l'attuale ritardo di replica nell'ambiente verde.

• Per Aurora PostgreSQL, usa la seguente query SQL:

  SELECT slot_name,
         confirmed_flush_lsn as flushed,
         pg_current_wal_lsn(),
         (pg_current_wal_lsn() - confirmed_flush_lsn) AS lsn_distance
  FROM pg_catalog.pg_replication_slots
  WHERE slot_type = 'logical';
  
  slot_name        |    flushed    | pg_current_wal_lsn | lsn_distance
  -----------------+---------------+--------------------+------------
  logical_replica1 | 47D97/CF32980 | 47D97/CF3BAC8      | 37192

  confirmed_flush_lsnRappresenta l'ultimo numero di sequenza di registro (LSN) inviato alla replica. pg_current_wall_lsnRappresenta la posizione attuale del database. Un valore lsn_distance pari a 0 indica che la replica è stata recuperata.

Switchover di un'implementazione blu/verde

È possibile passare da una distribuzione blu/verde utilizzando l'API AWS Management Console AWS CLI, the o RDS.

Console

Per eseguire lo switchover di un'implementazione blu/verde

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

2. Nel riquadro di navigazione, scegli Databases (Database) e seleziona l'implementazione blu/verde di cui eseguire lo switchover.

3. In Actions (Operazioni), scegli Switch over (Esegui switchover).

   Viene visualizzata la pagina Switch over (Switchover).

   

4. Nella pagina Switch over (Switchover), consulta il riepilogo dello switchover. Assicurati che le risorse in entrambi gli ambienti corrispondano a quelle previste. In caso contrario, scegli Cancel (Annulla).

5. In Impostazioni di timeout, inserisci il limite di tempo per lo switchover.

6. Se sul cluster è in esecuzione Aurora PostgreSQL, esamina e verifica i suggerimenti prima dello switchover. Per ulteriori informazioni, consulta Limitazioni della replica logica di PostgreSQL per le implementazioni blu/verde.

7. Seleziona Switch over (Switchover).

AWS CLI

Per passare da una distribuzione blu/verde utilizzando il AWS CLI, usa il switchover-blue-green-deploymentcomando con le seguenti opzioni:

• --blue-green-deployment-identifier— Specificare l'ID della risorsa della distribuzione blu/verde.

• --switchover-timeout: specifica il limite di tempo per lo switchover, in secondi. Il valore predefinito è 300.

Esempio Switchover di un'implementazione blu/verde

PerLinux, omacOS: Unix

aws rds switchover-blue-green-deployment \
    --blue-green-deployment-identifier bgd-1234567890abcdef \
    --switchover-timeout 600

Per Windows:

aws rds switchover-blue-green-deployment ^
    --blue-green-deployment-identifier bgd-1234567890abcdef ^
    --switchover-timeout 600

API RDS

Per eseguire lo switchover di una implementazione blu/verde utilizzando l'API Amazon RDS, usa l'operazione SwitchoverBlueGreenDeployment con i seguenti parametri:

• BlueGreenDeploymentIdentifier— Specificare l'ID della risorsa della distribuzione blu/verde.

• SwitchoverTimeout: specifica il limite di tempo per lo switchover, in secondi. Il valore predefinito è 300.

Dopo lo switchover

Dopo uno switchover, il cluster di database e le istanze database vengono mantenuti nell'ambiente blu precedente. A queste risorse si applicano i costi standard. La replica e il log binario tra gli ambienti blu e verde vengono arrestati.

RDS rinomina il cluster di database e le istanze database nell'ambiente blu aggiungendo -oldn al nome corrente, dove n è un numero. Il cluster DB viene forzato a passare allo stato di sola lettura. Anche se si disabilita il read_only parametro sul cluster DB, rimane di sola lettura finché non si elimina la distribuzione blu/verde.

Aggiornamento del nodo principale per i consumatori

Dopo aver cambiato una distribuzione blu/verde, se il cluster DB di istanze DB relativo nodo principale dopo il passaggio per mantenere la continuità della replica.

Dopo il passaggio, l'istanza Writer DB che si trovava precedentemente nell'ambiente verde emette un evento che contiene il nome del file di registro principale e la posizione del registro principale. Per esempio:

aws rds describe-events --output json --source-type db-instance --source-identifier db-instance-identifier

{
    "Events": [
...
        {
            "SourceIdentifier": "db-instance-identifier",
            "SourceType": "db-instance",
            "Message": "Binary log coordinates in green environment after switchover:
             file mysql-bin-changelog.000003 and position 804",
            "EventCategories": [],
            "Date": "2023-11-10T01:33:41.911Z",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:db:db-instance-identifier"
        }
    ]
}

Innanzitutto, assicurati che il consumatore o la replica abbiano applicato tutti i log binari del vecchio ambiente blu. Quindi, utilizza le coordinate del registro binario fornite per riprendere l'applicazione sui consumatori. Ad esempio, se stai eseguendo una replica MySQL su EC2, puoi usare il comando: CHANGE MASTER TO

CHANGE MASTER TO MASTER_HOST='{new-writer-endpoint}', MASTER_LOG_FILE='mysql-bin-changelog.000003', MASTER_LOG_POS=804;