在這種情況下MySQL Replication是否合適？

Question

我有一系列數據庫，每個數據庫基本上都是獨立的。它最初看起來像我需要一個複製解決方案，但我研究得越多，它就越覺得複製過度而且無用。我之前沒有做過MySQL複製，所以我一直在閱讀在線文檔，使用Google搜索並搜索相關問題，但是我找不到與我的情況非常相似的情況。這裏是我的問題的簡要說明：

1. 各種數據庫幾乎從來沒有實時連接到對方。
2. 他們需要能夠通過將文件複製到拇指驅動器然後將其移動到正確的目的地來「同步」。
3. 數據不完全匹配是可以的，但它們應該具有相同的父子關係。也就是說，如果生成的密鑰在數據庫之間不同，那麼沒什麼大不了的但可見數據必須匹配。
4. 時間安排並不重要。更新可以在一個星期之後完成，或者在 個月之後完成，只要他們最終完成了 即可。
5. 更新不能保證是 以正確的順序或以任何順序。他們將從每個數據庫按順序;只是不是數據庫之間的。
6. 而不是一組主從關係，它更像是一箇中央數據庫（R/W）和多個遠程數據庫（也是R/W）。
7. 我不知道我有多少個遠程 數據庫，直到他們創建了 。中央DB在數據到達之前不會知道數據庫存在。 （對我來說，這意味着我不能使用賦予每個唯一身份範圍的方法來保證中央數據庫的唯一性。）

在我看來，底線是我不想「複製「就像我想要的」意識「一樣。我想讓中央數據庫知道遠程數據庫中發生了什麼，但沒有時間要求。我想讓遠程數據庫知道中央數據庫，但他們不需要了解彼此。

WTH是我的問題嗎？它是這樣的：這種情況聽起來像任何典型的複製場景，還是聽起來像我必須推出自己的？或許上述＃7是唯一重要的，並且考慮到這一要求，即時複製是不可能的。

編輯：我意識到這個問題可能更適合於ServerFault。我也在那裏搜索，發現我的問題沒有答案。根據我在SO和SF上找到的複製問題，似乎決定在哪裏提出我的問題是50-50。對不起，如果我猜錯了。

Answer 1

由於「主」數據庫在它們出現之前不會知道複製數據庫的情況，所以這顯然不適用於複製。數據顯示時只是插入或更新。所以我正在關閉這個並接受這個答案，因爲問題變得沒有實際意義。