[[254518]]

這篇文章介紹了英國《衛報Guardian》為什么和如何從Mongo遷移到Postgres，英國衛報大部分內容 - 包括文章，實時博客，畫廊和視頻內容 - 都是內部CMS工具Composer中制作的。直到最近一直得到了在AWS上運行的Mongo DB數據庫的支持。這個Mongo DB數據庫是Guardian所有在線發布內容的“真實來源” - 大約230萬內容項。

當初為了遷移到AWS，決定購買OpsManager- Mongo的數據庫管理軟件，使用OpsManager來管理備份，處理編排并為我們的數據庫集群提供監控。

因為Mongo沒有提供任何工具來輕松在AWS上進行設置 - 我們需要手工編寫cloudformation來定義所有基礎架構，最重要的是我們編寫了數百行ruby腳本來處理安裝監視/自動化代理和新數據庫實例的編排。

自從遷移到AWS 以來，由于Mongo DB數據庫問題，我們發生了兩次嚴重的中斷，每次在theguardian.com上被阻止發布內容至少一個小時。在這兩種情況下，OpsManager和Mongo的支持服務人員都沒有能夠幫助我們，我們最終解決了這個問題 ：

• 時鐘非常重要 - 不要將VPC鎖定到NTP停止工作的程度。
• 在應用程序啟動時自動生成數據庫索引可能是一個壞主意。
• 數據庫管理很重要而且很難 - 我們寧愿不自己做。

OpsManager并沒有真正兌現其無障礙數據庫管理的承諾。例如，實際管理OpsManager本身 - 特別是從OpsManager 1升級到2 - 非常耗時，并且需要有關我們的OpsManager設置的專業知識。

由于不同版本的Mongo DB之間的身份驗證架構發生了變化，它也沒有實現其“一鍵升級”承諾。我們每年至少花費兩個月的工程時間來完成這項數據庫管理工作。

所有這些問題，加上我們為支持合同和OpsManager支付的高額年費，讓我們尋找替代數據庫選項，具有以下要求：

• 需要最少的數據庫管理。
• 支持靜態加密。
• Mongo的可行遷移路徑。

由于我們所有其他服務都在AWS中運行，因此顯而易見的選擇是DynamoDB - 亞馬遜的NoSQL數據庫產品。不幸的是，當時Dynamo不支持靜態加密。在等待大約9個月后才添加此功能，我們最終放棄并尋找其他東西，最終選擇在AWS RDS上使用Postgres。

“但是postgres不是文件存儲!”我聽到你哭了。嗯，不，它不是，但它確實有一個JSONB列類型，支持JSON blob中字段的索引。

我們希望通過使用JSONB類型，我們可以將Mongo遷移到Postgres，只需對我們的數據模型進行最小的更改。此外，如果我們希望將來轉向更多的關系模型，我們就有了這個選擇。關于Postgres的另一個好處是它有多成熟：在大多數情況下，我們想要提出的每個問題都已經在Stack Overflow上得到了解答。

從性能的角度來看，我們有信心Postgres可以應對 - 而Composer是一個寫作繁重的工具(每次記者停止打字時都會寫入數據庫) - 通常只有幾百個并發用戶 - 而不是高性能計算!

第二部分 - 二十年的內容遷移，沒有停機時間

以下是我們遷移數據庫的步驟：

• 創建新數據庫。
• 創建一種寫入新數據庫的方法(新API)。
• 創建一個代理，使用舊的數據庫作為主數據庫，將流量發送到舊數據庫和新數據庫。
• 將記錄從舊數據庫遷移到新數據庫。
• 使新數據庫成為主數據庫。
• 刪除舊數據庫。

鑒于我們正在遷移的數據庫為我們的CMS提供支持，因此遷移對我們的記者造成的影響很小。畢竟，新聞永遠不會停止。

新API：

2017年7月底，新的Postgres驅動的API開始工作。所以我們的旅程開始了。

我們簡化的CMS架構是這樣的：數據庫，API和與之交互的幾個應用程序(例如Web前端)。堆棧是，現在仍然是使用Scala，Scalatra Framework和Angular.js構建的，它大約有四年的歷史。

經過一些調查，我們得出結論，在我們可以遷移現有內容之前，我們需要一種方法來與新的PostgreSQL數據庫進行對話，并且仍然像往常一樣運行舊的API。畢竟，Mongo數據庫是我們的真相來源。它在試驗新API時為我們提供了安全毯。

這是為什么在舊API之上構建不是一個選項的原因之一。在原始API中幾乎沒有關注點分離，甚至在控制器級別也可以找到MongoDB細節。因此，在現有API中添加另一個數據庫類型的任務風險太大。

我們采用了不同的路線，并復制了舊的API。這就是APIV2誕生的方式。它或多或少是Mongo的復制品，包含相同的端點和功能。我們使用doobie，一個用于Scala的純功能JDBC層，添加了Docker以便在本地運行和測試，并改進了日志記錄和關注點分離。APIV2將成為一個快速而現代的API。

到2017年8月底，我們部署了一個使用PostgreSQL作為其數據庫的新API。但這只是一個開始。Mongo數據庫中的文章最初是在二十年前創建的，所有這些文章都需要移到Postgres數據庫中。

遷移

我們需要能夠編輯網站上的任何文章，無論它們何時發布，因此所有文章都作為單一的“事實來源”存在于我們的數據庫中。

雖然所有文章都存在于Guardian的內容API(CAPI)中，它為應用程序和網站提供支持，但正確的遷移是關鍵，因為我們的數據庫是“真相的來源”。如果CAPI的Elasticsearch集群發生任何事情，那么我們將從Composer的數據庫中重新索引它。

因此，在關閉Mongo之前，我們必須確信在Postgres驅動的API和Mongo驅動的API上的相同請求將返回相同的響應。

為此，我們需要將所有內容復制到新的Postgres數據庫。這是使用直接與新舊API對話的腳本完成的。這樣做的好處是，API已經提供了一個經過良好測試的界面，用于從數據庫讀取和寫入文章，而不是直接編寫訪問相關數據庫的內容。

遷移的基本流程是：

• 從Mongo獲取內容。
• 將內容發布到Postgres。
• 從Postgres獲取內容。
• 檢查一個和三個的響應是否相同

如果您的最終用戶完全沒有意識到它已經發生并且一個好的遷移腳本始終是這個的重要組成部分，那么數據庫遷移真的很順利。

考慮到這一點，我們需要一個腳本，可以：

• 發出HTTP請求。
• 確保在遷移一段內容后，兩個API的響應都匹配。
• 如果出現錯誤則停止。
• 生成詳細日志以幫助診斷問題。
• 發生錯誤后從正確的點重新啟動。

我們開始使用Ammonite，Ammonite允許您在Scala中編寫腳本，Scala是我們團隊的主要語言。這是一個很好的機會，可以嘗試我們之前沒有用過的東西，看看它對我們是否有用。雖然Ammonite允許我們使用熟悉的語言，但也有缺點。雖然Intellij現在支持Ammonite，但當時它沒有，這意味著我們失去了自動完成和自動導入。也不可能長時間運行Ammonite腳本。

最終，Ammonite不是正確的工具，我們使用sbt項目來執行遷移。我們采用的方法允許我們使用我們自信的語言工作并執行多次“測試遷移”，直到我們有信心在生產中運行它。

快進到2017年1月，是時候在我們的預生產環境CODE中測試完整的遷移了。

與我們的大多數系統類似，CODE和PROD之間***的相似之處是它們運行的​​應用程序的版本。支持CODE環境的AWS基礎架構遠沒有PROD那么強大，因為它的使用率要低得多。

在CODE上運行遷移將有助于我們：

• 估計PROD上的遷移需要多長時間。
• 評估遷移對性能的影響(如果有的話)。

為了準確衡量這些指標，我們必須匹配這兩個環境。這包括將PROD mongo數據庫的備份還原到CODE并更新AWS支持的基礎架構。

遷移超過200萬項內容需要很長時間，當然比辦公時間更長。所以我們一夜之間在屏幕上運行腳本。

為了衡量遷移的進度，我們將結構化日志(使用標記)發送到ELK堆棧。從這里，我們可以創建詳細的儀表板，跟蹤成功遷移的文章數量，失敗次數和總體進度。此外，這些顯示在團隊附近的大屏幕上，以提供更大的可見性。

遷移完成后，我們采用相同的技術檢查Postgres匹配的Mongo中的每個文檔。

第三部分 - 代理和生產中的運行

現在，新的Postgres驅動的API正在運行，我們需要使用實際流量和數據訪問模式對其進行測試，以確保其可靠和穩定。有兩種可能的方法可以實現這一點：更新與Mongo API通信的每個客戶端以與兩個API通信; 或運行代理，這樣做。我們使用Akka Streams在Scala中編寫了一個代理。

代理操作相當簡單：

• 接受來自負載均衡器的流量。
• 將流量轉發到主api并返回。
• 異步將相同的流量轉發到輔助api。
• 計算兩個響應之間的任何差異并記錄它們。

一開始，代理在兩個API的響應之間記錄了很多差異，在需要修復的API中出現了一些非常微妙但重要的行為差異。

結構化日志記錄

我們在Guardian上進行日志記錄的方式是使用ELK堆棧。使用Kibana使我們能夠靈活地以對我們最有用的方式顯示日志。Kibana使用相當容易學習的lucene查詢語法。但我們很快意識到，在當前設置中無法過濾掉日志或對其進行分組。例如，我們無法過濾掉因GET請求而發送的日志。

我們的解決方案是向Kibana發送更多結構化日志，而不是僅發送消息。一個日志條目包含多個字段，例如時間戳，發送日志或堆棧的應用程序的名稱。以編程方式添加新字段非常簡單。這些結構化字段稱為標記，可以使用logstash-logback-encoder庫實現。對于每個請求，我們提取了有用的信息(例如路徑，方法，狀態代碼)，并創建了一個包含我們記錄所需的附加信息的地圖。看看下面的例子。 

object Logging { 
 val rootLogger: LogbackLogger = LoggerFactory.getLogger(SLFLogger.ROOT_LOGGER_NAME).asInstanceOf[LogbackLogger] 
 
 private def setMarkers(request: HttpRequest) = { 
   val markers = Map( 
     "path" -> request.uri.path.toString(), 
     "method" -> request.method.value 
   ) 
   Markers.appendEntries(markers.asJava) 
 } 
 
 def infoWithMarkers(message: String, akkaRequest: HttpRequest) = 
   rootLogger.info(setMarkers(akkaRequest), message) 
} 

我們日志中的附加結構允許我們構建有用的儀表板并在我們的差異中添加更多上下文，這有助于我們識別API之間的一些較小的不一致。

復制流量和代理重構:

將內容遷移到CODE數據庫后，我們最終得到了幾乎完全相同的PROD數據庫副本。主要區別是CODE沒有流量。為了將實際流量復制到CODE環境中，我們使用了一個名為GoReplay(gor)的開源工具。它的設置非常簡單，可根據您的要求進行定制。

由于進入我們的API的所有流量首先達到了代理，因此在代理服務器上安裝gor是有意義的。請參閱下文，了解如何在您的盒子上下載gor以及如何開始捕獲端口80上的流量并將其發送到另一臺服務器。 

wget https://github.com/buger/goreplay/releases/download/v0.16.0.2/gor_0.16.0_x64.tar.gz  
tar -xzf gor_0.16.0_x64.tar.gz gor  
sudo gor --input-raw :80 --output-http http://apiv2.code.co.uk 

一切都運行良好一段時間，但很快我們的代理幾分鐘時就遇到了生產中斷。經過調查，我們發現代理運行的所有三個盒子同時循環。我們懷疑gor使用了太多資源并導致代理失敗。在進一步調查中，我們在AWS控制臺中發現這些盒子已經定期循環，但不是在同一時間。

在深入研究之前，我們試圖找到一種方法來繼續運行gor，但這次沒有對代理施加任何壓力。解決方案來自Composer的二級堆棧。該堆棧僅用于緊急情況，并且我們的生產監控工具會不斷對其進行測試。將流量從此堆棧重新映射到CODE，速度加倍，這次沒有任何問題。

新發現提出了很多問題。該代理的構建可能沒有像其他應用程序那樣精心設計。此外，它是使用Akka Http構建的，之前沒有任何團隊成員使用過。代碼很混亂，并且快速修復。我們決定開始一項重大的重構工作，以提高可讀性，包括使用理解而不是我們之前增長的嵌套邏輯，并添加更多的日志記錄標記。

我們希望通過花時間了解一切是如何運作的，并通過簡化邏輯，我們能夠阻止騎行。但這沒效果。經過大約兩個星期的嘗試使代理更可靠，我們開始覺得我們越來越深入兔子洞了。必須作出決定。我們同意冒險并留下風險，因為花在實際遷移上的時間比試圖修復一個月內將會消失的軟件更好。我們通過再經歷兩次生產中斷來驗證這個決定，每次中斷持續大約兩分鐘，但總體來說這是正確的做法。

快進到2017年3月，我們現在已經完成了遷移CODE，對API的性能或CMS中的用戶體驗沒有任何不利影響。我們現在可以開始考慮在CODE中停用代理。

***階段是改變API的優先級，以便代理首先與Postgres交談。如前所述，這是基于配置的。然而，有一個復雜性。

更新文檔后，Composer會在Kinesis流上發送消息。為了避免重復消息，只有一個API應該發送這些消息。API為此配置了一個標志; 對于Mongo支持的API，該值為true，對于Postgres支持的API，該值為false。簡單地更改代理與Postgres交談是不夠的，因為在請求到達Mongo之前，消息不會在Kinesis流上發送。這太遲了。

為了解決這個問題，我們創建了HTTP端點，以便瞬時更改負載均衡器中所有實例的內存配置。這使我們能夠非常快速地切換哪個API是主要的，而無需編輯配置文件并重新部署。此外，這可以編寫腳本，減少人為干預和錯誤。

現在所有的請求都是Postgres，而API2正在與Kinesis交談，可以通過配置和重新部署來***更改。

下一步是完全刪除代理，讓客戶單獨與Postgres API交談。由于有許多客戶，單獨更新每個客戶并不是真的可行。因此，我們將其推向了DNS。也就是說，我們在DNS中創建了一個CNAME，它首先指向代理的ELB，然后更改為指向API ELB。這允許進行單個更改，而不是更新API的每個單獨客戶端。

現在是遷移PROD的時候了。雖然有點可怕，因為它是生產。這個過程相對簡單，因為一切都基于配置。此外，當我們向日志添加舞臺標記時，還可以通過更新Kibana過濾器來重新調整先前構建的儀表板。

關閉代理和MongoDB

在10個月和240萬個遷移文章之后，我們終于可以關閉所有與Mongo相關的基礎設施。但首先，我們一直在等待的那一刻：殺死代理

這個小軟件給我們帶來了很多問題，我們迫不及待想要把它關掉!我們需要做的就是更新CNAME記錄以直接指向APIV2負載均衡器。

該團隊聚集在一臺電腦周圍。只需點擊一下即可切換開關。沒有人再呼吸了。完全沉默。點擊!而且改變了。什么都沒發生!我們都放松了。

出乎意料的是，刪除舊的MongoDB API是另一項挑戰。在瘋狂刪除舊代碼時，我們發現我們的集成測試從未更改為使用新API。一切都很快變紅了。幸運的是，大多數問題都與配置相關，因此很容易修復。但是測試捕獲的PostgreSQL查詢存在一些問題。為了避免這個錯誤，我們想到了我們可以做的事情，我們意識到，在開始大量工作時你也必須接受你會犯錯誤。

之后發生的一切都很順利。我們從OpsManager中分離了所有Mongo實例，然后終止它們。剩下要做的***事情就是慶祝。