由於MySQL Cluster自身就實現了資料的自動同步等功能，在此之上架一層Amoeba基本只起到了分擔SQL層負載的的作用，所以我們很有必要基於傳統的單點MySQL服務之上的 Amoeba都能幫我們做些什麼。

環境搭建的過程不再贅述，我們在兩個新的虛擬機器上啟動兩個獨立的MySQL服務，然後配置在 Amoeba中即可。此時SQL節點的IP分別為：

10.4.44.206 寫
10.4.44.207 讀
10.4.44.208 讀
10.4.44.205 Amoeba節點

這裡使用的MySQL版本為，mysql-5.5.29-linux2.6-x86_64。先手動分別在三個節點上建立了相同的資料庫(bigdata)和表(data_house)。修改amoeba.xml和dbServers.xml配置，重啟amoeba服務。

懷著好奇，先測試通過Amoeba節點寫入資料和查詢資料的情況，看看資料是否是各個節點自動同步的。同樣，使用的之前使用的JDBC測試程式碼。觀察寫入過程中虛擬機器的網路和磁碟指標情況。

write206節點監控圖表

發現果然只有206寫節點有網路和磁碟傳輸請求，207和208節點一片平靜。顯然資料不是這樣同步的，通過Amoeba查詢，果然沒有資料。在這種情況下，我們應該配置Amoeba的水平切分規則，讓資料分別儲存在各個節點上。不過這樣的話每個節點都只有一部分資料，任何一個節點的故障都會導致資料的不完整，我們來驗證看看是不是這樣。

修改rule.xml中的配置，

根據ID hash(2)的值水平切分資料。這裡每個規則都對應自己的讀寫節點。這裡驗證就是Amoeba的路由規則功能。執行資料插入，可以看到資料平均的分配到207和208兩個資料節點上，各10000條資料。

此時執行count操作，返回值始終是10000，可見此時無法查詢到完整的資料。但是有了這種切分規則，你可以靈活的進行的自己的配置，比如可以進行垂直切分等。所以可見，Amoeba的主要職責是起到了一個路由的作用，把請求分發下去，資料同步不是它關心的。所以Amoeba官網中介紹的讀寫分離也是基於MySQL主從配置的，這也是我們接下來要進行的工作：）