Ben genel olarak büyük bir AWS hayranıyım ... ama RDS, çok değil.
@RolandoMySQLDBA, buna karşı oldukça iyi noktalar olduğuna dikkat çekti.
RDS'de EC2'deki MySQL'e kıyasla gördüğüm tek avantaj, anlık görüntüleri, klonları ve zaman içinde kurtarma işlemlerini gösterme ve tıklatma yeteneğidir, ancak bunlar kontrol ve esneklik kaybını telafi etmek için yeterli değildir ve bunlar kesinlikle fiyatın daha yüksek olmasını haklı çıkarmayın. RDS bazı yönlerden seksidir, fakat nihayetinde düzeltemeyeceğiniz şeye güvenemezsiniz, çünkü tüm hareketli parçalara erişemezsiniz.
SUPERAyrıcalıktan hoşlanmıyorum . Hata günlüğünü yerleştirememekten hoşlanmıyorum. Çekirdeklerin ve sürücülerin yükten nasıl zevk aldığını görmek için veritabanı sunucumda "top" veya "iostat" komutunu çalıştırmayı sevmem. Federal depolama motoruna erişememekten hoşlanmıyorum. Sıcak bir standyby (multi-AZ) yedek ana makine için bir okuma kopyası olarak bile kaldıramadığım bir ödeme yapma fikrini sevmiyorum. Elbette, MySQL'in başarılı bir şekilde paketlenmesi ve bir kutuda RDBMS olarak satılması için tüm bu kısıtlamaların neden olması gerektiğine dair makul makul açıklamalar var. Tek şey şu; RDBMS bir kutuda sahip olmadığım bir dizi problemi “çözüyor” ... ve yoluma giriyor ve yeni sorunlara yol açıyor.
Ancak, RDS ile benim için mutlak anlaşma kırıcı ikili günlükleri ve çoğaltma için tam erişim eksikliği. Özellikle satır tabanlı olan Binloglar, küçük felaketler için harika bir kurtarma aracıdır, ancak bunlara erişemiyorsanız size yardımcı olmaz. Ofisinizde bir şirket içi sunucuyu, RDS'deki üretim veritabanınızın bir kopyası olarak yapılandırmak ister misiniz? Yerel yedeklemeler alacak bir şey, raporlama yapmak, felaket kurtarma için elinizde bulundurulması gereken bir şey var mı? Bu aynı anda açık ve mükemmel bir fikir.
Hata! Üzgünüz, çoğaltma işlemine doğrudan erişilemiyor. Tabii ki, okuma kopyaları için ödeme yapabilirsiniz ... ancak yalnızca diğer RDS örnekleri için. Kitabımda bir değer teklifi değil.
Güncelleme: MySQL 5.6 için RDS'de Bir Önemli Değişiklik
Hala, bir takım nedenlerden ötürü için RDS çalıştırmak için destek eksikliği de dahil olmak üzere karşıt olarak (hatta EC2) kendi sunucusunu çalıştıran tercih Kullanıcı Tanımlı Fonksiyonlar , kullanımı yetersizlik Federe Depolama Engine ve yetersizlik olması birini Acil erişim için ekstra bağlantı mevcut ... ancak ...
Amazon, benim büyük itirazlarımdan birini ortadan kaldıran RDS için MySQL 5.6’da önemli bir değişiklik yaptı - belki de en büyük itirazım: ikili günlükler artık erişilebilir durumda ve RDS’li olmayan bir örneği köle olarak çalıştırabilir veya diğer yardımcı programları binlog akışını okuyan sunucu.
http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/MySQL.Procedural.Exporting.NonRDSRepl.html
Resmi olarak, belgeler canlı yayını gerçekleştirme amacıyla bir köle ayarlayabilmeniz için bunu açığa çıkardıklarını gösterir - yabancı geleceğin ana sunucusunu varolan RDS örneğinden eşzamanlı hale getirir mysqldump, sonra onu köle olarak RDS'ye bağlarsınız Başvurunuz yeni yöneticiye aktarılıncaya kadar çoğaltma akışı aracılığıyla canlı bir güncelleme yayını almak için - ancak gayri resmi olarak, sizi desteklemelerini beklemediğiniz sürece bunu sürekli olarak yapabilirsiniz ... bana göre makul görünüyor.
Bu, yeni bir Web Semineri'nde , yaklaşık 56:45'te başlayan bir konuşmada onaylandı:
“Süresiz çoğaltılmış bir durumda tutabilirsiniz ...
“... çoğaltmayı sürdürme sorumluluğunu üstlendiğin sürece ...”
“İstediğin buysa, devam eden çoğaltmayı yapmanı engellemiyoruz.”
Bu yeni özellik, benim karşı karşıya olduğum Web sitesi destekli MySQL örneklerimizde, bizim kullanmadığımız FEDERATEDya da bazı şeyleri çok fazla ya da hiç kullanmadıkça, RDS'i kullanmaya yönelik battaniye itirazımı bırakmam için yeterliydi .
Bu yüzden hala onun lehine değilim, ancak artık buna karşı değilim, çünkü ikili kütüklerin canlı yayınına sahip olmak beni gerçek zamanlı olarak verilerin kontrolüne ve işlemlerin olmamasını sağlama sorumluluğuna sokuyor. felaketle sonuçlanan bir kesintide benimle geri döndüm, çünkü ben, DBA olarak kontrole geri döndüm - tam olarak istediğim gibi. Bir üçüncü taraf satıcının parmakları işaret etmesi veya dava açması veya neye karşı dava açması, kara bir kutu içindeki bir kara delikten kaybolursa kaybolan verilerinizi geri almaz.
Yönetim, RDS’nin “fikri” gibi gözüküyor ve maliyet farkına itiraz etmiyor, bu nedenle artık tüm yeni web sitelerini RDS’nin ardında başlatıyoruz.
İşaretle ve tıkla ve anında kurtar, kabul ediyorum, RDS’de hoş bir özellik ... var olan makinenizi değiştirmiyor ya da bozmuyor - bunun yerine, tamamen yeni bir örneği çalıştırıyor, yedeklemeyi kullanarak zaman içinde seçilen noktaya en yakın zamandır ve daha sonra bu yeni makineyi belirttiğiniz zaman noktasına getirmek için gerekli binlogları uygular.
Bununla ilgili, ancak diğer yönde, şimdi, canlı bir MySQL veritabanını RDS'ye geçirmek için benzer bir strateji kullanmak da mümkün ... bir RDS yöneticisini bağlayabilirsiniz (muhtemelen, bu genellikle yeni dağıtılmış olur) örneğin) mevcut bir sistemin kölesi olarak, RDS örneği, içine taşıdığınız anda verinin canlı sürümüne sahip olacak. Yalnızca 5.6'da çalışan dışa doğru çoğaltma için RDS binloglarına erişimin aksine, içe doğru çoğaltma 5.5.33 ve 5.6.13 ile başlayan RDS'de desteklenir .