同步表單向不同方向的不同表格

我從來沒有同步多個服務器。我正在研究一個需要多個MariaDB服務器來同步特定表的項目。每個表格只能在一臺服務器上進行更改，但每個表格都將在不同的服務器上進行更改。同步表單向不同方向的不同表格

鑑於表A，B，C，和d：

A - 設置表 - 只有更新，當用戶更改設置

B，C，d - 工作表 - 這些都會更新一次幾秒鐘的工作由個人服務器完成。

主服務器 - 變化A;需要B，C，D實時更新。

服務器2 - 更改B;需要A實時更新。

服務器3 - 更改C;需要A實時更新。

服務器4 - 變更D;需要A實時更新。

看看複製教程，我看到很多關於單向和雙向的信息，但是我一直未能找到與我正在嘗試做的事情相匹配的任何內容。

由於信息是時間敏感的，所以數據必須實時同步。如果服務器彼此失去連接，則只要連接恢復，我仍然需要同步數據。

這些表格將全部通過各自服務器上的PHP代碼進行更新。這些服務器都在運行Linux。這是MariaDB本身可以完成的事情嗎？或者以另一種方式處理這個問題會更好嗎？我真的希望避免將整個數據庫雙向複製到所有服務器，因爲大多數數據對於任何服務器都是不必要的，但主服務器和創建它的服務器是不必要的。

來源

2017-09-17 Ben Kirkland

忘記有多臺機器試圖互相同步。反而想想...

計劃A：使用單個服務器進行所有工作。然後沒有同步。

計劃B：利用網絡讓每個人都可以寫入一個主站，該主站可以不斷向單向複製到任意數量的從站。奴隸可以從中讀取。計劃C：某種形式的集羣（如Galera），以便多個節點不斷地相互複製，並且您可以讀取/寫入每個節點。

請注意「關鍵讀取」場景的任何同步或複製環境。這是當用戶在博客文章上發表評論時，則無法在下一個網頁上找到它。問題是它還沒有被「同步」。

回答你的問題：除了我描述的3件事外，沒有「同步」機制。

更

連接問題並不是一個嚴重的問題 - 有很多雲服務，在那裏，非常接近是可用的時間100.0％。

延遲並不是一個真正的嚴重問題 - 您會驚訝於網站有多遠。千里在今天的互聯網上「沒有」。

如果距離較遠，則最小化號碼從用戶到Web服務器的往返行程。並儘量減少前端和數據庫之間數據庫調用的號碼。請注意，在另一種情況下將Web服務器置於客戶端附近並且靠近數據庫是有益的。

在主從設置中，每天幾千兆字節是流量的合理上限。你在談論多少流量？

來源

2017-09-17 04:03:17

嗯......那是我害怕聽到的。忘了提及這些服務器將位於不同的地理位置，我希望這樣做可以幫助減輕任何延遲或連接問題。對我來說，做一些類型的複製會比我的工作線程更好，並且等待連接再次可用於主數據庫服務器。由於我期望在每臺服務器的個人表中建立千兆字節的數據，因此我不想將其複製到所有這些表中。 –

我添加了註釋以解決連接和延遲問題。 –

每個工作線程應該每天向數據庫寫入8640行。我希望每臺服務器上都有成千上萬個這樣的設備。每行由bigint id，Decimal（5,1），時間戳和2個INT組成。根據我現在工作表中的數據做數學計算，看起來我會每5秒鐘爲一千個線程傳輸大約126 KB的數據。可能從工作人員寫入主數據庫畢竟不是一個壞主意...... –

同步表單向不同方向的不同表格

回答

相關問題