Üretim sistemimin bir parçası olarak MySQL small RDS örneğine sahibim ve sağlanan IOPS ile birlikte orta dereceye yükseltmek istiyorum.

Eski okul DBA'sı olarak "slave ekle; ustaya tanıt; istemcileri değiştir" yönteminin farkındayım, ancak AWS sihirli tek tıklamayla yükseltme yolu, yani "yükseltme örneği", "sağlanan IOPS ekle" sözü veriyor.

Test RDS örneğinde bunu denedi, aksama süresi çok uzun, IMHO: küçük -> orta seviye yükseltme için yaklaşık 5 dakika ve sağlanan IOPS'ye geçiş için 30 dakika (!!!).

• Bu normal davranış mı?
• Arıza süresi olmayan üretim RDS'sinde yükseltme yapmanın bir yolu var mı?
• "Dur; anlık görüntü oluştur; anlık görüntüden daha büyük örneğe geri yükle" yöntemini tavsiye ediyor musunuz?

Bir örneği RDS'de yükseltmek, RDS'nin veritabanını fiziksel olarak yeni bir örneğe, muhtemelen farklı bir fiziksel ana bilgisayarda geçireceği anlamına gelir, bu nedenle aksaklık süresi önlenemez. Hazırlanan IOPS’ye geçiş yapmak, verilerinizin yeni bir EBS birimine geçirileceği anlamına gelir (ve sunucu, sağlanan IOPS ile EBS birimlerine erişebilecek makinelerin içeride olmasına bağlı olarak, bu değişikliğin yanı sıra yeni bir örneğe de geçirilebilir. fiziksel olarak değil, farklı bir ağ donanımı sınıfında olabilmeleri için olmayan makinelerden ayrıldılar) bu nedenle aksama süresi yine kaçınılmaz olacaktır.

Bu aksaklığı önlemenin bir yolu var gibi görünüyor: Bölgedeki başka bir uygunluk bölgesinde görünmez ve erişilemez (sizin için) bir çoğaltma yaratan Multi-AZ dağıtım.

İşletim sistemi düzeltme eki veya DB Örnek ölçeklemesi gibi sistem yükseltmeleri durumunda, bu işlemler otomatik yük devretmeden önce önce bekleme modunda uygulanır. Sonuç olarak, kullanılabilirlik etkiniz yalnızca otomatik yük devretme işleminin tamamlanması için gereken süre ile sınırlıdır.

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

Yani gerektiğini ben bu yeteneği test etmek için fırsat olmadı gerçi, hızlı ve sorunsuz geçiş yolu sağlar. Konsolda "Değiştir", bir örneği Multi-AZ'e dönüştürmenize izin veriyor. Muhtemelen, bu, örnek klonlanırken kısa bir G / Ç donmasına neden olur, bu yüzden elbette denemeden önce tüm bu işlevleri test etmenizi öneririm.

Alternatif olarak, RDS, "köle ekle; master'ı tanıt; istemcileri değiştir" işlemini taklit etmene izin vermesi gereken iç mekanizmayı da destekliyor ve bu da sıfıra yakın bir duruş süresine ulaşmanızı sağlıyor:

• İstediğiniz örnek sınıfıyla veritabanınızın gerçek bir RDS okuma kopyasını oluşturun
• Çoğaltmanın çevrimiçi olmasını ve ana ile senkronize edilmesini bekleyin
• Hazırlanmış IOPS eklemek için çoğaltmanın yapılandırmasını değiştirin
• Çoğaltmanın çevrimiçi olmasını ve ana ile senkronize edilmesini bekleyin
• Her iki sistemin de 3. taraf araçlarını kullanarak aynı verilere sahip olduğunu doğrulayın.
• Uygulamanızı eski ustadan ayırın
• Tüm uygulama yazarlarının çoğaltıldığından emin olmak için ana ve çoğaltmada eşleşen binlog koordinatlarını doğrulayın
• Sistemleri RDS'deki yeni kopyada "Read Replica Promote" ile böl
• Uygulamanızı yeni yöneticiye bağlayın

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

Multi-AZ ortamlarında bile, 60-120s kesinti yaşarsınız. Bir PostgreSQL db.m3.medium'den bir db.m3.large'ye yükseltme yaparken RDS örneklerine tekrar tekrar basmam gerekti.

Ayrıca yükseltme sırasında herhangi bir aksama süresinin önüne geçmek olasıdır. Bunu yapmanın yolu, okunan bir çoğaltma görüntüsünden yeni bir RDS'yi kısaca başlatmak ve onu etkin / etkin Master'dan Master'a çoğaltma olarak yapılandırmaktır. Yapılandırıldıktan sonra, uygulama trafiğini herhangi bir kesinti olmadan bir APP sunucusundan değiştirebilirsiniz. Bu yaklaşımı AWS her zaman kesinti süresinden kaçınmak için planlı bakımlarımız sırasında RDS bakımları açıkladığında kullanırız.

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

İşte detaylar:

M1 - Orignal Master

R1 - M1'in Çoğaltmasını Oku

SNAP1 - R1'in anlık görüntüsü

M2 - Yeni Usta

M2 oluşturma sırası: M1 → R1 → SNAP1 → M2

• RDS'de SÜPER ayrıcalık kullanamadığımızdan — master_data2, M1'deki mysqldump seçeneğini kullanmayız . Bunun yerine, M1'in binlog pozisyonunu elde etmek için R1'i başlattık . Sonra R1'den bir anlık görüntü (SNAP1) oluşturun ve ardından SNAP1'den M2'yi başlatın.

• PK çakışmalarını önlemek için iki ayrı RDS parametre grubu oluşturun:

  M1: auto_increment_ increment = 4 and auto_increment_offset = 1

  M2: auto_increment_ increment = 4 and auto_increment_offset = 2

• M1'de çoğaltma kullanıcısı oluştur

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

1. M1'den R1 oluşturun

-- 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. R1'den SNAP1 oluşturun

• M1'den elde edilen özniteliklere sahip SNAP1'den M2 oluşturma

• M / M çoğaltma anahtarı çakışmalarını önlemek için M1'den farklı bir auto_increment_ offset ile M2'ye bir parametre grubu atayın

4. Kurulum M / M çoğaltması

-- 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. Artık gerekmedikleri için R1 ve SNAP1'i silin

6. AWS Konsolu ile M2 Yükseltme

Eşgörünümü gereksinimlerinize göre değiştirmek için standart prosedürü kullanın.

7. M2'ye Zarif Geçiş Yap

M / M çoğaltması başarıyla ayarlandığı için, uygulama sunucularını bir kerede zarafetle değiştirerek DB bakım işlemine kesinti olmadan devam etmeye hazırız.

İşte nasıl çalıştığıyla ilgili daha fazla ayrıntı.

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

Bu işe yarar, ancak uygulamanızda RDS örneğinin uç noktalarının statik bir giriş olarak yapılandırılmadığından emin olmalısınız. Değişken RDS uç noktaları değiştirecektir.