Mam małą instancję RDS MySQL jako część mojego systemu produkcyjnego i chcę ją zaktualizować do średniej instancji z zapewnionym IOPS.

Jako oldschoolowy DBA wiem o metodzie „dodaj niewolnika; promuj do mistrza; przełącz klientów”, ale AWS obiecuje zapewnić magiczną ścieżkę aktualizacji jednym kliknięciem, tj. „Instancję aktualizacji”, „dodaj pod warunkiem IOPS”.

Próbowałem tego na testowej instancji RDS, przestój jest zbyt długi, IMHO: około 5 minut na małe-> średnie uaktualnienie i 30 minut (!!!) na przejście na dostarczone IOPS.

• Czy to jest normalne zachowanie?
• Czy jest jakiś sposób, aby uruchomić aktualizację produkcyjnego RDS bez przestoju?
• Czy zalecasz sposób „stop; utwórz migawkę; przywróć z migawki do większej instancji”?

Uaktualnienie instancji w RDS oznacza, że ​​RDS będzie fizycznie migrować bazę danych do nowej instancji, prawdopodobnie na innym fizycznym hoście, więc przestoju nie da się uniknąć. Migracja do wyposażonego IOPS prawdopodobnie oznaczałaby migrację danych do nowego woluminu EBS (a serwer może zostać migrowany również do nowej instancji z tą zmianą, w zależności od tego, czy wewnętrznie maszyny zdolne do uzyskiwania dostępu do woluminów EBS z wyposażonym IOPS są fizycznie oddzielone od maszyn, które nie są, aby mogły być na innym sprzęcie sieciowym), aby przestoje były znowu nieuniknione.

Wydaje się, że istnieje sposób na uniknięcie tego zakłócenia: wdrożenie Multi-AZ, które tworzy niewidoczną i niedostępną (dla ciebie) replikę w innej strefie dostępności w regionie.

W przypadku aktualizacji systemu, takich jak łatanie systemu operacyjnego lub skalowanie instancji DB, operacje te są stosowane najpierw w trybie gotowości, przed automatycznym przełączaniem awaryjnym. W rezultacie twój wpływ na dostępność jest ograniczony tylko do czasu wymaganego do zakończenia automatycznego przełączania awaryjnego.

^{- http://aws.amazon.com/rds/multi-az/}

Które powinny zapewnić szybką i bezproblemową migrację, choć nie miałem okazję przetestować tę funkcję. Pojawia się „Modyfikuj” w konsoli, aby umożliwić konwersję instancji na Multi-AZ. Prawdopodobnie spowodowałoby to krótkie zawieszenie We / Wy podczas klonowania instancji, więc oczywiście zaleciłbym przetestowanie całej tej funkcjonalności przed jej wypróbowaniem.

Alternatywnie RDS obsługuje wewnętrzny mechanizm, który powinien umożliwiać emulację operacji „dodaj niewolnika; promuj do mistrza; przełącz klientów”, co powinno także umożliwić konwersję prawie zerowego przestoju:

• Utwórz rzeczywistą replikę do odczytu RDS bazy danych z pożądaną klasą instancji
• Poczekaj, aż replika przejdzie w tryb online i zostanie zsynchronizowana z urządzeniem głównym
• Zmodyfikuj konfigurację repliki, aby dodać Provisioned IOPS
• Poczekaj, aż replika przejdzie w tryb online i zostanie zsynchronizowana z urządzeniem głównym
• Sprawdź, czy oba systemy mają identyczne dane, korzystając z narzędzi innych firm
• Odłącz swoją aplikację od starego wzorca
• Zweryfikuj pasujące współrzędne binlog na master i replice, aby upewnić się, że wszystkie zapisy aplikacji zostały zreplikowane
• Podziel systemy za pomocą „Promuj odczyt repliki” w nowej replice w RDS
• Połącz swoją aplikację z nowym urządzeniem głównym

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

Nawet w środowisku z wieloma serwerami AZ nastąpi przerwa 60–120 lat. Tak było w przypadku wielokrotnego uderzania w nasze instancje RDS podczas aktualizacji PostgreSQL db.m3.medium do db.m3.large.

MOŻLIWE jest również uniknięcie przestojów podczas aktualizacji. Można to zrobić przez krótkie uruchomienie nowego RDS z migawki repliki do odczytu i skonfigurowanie go jako aktywnej / aktywnej replikacji typu Master na Master. Po skonfigurowaniu możesz przełączać ruch aplikacji na jednym serwerze aplikacji naraz, bez żadnych przestojów. Stosujemy to podejście za każdym razem, gdy AWS ogłasza konserwację RDS, aby uniknąć przestojów, a także podczas naszych zaplanowanych konserwacji.

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

Oto szczegóły:

M1 - Mistrz Orignal

R1 - Przeczytaj replikę M1

SNAP1 - Migawka R1

M2 - Nowy mistrz

Sekwencja tworzenia M2: M1 → R1 → SNAP1 → M2

• Ponieważ nie możemy używać uprawnień SUPER na RDS, nie używamy mysqldump z — master_data2opcją na M1. Zamiast tego uruchamiamy R1, aby uzyskać z niego pozycję binlog M1 . Następnie utwórz migawkę (SNAP1) z R1, a następnie uruchom M2 z SNAP1.

• Utwórz dwie oddzielne grupy parametrów RDS z następującymi przesunięciami, aby uniknąć konfliktów PK:

  M1: auto_increment_ increment = 4 and auto_increment_offset = 1

  M2: auto_increment_ increment = 4 and auto_increment_offset = 2

• Utwórz użytkownika replikacji na M1

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

1. Utwórz R1 z 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. Utwórz SNAP1 z R1

• Utwórz M2 z SNAP1 z atrybutami uzyskanymi z M1

• Przypisz grupę parametrów do M2 z innym przesunięciem auto_increment_ od M1, aby uniknąć konfliktów kluczy replikacji M / M

4. Skonfiguruj replikację M / M

-- 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. Usuń R1 i SNAP1, ponieważ nie są już potrzebne

6. Zaktualizuj M2 za pomocą konsoli AWS

Skorzystaj ze standardowej procedury, aby zmodyfikować instancję zgodnie z własnymi potrzebami.

7. Wykonaj płynne przejście na M2

Ponieważ replikacja M / M została pomyślnie skonfigurowana, jesteśmy gotowi kontynuować konserwację DB bez przestojów, z wdziękiem przełączając serwery aplikacji po jednym na raz.

Oto więcej informacji o tym, jak to działa.

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

To by działało, jednak należy upewnić się, że punkty końcowe instancji RDS nie są skonfigurowane w aplikacji jako pozycja statyczna. Zamiana RDS zmieni punkty końcowe.