Database Reference
In-Depth Information
of the software stack where it is hard to push the database to its performance
limit. In general, a user's operation which is sent by a load generator has to be
interpreted as database transactions in the web tier based on a predefined business
logic before passing the request to the database tier. Thus the saturation on the web
tier usually happens earlier than the saturation on the database tier. To prevent
this from happening, the design of the original software stack is modified by
removing the web server tier. In particular, the business logic of the application
is re-implemented in a way that an end-user's operation can be processed directly
at the database tier without any intermediate interpretation at the web server
tier. Meanwhile, on top of Cloudstone, a DBCP
1
connection pool and a MySQL
Connector/J
2
are implemented. The pool component enables the application users
to reuse the connections that have been released by other users who have completed
their operations in order to save the overhead of creating a new connection for
each operation. The proxy component works as a load balancer among the available
virtualized database replica servers where all write operations are sent to the master
while all read operations are distributed among slaves.
MySQL Replication with a Fine-Grained Time/Date Function
Multiple MySQL replication are deployed to compose the database tier. Two
components are implemented to monitor replication delay in MySQL, including
a
Heartbeats
database and a time/date function for each virtualized database replica
server. The Heartbeats database, synchronized in the form of an SQL statement
across replica servers, maintains a
heartbeat
table which records an
id
and a
timestamp
in each row. A heartbeat plug-in for Cloudstone is implemented to
periodically insert a new row with a global id and a local timestamp to the master
during the experiment. Once the insert query is replicated to slaves, every slave
re-executes the query by committing the global id and its own local timestamp. The
replication delay from the master to slaves is then calculated as the difference of two
timestamps between the master and each slave. In practice, there are two challenges
with respect to achieving a fine-grained measurement of replication delay: the
resolution of the time/date function and the clock synchronization between the
master and slaves. The time/date function offered by MySQL has a resolution of
a second which represents an unacceptable solution because accurate measuring
of the replication delay requires a higher precision. Thus, a user defined time/date
function with a microsecond resolution is implemented based on a proposed solution
to MySQL Bug #8523
3
. The clock synchronizations between the master and slaves
