it-swarm.com.de

Was ist der optimale Weg, um eine Produktions-RDS-Instanz zu aktualisieren?

Ich habe eine kleine MySQL-RDS-Instanz als Teil meines Produktionssystems und möchte sie mit dem bereitgestellten IOPS auf eine mittlere Instanz aktualisieren.

Als DBA der alten Schule ist mir die Methode "Slave hinzufügen; zum Master hochstufen; Clients wechseln" bekannt, aber AWS verspricht, einen magischen Ein-Klick-Upgrade-Pfad bereitzustellen, d. H. "Upgrade-Instanz", "Bereitgestelltes IOPS hinzufügen".

Versucht dies auf Test-RDS-Instanz, Ausfallzeit ist zu lang, IMHO: ca. 5 Minuten für kleine-> mittlere Upgrades und 30 Minuten (!!!) für den Wechsel zu bereitgestellten IOPS.

  • Ist das normal?
  • Gibt es eine Möglichkeit, ein Upgrade für Produktions-RDS ohne Ausfallzeiten durchzuführen?
  • Empfehlen Sie "Stop; Erstellen eines Snapshots; Wiederherstellen vom Snapshot auf eine größere Instanz"?
35
Vitaly

Ein Upgrade einer Instanz in RDS bedeutet, dass RDS die Datenbank physisch auf eine neue Instanz migriert, wahrscheinlich auf einem anderen physischen Host, sodass Ausfallzeiten nicht vermeidbar sind. Eine Migration auf bereitgestelltes IOPS würde wahrscheinlich bedeuten, dass Ihre Daten auf ein neues EBS-Volume migriert werden (und der Server könnte mit dieser Änderung auch auf eine neue Instanz migriert werden, je nachdem, ob intern Maschinen vorhanden sind, die mit bereitgestelltem IOPS auf EBS-Volumes zugreifen können physisch von Computern getrennt, die dies nicht sind, so dass sie sich auf einer anderen Klasse von Netzwerkhardware befinden können), sodass Ausfallzeiten erneut unvermeidlich wären.

Es scheint einen Weg zu geben, diese Störung zu vermeiden: eine Multi-AZ-Bereitstellung, die ein unsichtbares und für Sie unzugängliches Replikat in einer anderen Verfügbarkeitszone innerhalb der Region erstellt.

Bei System-Upgrades wie Betriebssystem-Patches oder DB-Instanz-Skalierung werden diese Vorgänge vor dem automatischen Failover zuerst im Standby-Modus angewendet. Infolgedessen ist Ihre Auswirkung auf die Verfügbarkeit nur auf die Zeit begrenzt, die für den Abschluss des automatischen Failovers erforderlich ist.

- http://aws.Amazon.com/rds/multi-az/

Das sollte einen schnellen und nahtlosen Migrationspfad bieten, obwohl ich keine Gelegenheit hatte, diese Fähigkeit zu testen. "Ändern" in der Konsole wird angezeigt, damit Sie eine Instanz in Multi-AZ konvertieren können. Vermutlich würde dies zu einem kurzen Einfrieren der E/A führen, wenn die Instanz geklont wird. Daher würde ich natürlich empfehlen, alle diese Funktionen zu testen, bevor Sie sie ausprobieren.

Alternativ unterstützt RDS einen internen Mechanismus, mit dem Sie den Vorgang "Slave hinzufügen, zum Master hochstufen, Clients wechseln" emulieren können. Auf diese Weise können Sie auch eine Ausfallzeitkonvertierung nahe Null erzielen:

  • Erstellen Sie ein tatsächliches RDS-Lesereplikat Ihrer Datenbank mit der gewünschten Instanzklasse
  • Warten Sie, bis das Replikat online geschaltet und mit dem Master synchronisiert wurde
  • Ändern Sie die Konfiguration des Replikats, um Provisioned IOPS hinzuzufügen
  • Warten Sie, bis das Replikat online geschaltet und mit dem Master synchronisiert wurde
  • Stellen Sie mithilfe von Tools von Drittanbietern sicher, dass beide Systeme über identische Daten verfügen
  • Trennen Sie Ihre Anwendung vom alten Master
  • Überprüfen Sie die übereinstimmenden Binlog-Koordinaten auf Master und Replikat, um sicherzustellen, dass alle Anwendungsschreibvorgänge repliziert wurden
  • Teilen Sie die Systeme mit "Promote Read Replica" auf dem neuen Replikat in RDS auf
  • Verbinden Sie Ihre Anwendung mit dem neuen Master

http://aws.Amazon.com/about-aws/whats-new/2012/10/11/Amazon-rds-mysql-rr-promotion/

38

Selbst in einer Multi-AZ-Umgebung tritt ein Ausfall von 60-120 auf. Dies war der Fall, als ich während eines Upgrades wiederholt auf unsere RDS-Instanzen traf von einem PostgreSQL-db.m3.medium zu einem db.m3.large.

4
Wayn E

Es ist auch MÖGLICH, Ausfallzeiten während des Upgrades zu vermeiden. Sie können dies tun, indem Sie kurz ein neues RDS aus einem Lesereplikat-Snapshot starten und konfigurieren als Aktiv/Aktiv-Master-zu-Master-Replikation. Sobald es konfiguriert ist, können Sie den Anwendungsverkehr jeweils um einen APP-Server ohne Ausfallzeiten umschalten. Wir verwenden diesen Ansatz jedes Mal, wenn AWS RDS-Wartungsarbeiten ankündigt, um Ausfallzeiten sowie während unserer geplanten Wartungsarbeiten zu vermeiden.

https://workmarket.tech/zero-downtime-maintenances-on-mysql-rds-ba13b51103c2

Hier sind die Details:

M1 - Orignal Master

R1 - Replik des M1 lesen

SNAP1 - Momentaufnahme des R1

M2 - Neuer Meister

M2-Erstellungssequenz: M1 → R1 → SNAP1 → M2

  • Da wir das SUPER-Privileg für RDS nicht verwenden können, verwenden wir mysqldump nicht mit — master_data2 Option auf dem M1. Stattdessen starten wir R1, um die Binlog-Position des M1 daraus zu erhalten. Erstellen Sie dann einen Snapshot (SNAP1) vom R1 und starten Sie M2 vom SNAP1.

  • Erstellen Sie zwei separate RDS-Parametergruppen mit den folgenden Offsets, um PK-Konflikte zu vermeiden:

    M1: auto_increment_ increment = 4 and auto_increment_offset = 1

    M2: auto_increment_ increment = 4 and auto_increment_offset = 2

  • Erstellen Sie einen Replikationsbenutzer auf M1

    GRANT EXECUTE, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO ‘repl’@’%’ IDENTIFIED BY PASSWORD <secret>;

1. Erstellen Sie R1 aus M1

-- Connect to the R1 and stop replication
   CALL mysql.rds_stop_replication;
-- Obtain M1’s (!!) current binlog file and position 
        `mysql> show slave status\G
             Master_Log_File: mysql-bin.000622
             Exec_Master_Log_Pos: 9135555

2. Erstellen Sie SNAP1 aus R1

  • Erstellen Sie M2 aus dem SNAP1 mit den von M1 erhaltenen Attributen

  • Weisen Sie M2 eine Parametergruppe mit einem anderen Versatz von auto_increment_ als M1 zu, um Konflikte zwischen M/M-Replikationsschlüsseln zu vermeiden

4. M/M-Replikation einrichten

-- Configure M2 as a slave of M1
CALL mysql.rds_set_external_master ('m1.xyxy24.us-east-1.rds.amazonaws.com', 3306, 'repl', 'mypassword', 'mysql-bin.000622', 9135555, 0);
CALL mysql.rds_start_replication;
-- Connect to M2 and obtain its current binlog file and position
         mysql> show master status\G
            File: mysql-bin.004444
            Position: 6666622
-- Connect to M1 and configure it to be a slave of the M2
CALL mysql.rds_set_external_master ('m2.xyxy24.us-east-1.rds.amazonaws.com', 3306 , 'repl', 'mypassword', 'mysql-bin.004444', 6666622, 0);
CALL mysql.rds_start_replication;

5. Löschen Sie R1 und SNAP1, da sie nicht mehr benötigt werden

6. Aktualisieren Sie M2 über die AWS-Konsole

Verwenden Sie das Standardverfahren, um die Instanz gemäß Ihren Anforderungen zu ändern.

7. Führen Sie eine ordnungsgemäße Umschaltung auf M2 durch

Da die M/M-Replikation erfolgreich eingerichtet wurde, können wir die DB-Wartung ohne Ausfallzeiten fortsetzen, indem wir die App-Server einzeln ordnungsgemäß wechseln.

Hier finden Sie weitere Details zur Funktionsweise.

https://workmarket.tech/zero-downtime-maintenances-on-mysql-rds-ba13b51103c2

3

Dies würde funktionieren, Sie müssen jedoch sicherstellen, dass die Endpunkte der RDS-Instanz in Ihrer Anwendung nicht als statischer Eintrag konfiguriert sind. Durch das Austauschen von RDS werden die Endpunkte geändert.

1
Anup Singh