Magento升級流程和基礎設施以儘可能縮短停機時間

Question

我有一位客戶，他當前擁有Magento的一臺服務器，他的admin將整個站點關閉了多個小時的更新。我想，使其瞬間的過程，讓我想建議他如何應該已經設置了新的解決方案：

• Magento的生產服務器1（WEB + DB）
• Magento的生產服務器2（WEB + DB）
• Magento的開發服務器1

DB將不得不被那些2個服務器之間以某種方式同步（集羣？複製？）和我在想，是最小的停機時間可能先更新應該在開發測試服務器（在升級之前從生產服務器同步的DB/WEB）和後檢查它工作正常，並知道過程看起來像我會禁用LoadBalancing或RoundRobin DNS到服務器1，然後做服務器2上的升級/更新，然後切換到服務器2作爲生產服務器和更新服務器1.當兩者都完成後打開LoadBalancing/Round Robin。

我來自Windows環境，所以這是我如何做到這一點在Windows上（也許與單獨的數據庫和Web也）和像RedGate SqlCompare/Sql數據比較等工具應該工作。

但我不知道的Magento在所有所以請讓我知道什麼是可能的，也許這個應該怎麼做，如果客戶不想與他的店是下降到結束......

Answer 1

你肯定會需要一個生產服務器，以及某種階段/版本管理系統。 我建議檢查版本管理的Subversion或Git。 可以首先將更改提交到存儲庫，然後更新到實時站點，而不會停機。這對於開發環境來說綽綽有餘。

對於更大的更改，如Magento版本升級，您可能仍然希望/需要在半夜將網站關閉幾個小時，因爲這是一個更大的過程。

至於多臺服務器，作爲一個例子，我運行負載平衡器，它在主服務器和輔助服務器之間進行平衡。有一個數據庫服務器是分開的。對使用Subversion提交給主服務器的開發服務器進行了更改，然後主服務器和輔助服務器之間的任何更改每隔60秒對輔助服務器進行rsynced。

對於此解決方案，會話和緩存數據存儲在數據庫中。

Answer 2

恕我直言，擁有良好的託管環境，除非你真的在成千上萬的同時訪問者，你不需要多臺服務器。插件是管理員相關問題的常見原因。

我們在「雲」環境中取得了巨大成功。實例化一個新的雲實例，獲取該IP，然後在你的「主機」文件中，指向像dev.yourdomain.com這樣的東西進行測試。唯一真正的停機時間是，當數據庫轉換爲新版本（可能需要幾個小時）時，應凍結生產站點。我們的mySql數據庫備份是3 GB左右，但謝天謝地的下降到280 MB。

我們使用nginx和php-fpm，它們很快就會變得很淫穢。我

典型的遷移路徑：

1. 備份生產現場
2. 開始新的雲實例和複製生產現場開發站點 （恢復生產數據庫）
3. 嘗試升級開發站點一個在步驟時間看什麼中斷
4. 啓動新的雲實例並完全安裝最新的 magento版本
5. onc E使用，恢復生產數據庫，看着已經被榨乾上 轉換它，看看有什麼突破升級還是全新之間
6. 挑安裝
7. 備份生產MYSQL，把生產現場維護模式 而開發站點轉換數據庫
8. 將域名轉換爲新的IP地址