2008-09-24 71 views
2

我在相當廣泛的區域有幾個不同的位置,每個位置都有一個存儲公司數據的Linux服務器。這些數據每天都會以不同的方式在每個不同的位置改變。我需要一種方法來保持這些數據在所有這些位置之間保持最新和同步。保持多臺Linux服務器同步的最佳方式是什麼?

例如:

在一個位置放置有人一組圖像的本地服務器上。在另一個位置,其他人將一組文檔放在他們的本地服務器上。第三個位置將少量的圖像和文檔添加到他們的服務器。在其他兩個位置,根本沒有對其本地服務器進行任何更改。到第二天早上,我需要所有五個地點的服務器都有這些圖像和文檔。

我的第一個直覺是使用rsync和cron作業在夜間(上午1點到上午6點左右)進行同步,當時我們的位置沒有使用任何帶寬。在我看來,最好讓一臺服務器成爲「中央」服務器,首先從其他服務器獲取所有文件。那麼它會將這些變化推回到每個遠程服務器?還是有另一種更好的方法來執行此功能?

+0

這可能是一個太開放的問題,應該屬於unix.stackexchange.com。只要提到它,即使我認爲它不值得被掠奪。 – lindhe 2015-05-02 22:26:13

回答

2

AFAIK,rsync是您的最佳選擇,它支持部分文件更新之間的各種其他功能。一旦設置它是非常可靠的。您甚至可以使用時間戳記日誌文件來設置cron,以跟蹤每次運行中更新的內容。

2

如果rsync不是最適合您的解決方案,那麼您可以選擇Unison。 Unison在Windows下工作,當雙方發生變化時(不一定需要按照您的建議選擇一臺服務器作爲主服務器),它有一些功能可供處理。

根據任務的複雜程度,可能有效。

1

我不知道這是多麼實際,但一個源代碼管理系統可能在這裏工作。在某個時間點(也許每個小時?),一個cron作業運行一次提交,並在一夜之間,每臺機器運行一次結賬。在結賬需要運行時,您可能會遇到長時間未完成提交的問題,而且rsync基本上可以做同樣的事情。

我想我在想的是,一箇中央服務器將使您的同步操作更容易 - 衝突可以在中央處理一次,然後推送到其他機器。

0

rsync將是您的最佳選擇。但是您需要仔細考慮如何解決不同網站上相同數據的更新之間的衝突。如果站點1已更新 'customers.doc',並且站點2對同一文件有不同更新,您將如何解決它?

2

你可以(理論上)做的一件事就是使用Python或其他東西以及inotify內核功能(例如通過pyinotify包)創建一個腳本。

您可以運行腳本,該腳本在特定樹上註冊以接收事件。然後,您的腳本可以觀看目錄,然後隨着每個服務器上的更改而更新所有其他服務器。

例如,如果有人將spreadsheet.doc上載到服務器,腳本會立即看到它;如果文檔在5分鐘內未被修改或刪除,則該腳本可以將其複製到其他服務器(例如,通過rsync)

這樣的系統理論上可以實現從一臺機器到另一臺機器的一種有限的'文件系統複製'。一種簡潔的想法,但你可能需要自己編寫代碼。

0

我必須同意Matt McMinn,尤其是因爲它是公司數據,我會使用源代碼管理,並且根據更改率更頻繁地運行它。

我認爲中央票據交換所是個好主意。

2

我這樣做(在Debian/Ubuntu的箱)的方式:

  • 使用dpkg --get-selections讓你安裝的軟件包
  • 使用dpkg --set-selections安裝從創建
  • 使用源代碼控制列表的包解決方案來管理配置文件。我以集中的方式使用git,但顛覆可以很容易地使用。
0

取決於以下 *需要同步多少臺服務器/計算機? **如果服務器太多,使用rsync會成爲問題 **您可以使用線程並同時或一個接一個地同步到多個服務器。 那麼,你是在給定的時間點在後一種情況下,看着在服務器上的源機器或一致的數據高負荷(集羣)

  • 需要的文件夾的大小來進行同步以及如何它經常變化

    • 如果數據很大,那麼rsync需要時間。
  • 文件數

    • 如果文件的數量都很大,特別是如果他們是小文件的rsync將再次採取了很多的時間

所以一切都取決於是否使用rsync,NFS,版本控制的場景

  • 如果服務器數量少,數據量小,那麼每小時運行一次rysnc是有意義的。 如果數據偶爾有變化,您還可以將內容打包到RPM中

根據所提供的信息,IMO版本控制將最適合您。

如果兩個人上傳具有相同名稱的不同文件,Rsync/scp可能會出現問題。 在多個位置的NFS需要完美架構

爲什麼不能有一個/多個存儲庫,並且每個存儲庫都只是向這些存儲庫提交。 您需要做的就是保持存儲庫同步。 如果數據很大並且更新頻繁,那麼您的存儲庫服務器將需要大量內存和良好的I/O子系統

相關問題