amazon ec2 mysql_Amazon RDS for MySQL與在Amazon EC2執行個體上安裝MySQL

我一般都是AWS的忠實粉絲…但是RDS,不是那麼多.

@RolandoMySQLDBA已經指出了一些非常好的反對它.

與EC2上的MySQL相比,我在RDS中看到的唯一優勢是能夠執行點選快照,克隆和時間點恢複,但這些優勢還不足以彌補失去控制和靈活性的問題.大多數人肯定不能證明價格更高. RDS在某些方面很性感,但你不能最終相信你最終無法解決的問題,因為你無法找到所有活動部件.

我不喜歡沒有SUPER特權.我不喜歡無法拖尾錯誤日志.我不喜歡無法在我的資料庫伺服器上運作“top”或“iostat”來檢視核心和驅動器如何享受負載.我不喜歡無法通路聯合存儲引擎.我不喜歡支付熱備用(多AZ)備份主機的想法,我甚至無法将其用作隻讀副本.當然,有完全合理的解釋為什麼所有這些限制都必須到位,以便MySQL成功打包并作為RDBMS-in-a-box出售.唯一的問題是,RDBMS-in-a-box“解決”了我沒有的一系列問題……并且妨礙了我,造成了新的問題.

但對我來說,使用RDS的絕對優勢是完全無法通路二進制日志和複制. Binlogs,特别是基于行的,對于輕微災難來說是一個很棒的恢複工具,但如果你無法通路它們,它們對你沒有任何幫助.想要在辦公室配置内部部署伺服器作為RDS中生産資料庫的隻讀副本嗎？如果您的RDS中的資料發生了不可想象的事情,那麼可以采取本地備份,進行報告,手頭進行災難恢複嗎？這是一個同時顯而易見的想法.

哎呀,抱歉,無法直接通路複制.當然,您可以支付讀取副本…但僅作為其他RDS執行個體.在我的書中不是一個價值主張.

更新：MySQL 5.6的RDS的一個重大變化

我仍然喜歡運作我自己的伺服器(即使在EC2中)而不是運作RDS,原因有很多,包括缺乏對User-Defined Functions的支援,無法使用Federated Storage Engine,以及無法使one extra connection可用于緊急通路. ..但是……

亞馬遜已經在MySQL 5.6 for RDS上做了重大改變,這消除了我的一個主要反對意見 – 也許是我最大的反對意見：現在可以通路二進制日志,你可以将非RDS執行個體作為從屬運作,或者将其他實用程式連接配接到讀取binlog流的伺服器.

正式地說,文檔表明它們正在暴露這個,以便您可以設定一個從站進行實時遷移 – 使用mysqldump從現有RDS執行個體同步外部未來主伺服器,然後将其連接配接到RDS作為slave通過複制流擷取更新的實時源,直到您的應用程式遷移到新主伺服器 – 但非正式地,隻要您不希望它們支援您,您就可以持續執行此操作…對我來說,似乎是合理的.

這是在in a recent Webinar,在56:45左右開始的對話中确認的：

“You can keep it in a replicated state indefinitely…

“…as long as you take the responsibility to maintain the replication…”

“We are not preventing you from doing ongoing replication if that’s what you want.”

這個新功能足以讓我放棄我在面向公衆的網站支援MySQL執行個體中使用RDS的全面反對意見,我們不會使用FEDERATED或其他一些内容.

是以我仍然不贊成它,但我不再反對它,因為擁有二進制日志的實時流使我最終實時控制資料并確定沒有交易的責任在災難性的停電中迷失了我的回歸,因為我作為DBA重新掌控了 – 這正是我想要的.讓第三方供應商指責或提起訴訟或其他任何事情,如果它丢失在黑匣子内的黑洞中,則不會丢失您丢失的資料.

管理層似乎喜歡RDS的“想法”并且不反對成本差異,是以我們現在推出所有新的網站,其中包含RDS.

我承認,點選時間點恢複是RDS中的一個很好的功能…它不會改變或破壞你現有的機器 – 相反,它會啟動一個全新的執行個體,使用備份最接近所選時間點,然後應用必要的binlog以使新機器前進到您指定的時間點.

與此相關,但在另一個方向,現在也可以使用類似的政策将實時MySQL資料庫遷移到RDS …您可以連接配接RDS主機(可能,通常,這将是新部署的執行個體)作為現有系統的從屬裝置,以便RDS執行個體在您遷移到資料時具有實時版本的資料.與通路RDS binlogs進行外向複制(僅适用于5.6)不同,inward replication is supported in RDS以5.5.33和5.6.13開頭.