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

11.6 PROVISIONING THE DATABASE TIER BASED

ON SLA OF DATA FRESHNESS

11.6.1 a DaPtive r ePliCation C ontroller
In practice, the cost of maintaining several database replicas that are always strongly
consistent is very high. Therefore, keeping several database replicas with different
levels of freshness can be highly beneficial in the cloud environment since freshness
can be exploited as an important metric of replica selection for serving the applica-
tion requests as well as optimizing the overall system performance and monetary
cost. Our framework provides the software applications with flexible mechanisms
for specifying different service level agreements (SLA) of data freshness for the
underlying database replicas. In particular, the framework allows specifying an SLA
of data freshness for each database replica and continuously monitor the replication
delay of each replica so that once a replica violates its defined SLA, the framework
automatically activates another database replica at the closest geographic location to
balance the workload and re-satisfy the defined SLA [26]. In particular, the SLA of
the replication delay for each replica ( delay sla ) is defined as an integer value in the
unit of millisecond, which represents two main components:

delay sla = delay rtt + delay tolerance

where the round-trip time component of the SLA replication delay ( delay rtt ) is the
average round-trip time from the master to the database replica. In particular, it
represents the minimum delay cost for replicating data from the master to the associ-
ated slave. The tolerance component of the replication delay ( delay tolerance ) is defined
by a constant value that represents the tolerance limit of the period of the time for
the replica to be inconsistent. This tolerance component can vary from one rep-
lica to another depending on many factors such as the application requirements, the
geographic location of the replica, and the workload characteristics and the load
balancing strategy of each application. Therefore, the control module is responsible
of triggering the action module for adding a new database replica, when necessary,
to avoid any violation in the application-defined SLA of data freshness for the active
database replicas. In our framework implementation, we follow an intuitive strategy
that triggers the action module for adding a new replica when it detects a number
of continuous up-to-date monitored replication delays of a replica that exceeds its
application defined threshold ( T ) of SLA violation of data freshness. In other words,
for a running database replica, if the latest T monitored replication delays are violat-
ing its SLA of data freshness, the control module will trigger the action module to
activate the geographically closest replica (for the violating replica). It is worthy to
note that the strategy of the control module in making the decisions (e.g., the timing,
the placement, the physical creation) regarding the addition of a new replica in order
to avoid any violence of the application-defined SLA can play an important role in
determining the overall performance of the framework. However, it is not the main
focus of this chapter to investigate different strategies for making these decisions.
We leave this aspect for future work.