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

eu-west). On the runtime, the monitor module is responsible of continuously tracking
the application-defined SLAs and feeding the control module with the collected infor-
mation. The control module is responsible for continuously checking the monitored
SLA values against their associated application-defined SLAs and triggers the action
module to scale out/in the database according to the application-defined action rules.
In general, dynamic provisioning at the database-tier involves increasing or decreas-
ing the number of database servers allocated to an application in response to workload
changes. Data replication is a well-known strategy to achieve the availability, scalabil-
ity, and performance improvement goals in the data management world. In particular,
when the application load increases and the database tier becomes the bottleneck in the
stack of the software application, there are two main options for achieving scalability
at the database tier to enable the application to cope with more client requests:
1. Scaling up (vertical scalability) , which aims at allocating a bigger machine
with more horsepower (e.g., more processors, memory, bandwidth) to act as
a database server.
2. Scaling out (horizontal scalability) , which aims at replicating the data across
more machines.
In practice, the scaling up option has the main drawback that large machines are
often very expensive and eventually a physical limit is reached where a more power-
ful machine cannot be purchased at any cost. Alternatively, it is both extensible and
economical, especially in a dynamic workload environment, to scale out by adding
another commodity server that fits well with the pay-as-you-go pricing philosophy of
cloud computing. In addition, the scale out mechanism is more adequate for achiev-
ing the elasticity benefit of cloud platforms by facilitating the process of horizon-
tally adding or removing (in case of scaling in), as necessary, computing resources
according to the application workload and requirements.
In database replication, there are two main replication strategies: master-slave
and multimaster . In master-slave, updates are sent to a single master node and
lazily replicated to slave nodes. Data on slave nodes might be stale, and it is the
responsibility of the application to check for data freshness when accessing a slave
node. Multimaster replication enforces a serializable execution order of transactions
between all replicas so that each of them applies update transactions in the same
order. This way, any replica can serve any read or write request. Our framework
mainly considers the master-slave architecture as it is the most common architec-
ture employed by most web applications in the cloud environment. For the sake of
simplicity of achieving the consistency goal among the database replicas and reduc-
ing the effect of network communication latency, we employ the ROWA (read-once
write-all) protocol on the Master copy [13]. However, our framework can be easily
extended to support the multimaster replication strategy as well.
In general, provisioning of a new database replica involves extracting database
content from an existing replica and copying that content to a new replica. In prac-
tice, the time taken to execute these operations mainly depends on the database size.
To provision database replicas in a timely fashion, it is necessary to periodically
snapshot the database state to minimize the database extraction and copying time to