數據庫拓撲設計混亂

Question

背景

我運行（讀：繼承）的網絡是設置非常類似於一個共享託管服務提供商。基礎設施上運行着300-400個站點。多年來，數據庫拓撲結構變得非常分散，因爲它與webserver-> database是1對1的關係。

問題

• 的應用是從10通過已實施的WordPress第三方設計公司設計的9次/的Joomla/Drupal的等
• 的數據庫之類的隨意橫跨6個數據庫蔓延服務器。他們沒有複製到任何地方。
• 應用程序沒有單獨的數據庫句柄的概念來將INSERT分隔爲主模塊和SELECT模塊分配給從模塊。
• 使用單主內置mysql複製創建了一個巨大的瓶頸。插入的數量會很快下降到主分區。

問題

我的問題是，怎樣才能讓我的數據庫拓撲儘可能平坦，同時留出空間未來可擴展性？

未來，我希望在我的網絡中添加更多的地理位置，以便在「底層網絡」上覆制相同的數據庫。

在過去，我研究了多主複製，但看到了諸如auto_increment列碰撞之類的問題。

我向企業解決方案開放。類似於用於Oracle複製的Shareplex產品。

無論解決方案是什麼，期望應用程序改變以適應這種新設計是不合理的。因此，像auto_increment列這樣的東西需要保持不變，並凝聚整個集羣。

目標

我的目標是有一個內部負載平衡的主機名，我可以在點所有的應用程序的每個集羣。我

這也會給我容錯，我目前沒有。目前，從旋轉中刪除數據庫是不可能的。

像Cassandra和Hadoop這樣的應用程序看起來與我想實現的非常相似，但NoSQL不適用於這些應用程序。

任何提示/指針/教程/文檔/產品建議非常感謝。謝謝。

Answer 1

在過去，我研究了多主複製，但看到了諸如auto_increment列碰撞之類的問題。

我們在生產中使用多主人工作。汽車公司的難題早在auto_increment_increment and auto_increment_offset就已經解決，它允許每個服務器擁有自己的增量ID模式。只要應用程序沒有設計就盲目地假設所有的ID都是順序​​的，它應該可以正常工作。

多主節點真正的問題是，MySQL 仍然偶爾會破壞二進制日誌。這主要是由於不可靠的連接造成的問題，所以如果所有的實例都是本地的，這不會成爲問題。

多主控制器的另一個問題是，它只是不能按照您已經經歷或假設的寫法進行擴展，給出答案中的一點。 所有的一個主文件上的寫入都有被其他人複製。即使您正確地分攤了讀取負載，您最終也會遇到只能通過更多硬件，應用程序重新設計或分片（請參閱：重新設計應用程序）才能解決的I/O瓶頸問題。現在MySQL已經有了基於行的複製可用。

如果您需要地理多樣性，多主可以工作。

另請參閱DRBD磁盤塊級複製系統，該系統現在已被內置到現代Linux內核中。它之前被其他人用來複制MySQL和PostgreSQL，雖然我沒有任何個人經驗。

如果您正在尋找高可用性，或者只是尋找（手動或自動）故障切換，我無法從您的問題中得知。如果您只需要需要故障切換並且可能有一點停機時間，那麼傳統的主/從複製對您來說可能就足夠了。麻煩是把一個成爲主人的奴隸變成奴隸。