使用 EBS（Elastic Block Store）和 Elastic Beanstalk 在 Amazon EC2 上執行 MySQL

我是 Elastic Beanstalk 的新手，但我使用執行 PHP 5.3 的 64 位 Amazon Linux 的容器創建了一個環境。我想在 EBS 上設置 MySQL，然後安裝 phpMyAdmin 並導入我的數據庫。

但是，我不知道該怎麼做，因為文件對我不起作用： Running MySQL on Amazon EC2 with EBS (Elastic Block Store)

由於該指南最後一次更新是在 2010 年 3 月 23 日，我想它可能已經過時了。

這是我所做的：

1. 設置 EC2 實例，附加 EBS 卷，通過 ssh 連接到實例，並使用命令“sudo su -”獲得 root 訪問權限（到目前為止一切順利）。
2. 根據指南，我現在應該執行“sudo apt-get update && sudo apt-get upgrade -y”命令，但找不到 apt-get 命令。沒問題，我執行了 yum update 和 yum upgrade 。
3. 同樣，“sudo apt-get install -y xfsprogs mysql-server”也不起作用，所以我執行了“sudo yum install -y xfsprogs mysql-server”並安裝了 MySQL。
4. 該指南說要在 /dev/sdh 上創建一個 XFS 文件系統，但是我的 EBS 卷附加到 /dev/sda1（這是您使用 Elastic Beanstalk 時的預設設置，並且無法更改）並且已經有一個文件系統它（我猜 Elastic Beanstalk 會自動創建一個），所以它不允許我執行“sudo mkfs.xfs /dev/sdh”命令（我將其更改為“sudo mkfs.xfs /dev/sda1”，因為那是我的附卷）。
5. 指南中接下來的 3 個命令似乎已執行（沒有錯誤消息），所以現在我的 EBS 卷安裝為 /ebsvol。但是，我注意到 /ebsvol 在 /ebsvol 中有根目錄結構的副本。但是，/ebsvol/ebsvol 是一個空目錄。在這一點上，我有點擔心，但我繼續。
6. 我使用命令“/sbin/service mysqld stop”停止 MySQL 伺服器，因為指南中的命令 (sudo /etc/init.d/mysql stop) 不起作用。
7. 現在我必須將現有的數據庫文件移動到 EBS 卷並將 MySQL 指向 EBS 卷。這是一場災難，因為 mysql 文件不在指南所說的位置。現在我無法重新啟動 MySQL 伺服器。

幫助！

1. 是否有將 MySQL 配置為在 Elastic Beanstalk 上使用 EBS 卷的更新指南？搜尋 Google、stackoverflow、serverfault 會得到一些 2008/2009 年的指南，因此它們尚未使用 Elastic Beanstalk 進行測試。（編輯：有沒有類似 Eric Hammond 的文件，但是對於 CentOS/RHEL？）
2. 如何撤消所有阻止 MySQL 啟動的安裝綁定？我應該刪除實例和卷並重新開始嗎？
3. 我是否在浪費時間嘗試在 Elastic Beanstalk 上的 EBS 上設置 MySQL？由於缺乏可用資訊，要麼 a) 做起來很簡單，而且不需要指南（因此讓我成為白痴）；或者，b）沒有人在 Elastic Beanstalk 上設置 MySQL，因為它是不必要的/冗餘的（因此我不應該打擾）。

編輯：感謝您的評論和回答。我正在嘗試找出在 AWS 上建立 PHP/MySQL 網站的最佳方式，因此 Elastic Beanstalk 似乎是一個好主意，因為 AWS 將其推銷為“一種更簡單的方式，讓您在 AWS 中快速部署和管理應用程序雲。”

但是，如果您想使用 EBS 執行 MySQL，這似乎並不完全正確。根據我收集到的資訊，我猜每個人都將 RDS 與 Elastic Beanstalk 一起使用，因為它可以自動擴展並且可能具有自動快照功能。

所以我想我剩下這些選擇：

1）不要使用 Elastic Beanstalk：根據 Eric Hammond 文件，設置一個在 EBS 卷上執行 MySQL 的 Ubuntu EC2 實例（聽起來會有一些可擴展性問題？）。

2. 使用 Elastic Beanstalk：在 RDS 上設置我的數據庫（沒有可擴展性問題）。

3. 使用 Elastic Beanstalk：但是使用配置了 MySQL 的 ubuntu AMI 在 EBS 卷上執行（這可能嗎？Elastic Beanstalk 是否可以與私有 AMI 一起使用？）

4. 使用 Elastic Beanstalk：重新開始並使用cyberx86 的關於調整ubuntu 指令以在CentOS/RHL 上工作的指令。

在這一點上，我的數據庫和網站流量非常小。讓它可擴展會很好，但在這一點上，我只想讓它以一種方式執行，讓我在我的程式碼在 localhost 上執行後使用 git 部署新版本。首要任務是讓網站啟動並執行，並重新開始行銷和建構功能，而不是花時間在託管上。我該怎麼辦？

我不使用 Elastic Beanstalk - 但您遵循的指南適用於 EC2（我絕對可以提供幫助）。您遇到的第一個困難是您使用的指南適用於 Ubuntu 9.10；Amazon 的 Linux 基於 CentOS/RHEL - 所以如果你能找到 CentOS 6 指南，你會更輕鬆。

您的問題的根源似乎源於“附加 EBS 卷”。在 EC2 上，您可以將多個 EBS 卷附加到單個實例。所有實例都有一個根卷 - 這些可以是 S3 支持的或 EBS 支持的。到目前為止，首選的方法是使用 EBS 支持的根卷（它的成本稍高，但在靈活性和耐用性方面彌補了這一點）。具有 EBS 根卷的實例幾乎總是將此卷附加為 /dev/sda1 - 在現代 Linux 系統上，該設備實際上顯示為 /dev/xvda1（應該將後者傳遞給任何命令）。（除了試圖格式化一個掛載的捲——你試圖在實例執行的情況下格式化你的根文件系統——即你試圖擦除你的作業系統，這絕對不是一個好主意，如果它甚至可能的話）。

在這種情況下，建議添加第二個 EBS 卷 - 將它附加到您的實例（例如，作為 /dev/sdh，但使用 /dev/xvdh 作為命令），並使用它來儲存您的 MySQL 數據。（儘管沒有使用 Elastic Beanstalk）我很難相信 Elastic Beanstalk 不允許您附加第二個卷 - 因為此功能對於 EC2 來說相當重要。

您應該能夠通過執行cat /proc/partitions（或使用fdisk -l）獲取 EBS 設備列表。

您會注意到，在您所做的第 5 步中，您實際上是在其自身中安裝根卷（即 /dev/sda1 已安裝為 / 並且您將 /dev/sda1 安裝為 /ebsvol） - 最好避免這樣做。

此外，雖然/etc/init.d/mysql stop沒有奏效，但/etc/init.d/mysqld stop可能會奏效。（同樣，您可以通過執行獲得 init.d 腳本的列表ls /etc/init.d- 並且應該能夠像您一樣使用這些路徑，但我通常使用該service命令）。

MySQL 數據庫應該在 /var/lib/mysql - 但是，/etc/fstab 中的掛載點可能不正確（考慮到 /ebsvol 中的 ebsvol 問題）。當您cd /var/lib/mysql應該能夠看到您的數據庫時 - 如果沒有，您的掛載就無法正常工作。（驗證 /var/lib/mysql 是否安裝在不同的設備上，mountpoint -d /var/lib/mysql並將設備與 進行比較cat /proc/partitions）。

您所遵循的指南的基本思想非常有效 - 將數據和數據庫放在與根卷不同的 EBS 卷上是一種常見的做法，因為它提供了許多優勢（性能、易於快照、更容易在實例之間移動等），並且基本的 Linux 命令沒有改變——它們只是用於 Ubuntu。

撤消您的安裝umount /path- 就像您通常所做的一樣，當然，您需要確保設備不忙（如果您沒有設法啟動 MySQL，這可能不是問題）。umount 只是暫時的 - 因此您還必須/etc/fstab從那裡編輯和刪除對安裝點的任何引用。如果您在實例上沒有任何有價值的東西，您可能最好重新開始（不是因為很難解除安裝幾個卷，而是因為當您從頭開始時總是更容易找出哪裡出錯了已知狀態）。

最後，關於 Elastic Beanstalk 上的 MySQL：Elastic Beanstalk 的重點應該是它處理資源的配置和自動擴展——它仍然基於核心 AWS 組件（例如 EC2、S3、ELB 等），但它會為你做一些事情。Elastic Beanstalk 通常使用 RDS 來處理 MySQL 數據庫。RDS 是 MySQL 的 Amazon 託管版本，可簡化 MySQL 實例的配置和擴展。請記住，如果沒有大量設置，MySQL 不適合自動縮放。您不能只啟動第二個 MySQL 實例並在兩個實例之間分配負載 - 您需要設置複製，這可能不是一項簡單的任務）。

從本質上講，如果您能夠設置 MySQL 以使其從您的 Web 伺服器實例執行並且可以無縫自動擴展，那麼您幾乎可以肯定直接使用 EC2 而無需使用 Elastic Beanstalk 會更好。因此，我建議，大多數人實際上並沒有在 Elastic Beanstalk 上設置 MySQL（你可以做的是設置一個單獨的 MySQL 實例，但如果你使用的是 Beanstalk，RDS 可能是一種更簡單的方法）。

---

編輯：

與主要作為黑盒執行的許多其他服務不同，Elastic Beanstalk 確實讓您可以訪問底層組件。也就是說，如果您打算手動設置 EC2 實例，那麼您就否定了 Elastic Beanstalk 的觀點。

如果您使用的是 EC2，PHP/MySQL 的方法很少：

1. 您可以在一個實例上同時託管您的網路伺服器和數據庫 - 當您剛開始時，這可能是一種合理的方法，但是，它不能很好地水平擴展（但您仍然可以垂直擴展 - 使用更大的實例）。希望當您超過 x-large 實例的容量時，您將能夠設置更複雜的設置。也就是說，這對冗餘是不利的——一切都在一個實例上，任何組件的故障都會破壞你的整個設置。
2. 您可以在一個實例上託管您的網路伺服器，並將 RDS 用於您的數據庫。大多數設計良好的應用程序對 Web 伺服器的負擔比對數據庫的負擔更大（理想情況下，數據庫負載會偏讀）。在這種情況下，您可以相對輕鬆地擴展您的 Web 伺服器實例（例如，通過將它們放在 ELB 後面 - 只需稍作努力即可確保所有實例都提供相同的內容）。RDS 是由 AWS 管理的 MySQL——它不是完全自動化的，但它在自動擴展方面確實有很長的路要走。從本質上講，RDS 將提供多個只讀從屬設備和一個寫入主控設備，以及多個熱備份，如果您需要，可以接管。缺點是您要為所有正在執行的實例付費（並且您無法完全控制 MySQL 的某些複雜設置）。
3. 最後一種方法是使用您的 Web 伺服器集群和您自己的 MySQL 集群。本質上，您可以擴展您的 Web 實例（如上所述），然後您將設置單獨擴展的 MySQL 實例。您將需要研究 MySQL 複製（或者如果您可以使您的應用程序適應其資料結構，則可能使用 MySQL 集群）。

關於同一主題的其他一些答案：

• RDS 與 EC2
• 部署應用程序
• EC2 擴展的一些方法

我的觀點通常是一鍵式解決方案不是最好的方法——我喜歡手動執行某些操作所提供的控制。我發現，我不僅通常會得到一個更量身定制、更高效的最終結果，而且我對系統的工作原理也有了更好的理解，這使得找出問題所在變得更加容易。一旦您對它們的複雜性有了很好的了解，您就可以始終自動化您自己的設置。

關於 RDS 需要牢記的一點——它已經得到 EBS 的支持。RDS 是 MySQL - 它不是類似的東西，也不是另一個關係數據庫。它是在 EBS 支持的 EC2 實例上執行的 MySQL 託管實例。AWS 將使軟體保持最新，您可以對數據進行正常的 EBS 快照等。您只是無法直接訪問實例上執行的底層軟體。

至於作業系統的選擇，我比較偏愛亞馬遜的Linux。它得到 AWS 的良好支持並使用最少的資源 - 它與 CentOS 完全兼容（事實上，它在最新版本中預設包含 EPEL 儲存庫）。通常的觀點是使用您喜歡的任何 Linux 發行版，因為差異通常很小（CentOS 將與 Ubuntu 一樣工作，因為您正在使用的指令 - 大多數命令（apt-get 除外）在 CentOS 上是相同的. 鑑於我自己的設置在使用 Amazon 的 Linux 的單獨 EBS 卷上具有數據庫，我可以向您保證，這並不難）。

我建議有一些主要考慮因素：

• 熟悉/願意學習 Linux 系統 - 如果您不介意設置自己的伺服器並希望更好地了解它們，我肯定會選擇 EC2 路線。如果你做得對，你最終會得到更好的結果，並且從長遠來看會有更多的多功能性。不過，我會提到，如果您採用這種方法，您想真正了解您正在執行的命令是做什麼的 - 如果您真的想致力於它，僅僅遵循指南是不夠的。
• 預算 - 請記住，使用 AWS，一切都是有代價的。AWS 為您做的越多，他們向您收取的費用就越多。RDS 實例的成本比等效的 EC2 實例高出約 30%（並且沒有微型實例），如果您想要它們提供的冗餘，您需要執行多個 RDS 實例（並為每個實例付費）。Elastic Beanstalk 將為您預置實例、負載均衡器、RDS 實例等 - 成本會迅速增加。
• 時間 - 如果您沒有時間，想要按下幾個按鈕並擁有一些功能，那麼 Elastic Beanstalk 可能是您的最佳選擇。

我建議不要將 Elastic Beanstalk 與 MySQL 結合到您的 AMI 中 - 如果它完全可以工作，它可能會非常不穩定。（想想當它向你的集群添加和刪除一個實例時會發生什麼，或者當數據進入一個實例而不是另一個實例時會發生什麼……）

牢記可擴展性是很好的——但不要過早優化，否則你將永遠無法完成任何事情。一定要牢記這一點，但如果目前使特定組件可擴展的成本（時間、金錢等）不切實際，請不要太擔心——當需要擴展它時，你’我會弄清楚的（畢竟大多數流行的網站都是這樣開始的）。

我建議，如果您的應用程序被設計成可以利用一些記憶體，那麼它將有很長的路要走。

通常，在 EC2 上，垂直擴展（擴展到更大的實例）比水平擴展（擴展到更多實例）更好。但是，首先，您希望擴展到兩個實例，以便擁有一些冗餘並最大限度地減少單點故障。因此，一種可能的方法可能是：

1. 從一個微型實例開始 - 上面有你的數據庫和應用程序（你不能得到比這更小的實例，這使它成為一個很好的起點）。

• 當然，這很容易垂直擴展，只需不斷升級您的實例，直到您使用超大型實例。問題歸結為冗餘 - 如果您的實例有任何問題，您的應用程序將處於離線狀態。

2. 現在，您通常希望將您的數據庫分離到另一個實例（因為 a）數據庫將看到與您的應用程序不同的負載，並且 b）您不能以與 Web 伺服器完全相同的方式自動擴展 MySQL），但是微實例只是不’不能很好地處理負載，所以我建議先升級到一個更大的實例，至少是一個小的，然後也許是一個中等的（基本上，這個想法是，一旦你需要更大的實例類型，效果可能會更大）
3. 將數據庫與 Web 伺服器分開。這將使您能夠滿足數據庫（例如高記憶體）與 Web 伺服器（例如更高的 cpu）的不同需求以及您如何擴展它們之間的差異（推薦閱讀）。此時您可能決定使用 RDS 而不是執行您自己的 MySQL 實例。
4. 現在您的應用程序在專用實例上執行，您可以擴展它而不必擔心您的數據庫 - 設置自動擴展以便您有一些冗餘。當任何一個應用程序節點失敗或負載超過您指定的門檻值時，這應該會自動添加更多應用程序節點。
5. 添加第二個數據庫節點並配置節點之間的複制（如果您選擇使用 MySQL 集群或 NoSQL 解決方案，您也應該能夠設置自動縮放）。此時一切都應該有冗餘，即使一個節點發生故障，你也應該仍然線上。
6. 根據需要，一次將一個實例升級到更大的實例大小。

引用自：https://serverfault.com/questions/384103