Saya memiliki instance MySQL RDS kecil sebagai bagian dari sistem produksi saya dan saya ingin memutakhirkannya ke instance sedang dengan IOPS yang disediakan.

Sebagai DBA jadul, saya sadar tentang metode "tambahkan budak; promosikan untuk menjadi master; beralih klien", tetapi AWS berjanji untuk menyediakan jalur peningkatan satu klik ajaib, yaitu "contoh instal", "tambahkan IOPS yang disediakan".

Mencoba ini pada contoh uji RDS, downtime terlalu lama, IMHO: sekitar 5 menit untuk upgrade kecil-> sedang, dan 30 menit (!!!) untuk beralih ke IOPS yang disediakan.

• Apakah ini perilaku normal?
• Apakah ada cara untuk menjalankan peningkatan pada RDS produksi tanpa downtime?
• Apakah Anda merekomendasikan cara "berhenti; buat snapshot; pulihkan dari snapshot ke instance lebih besar"?

Memutakhirkan sebuah instance dalam RDS berarti RDS akan secara fisik memigrasi basis data ke instance baru, kemungkinan pada host fisik yang berbeda, sehingga waktu henti tidak akan dapat dihindari. Bermigrasi ke IOPS yang disediakan kemungkinan berarti data Anda akan dimigrasi ke volume EBS baru (dan server mungkin dimigrasi ke instance baru juga dengan perubahan ini, tergantung pada apakah, secara internal, mesin yang mampu mengakses volume EBS dengan IOPS yang disediakan adalah secara fisik dipisahkan dari mesin yang tidak, sehingga mereka dapat berada pada kelas yang berbeda dari perangkat keras jaringan) sehingga waktu henti tidak akan terhindarkan lagi.

Tampaknya ada cara untuk menghindari gangguan ini: penyebaran Multi-AZ, yang membuat replika yang tidak terlihat dan tidak dapat diakses (untuk Anda) di zona ketersediaan lain di kawasan tersebut.

Dalam hal peningkatan sistem seperti penambalan OS atau penskalaan DB Instance, operasi ini diterapkan terlebih dahulu pada siaga, sebelum kegagalan otomatis. Akibatnya, dampak ketersediaan Anda hanya terbatas pada waktu yang diperlukan untuk menyelesaikan kegagalan otomatis.

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

Itu seharusnya memberikan jalur migrasi yang cepat dan mulus, meskipun saya belum sempat menguji kemampuan ini. "Modify" di konsol muncul untuk memungkinkan Anda mengonversi instance ke Multi-AZ. Agaknya, ini akan menghasilkan pembekuan I / O singkat ketika instance dikloning, jadi saya tentu saja akan merekomendasikan pengujian semua fungsi ini sebelum mencobanya.

Bergantian, RDS mendukung mekanisme internal yang memungkinkan Anda untuk meniru operasi "tambahkan budak; promosikan untuk menjadi master; beralih klien", dan ini juga akan memungkinkan Anda untuk mencapai konversi down-zero-down-time:

• Buat replika baca RDS aktual dari database Anda dengan kelas instance yang diinginkan
• Tunggu replika datang online dan disinkronkan dengan master
• Ubah konfigurasi replika untuk menambahkan Provisi IOPS
• Tunggu replika datang online dan disinkronkan dengan master
• Verifikasi bahwa kedua sistem memiliki data yang identik menggunakan alat pihak ke-3
• Putuskan sambungan aplikasi Anda dari master lama
• Verifikasi koordinat binlog yang cocok pada master dan replika untuk memastikan bahwa semua penulisan aplikasi telah direplikasi
• Membagi sistem dengan "Promote Read Replica" pada replika baru di RDS
• Hubungkan aplikasi Anda ke master baru

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

Bahkan dengan lingkungan multi-AZ, Anda akan mengalami pemadaman 60-120 - an. Ini adalah kasus ketika saya berulang kali menekan instance RDS kami sambil melakukan peningkatan dari PostgreSQL db.m3.medium ke db.m3.large.

Ini juga MUNGKIN untuk menghindari downtime selama upgrade. Cara untuk melakukannya adalah dengan meluncurkan RDS baru dari snapshot replika baca dan mengkonfigurasinya sebagai replikasi Master ke Master yang aktif / aktif. Setelah dikonfigurasi, Anda dapat mengalihkan lalu lintas aplikasi satu server aplikasi pada saat itu tanpa downtime. Kami menggunakan pendekatan ini setiap kali AWS mengumumkan pemeliharaan RDS untuk menghindari waktu henti serta selama perawatan terjadwal kami.

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

Berikut detailnya:

M1 - Master Orignal

R1 - Baca Replika M1

SNAP1 - Cuplikan dari R1

M2 - Master Baru

Urutan pembuatan M2: M1 → R1 → SNAP1 → M2

• Karena kami tidak dapat menggunakan hak istimewa SUPER pada RDS, kami tidak menggunakan — master_data2opsi mysqldump pada M1. Sebagai gantinya, kami meluncurkan R1 untuk mendapatkan posisi binlog dari M1 darinya. Kemudian buat snapshot (SNAP1) dari R1 dan kemudian jalankan M2 dari SNAP1.

• Buat dua grup parameter RDS terpisah dengan offset berikut untuk menghindari konflik PK:

  M1: auto_increment_ increment = 4 and auto_increment_offset = 1

  M2: auto_increment_ increment = 4 and auto_increment_offset = 2

• Buat pengguna replikasi di M1

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

1. Buat R1 dari 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. Buat SNAP1 dari R1

• Buat M2 dari SNAP1 dengan atribut yang diperoleh dari M1

• Tetapkan grup parameter ke M2 dengan offset auto_increment_ berbeda dari M1 untuk menghindari konflik kunci replikasi M / M

4. Atur replikasi 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. Hapus R1 dan SNAP1 karena tidak lagi diperlukan

6. Tingkatkan M2 melalui Konsol AWS

Gunakan prosedur standar untuk Memodifikasi Mesin Virtual sesuai kebutuhan Anda.

7. Lakukan Graceful Switchover ke M2

Karena replikasi M / M berhasil diatur, kami siap untuk melanjutkan dengan pemeliharaan DB tanpa downtime dengan beralih dari server aplikasi satu per satu.

Berikut ini rincian lebih lanjut tentang cara kerjanya.

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

Ini akan berhasil, namun Anda harus memastikan bahwa titik akhir instance RDS tidak dikonfigurasi dalam aplikasi Anda sebagai entri statis. Bertukar RDS akan mengubah titik akhir.