CloudDB AutoAdmin - Large Scale and Big Data: Processing and Management - page 369

MySQL with asynchronous master-slave replication is limited in its ability to scale
due to the saturation to the master database. In particular, the throughput trends
react to saturation movements and transitions in database replicas in regards to an
increasing workload and an increasing number of database replicas. In general, the
observed saturation point (the point right after the observed maximum throughput
of a number of slaves), appearing in slaves at the beginning, moves along with an
increasing workload when an increasing number of slaves are synchronized to the
master. Eventually, however, the saturation will transit from slaves to the master
where the scalability limit is achieved. Taking throughput trends with configurations
of the same zone and 50/50 ratio (Figure 11.5a) as an example, the saturation point
of 1 slave is initially observed at under 100 workloads due to the full utilization of
the slave's CPU. When a second slave is attached, the saturation point shifts to 175
workloads where both slaves reach maximum CPU utilization while the master's
CPU usage rate is also approaching its utilization limit. Thus, ever since the third
slave is added, 175 workloads remain as the saturation point, but with the master
being saturated instead of slaves. Once the master is in the saturation status, adding
more slaves does not help with improving the scalability, because the overloaded
master fails to offer extra capacity for improving write throughput to keep up the
read/write ratio that corresponds to the increment of the read throughput. Hence,
the read throughput is suppressed by the benchmark, for the purpose of maintaining
the predefined read/write ratio at 50/50. The slaves are over provisioned in the case
of 3 and 4 slaves, as the suppressed read throughput prevents slaves from being fully
utilized. The similar saturation transition also happens to 3 slaves at 50/50 ratio in
the other two locations (Figure 11.4b and 11.4c) and 10 slaves at 20/80 ratio in the
same zone (Figure 11.5a) and different zone (Figure 11.5b) and also 9 slaves at 20/80
ratio in different regions (Figure 11.5c).
The configuration of the geographic locations is a factor that affects the end-to-
end throughput, in the context of locations of users. In the case of our experiments,
since all users emulated by Cloudstone send read operations from us - east -1 a , dis-
tances between the users and the slaves increase, following the order of same zone,
different zone, and different region. Normally, a long distance incurs a slow round-
trip time, which results in a smaller throughput for the same workload. Therefore,
it can be expected that a decrease in maximum throughput would be observed
when configurations of locations follow the order of same zone, different zone,
and different region. Moreover, the throughput degradation is also related to read
percentages where higher read percentages would result in larger degradations. It
explains why degradation of maximum throughput is more significant with con-
figuration of 80/20 read/write ratio (Figure 11.5). Hence, it is a good strategy to
distribute replicated slaves to places that are close to users to improve end-to-end
throughput.
The performance variation of instances is another factor that needs to be consid-
ered when deploying databases in the cloud. For throughput trends of 1 slave at 50/50
read/write ratio with configurations of different zone and different region, respec-
tively, if the configuration of locations is the only factor, the maximum throughput
in the different zone (Figure 11.4b) should be larger than the one in the different
region (Figure 11.4c). However, the main reason of throughput difference here is