Test the MySQL-Amoeba load balancing and read/write splitting functions.

Because MySQLCluster implements automatic data synchronization and other functions, a layer of Amoeba serves only to share the load of the SQL layer, therefore, it is necessary for Amoeba based on the traditional single point MySQL service to help us do something. We will not repeat the environment building process. We will start two independent

Because MySQL Cluster itself implements automatic data synchronization and other functions, the installation of a layer of Amoeba serves only to share the load of the SQL layer, therefore, it is necessary for Amoeba based on the traditional single point MySQL service to help us do something. We will not repeat the environment building process. We will start two independent

Because MySQL Cluster itself implements automatic data synchronization and other functions, the installation of a layer of Amoeba serves only to share the load of the SQL layer, therefore, it is necessary for Amoeba based on the traditional single point MySQL service to help us do something.

We will not repeat the environment setup process. We will start two independent MySQL services on two new virtual machines and configure them in Amoeba. At this time, the IP addresses of SQL nodes are:

10.4.44.206 write 10.4.44.207 read 10.4.44.208 read 10.4.44.205 Amoeba Node

The MySQL version used here is, mysql-5.5.29-linux2.6-x86_64. You have created the same database (bigdata) and table (data_house) on the three nodes ). Modify amoeba. xml and dbServers. xml configurations and restart the amoeba service.

With curiosity, first test writing data and querying data through the Amoeba node to see if the data is automatically synchronized by each node. Similarly, use the previously used JDBC test code. Observe the network and disk metrics of the VM during the write process.

Write206 node monitoring chart

It was found that only 206 of write nodes had network and disk transmission requests, and 207 and 208 nodes remained calm. Obviously, the data is not synchronized in this way. The data is queried through Amoeba, and there is no data. In this case, we should configure horizontal segmentation rules for Amoeba to store data on each node separately. In this case, each node has only a part of data, and any node failure will result in incomplete data. Let's verify if this is the case.

Modify the configuration in rule. xml,

Split data horizontally based on the value of ID hash (2. Each rule corresponds to its own read/write node. Here the verification is the Amoeba routing rule function. Execute data insertion. We can see that the data is evenly distributed to 207 and 208 data nodes, each with 10000 data records.

 

At this time, the count operation is executed, and the return value is always 10000. Therefore, the complete data cannot be queried. However, with this splitting rule, you can flexibly configure your own configurations, such as vertical splitting. Therefore, it can be seen that the main responsibility of Amoeba is to act as a route and distribute requests. Data Synchronization is not a concern of Amoeba. Therefore, the read/write splitting introduced on the Amoeba official website is based on the MySQL Master/Slave configuration. This is what we will do next :)

Original article address: MySQL-Amoeba load balancing, read/write splitting function verification, thanks to the original author for sharing.