Volume 3, Issue 9, September 2013 ISSN: 2277 128X

International Journal of Advanced Research in

Computer Science and Software Engineering
Research Paper
Available online at: www.ijarcsse.com
Database Replication Using Eager Replication
Kuljeet Kaur Poonam Sood Simarpreet Kaur
Dept. of Computer Science, PTU Dept. of Computer Science, PTU Dept. Of Computer Science, PTU
India India India

Abstract— Replication is the one of the good way to increase the performance of database system by separate out
database by maintaining different servers. Database replication is used to provide high availability and performance
for accessing data. In this paper we are discussing the eager replication technique of data replication to ensure
consistency using three parameters; this helps the database designer to examine various components and find the
most efficient and reliable replication technique.

Keywords—Database Replication, Data Consistency, Eager Replication, Data Replication Strategy, Eager Replication
Parameters.

I. Introduction
Distributed system is that system in which systems are logically connected. Data may be distributed or stored on multiple
systems located at same physical location or may be distributed over a network of interconnected systems. In order to
distribute database load to different database servers rather having a single mainframe server we replicate data. In this
way work load on single server can be decreased.
Replication is a process in which data is stored in more than one site for reliability and performance reasons. Database
replication having two types:
(1) Full Data Replication :- In this copy of whole database is stored at every site.
(2) Partial Data Replication :- In this some fragment of database are replicated.

II. Database Replication Techniques

(1) Eager Replication:- It is a synchronous replication technique, which is also known for deadlocking. It maintains
consistency by synchronizing transactions, but it is an expansive technique. Eager Replication solutions do conflict
prevention. For instance, if a record is changed on two nodes simultaneously, an eager replication system would
detect conflict before confirming the commit and abort one of transactions.
(2) Lazy Replication:- It is an asynchronous replication technique, which is also known for low data consistency and
high scalability and performance. Due to asynchronous transaction does not follow acid properties.

III. Database Replication Methods

(1) Snapshot Replication: - This is one of the simplest replication method. It sends data periodically in a bulk format. It
is mostly used in read only environment. In this replication method, data on one database server clearly copied to
another database server or to another database on same server.
(2) Merging Replication:- In this one database is combined into another database. In this process publisher and
subscribers make updates while connected or disconnected and then combining the updates when they are connected.
(3) Transactional Replication:- This type of replication is used in the environment where we have low degree of latency
and high bandwidth. It requires continuous and reliable connections. In this replication method user obtain initial
copies of database but obtain updates periodically on data changes.

IV. Eager Replication Technique

(1) PARAMETERS OF EAGER REPLICATION:
There are mainly three parameters of eager replication which determine the nature and properties of eager replication
protocols. These parameters are:
(a) Server Architecture:- This is the first parameter to consider and in this transactions’ are executed in first place. It
is most important property of replication. It is based on the type of data is being replicated. Primary Copy method of
this technique is often used. It is further classified into two parts:
(i) Primary copy: Primary copy is specific site for replication associated with each data item. Any update made to
data item is firstly processed by primary copy or master and then propagates the updates to its slaves. Primary Copy
has a limitation of single point failure and a bottleneck. This limitation can be removed by providing role of one
primary copy (which crashes) to other slave or copy and providing back up of that primary copy also. This can be
done with the help of election protocol. To avoid bottlenecks, it is better to use hierarchical tree-structured system

© 2013, IJARCSSE All Rights Reserved Page | 1166

 Kaur et al., International Journal of Advanced Research in Computer Science and Software Engineering 3(9),
September - 2013, pp. 1166-1168
such as HAMP (Hierarchical Asynchronized Multi-level-consistency Protocol), where each data subset has its own
primary copy as data is partitioned in this protocol.

(ii) Update everywhere: Update everywhere provide update to data item to be performed on any server in a cluster
regardless of whether a transaction is update, delete, insert transaction or a simple transaction. The server on which
data update is performed will delegate the transaction to all other servers using multicast transaction primitive
propagation such as Total Order Broadcast. It removes the limitation of a single point failure in primary copy by
updating two different copies of same data item. It also removes the limitation of bottlenecks.
(b) Server Interaction:- This second parameter is necessary to performance of a replication protocol in distributed
systems. This provides the degree of communication between servers during execution of a transaction. Server
Interaction provides us with the amount of network traffic generated by transaction algorithm and overall overhead
of execution. This is considered as function of number of messages required to handle the operation of transaction. If
interaction between servers will be high, then consistency will also be high but low performance. On the other hand,
if interaction is low then consistency will be low and performance will be high. The reason for this relation between
consistency and performance is that server interaction is the result of consistency checking protocols such as two-
phase commit or 1-safe which is a trimmed down version of two-phase commit. In this we consider two cases:

(i) Constant Interaction: Constant Interaction is a technique in which constant number of messages is directly
related to number of transactions received independent of the operations in the transaction by means of message
grouping. In constant interaction protocols exchange a single message by grouping all the operations in a single
message. By grouping all the operation of a transaction, node communication can be limited.

(ii) Linear interaction: Linear interaction is a technique in which a database server transmits each operation of a
transaction on individual basis. This is mostly suited for small minimal node environment but when it is applied to
large distributed systems then scalability performance is limited but when limited nodes are replicated then overhead
becomes negligible. As propagation is done on individual basis then overhead reaches unacceptable levels. Database
server sent each operation as SQL statement or as log records.

(c) Transaction Termination: The last parameter in eager replication is way to terminate the transaction. It is a
process in which all servers either abort or commit the transaction. It is done to ensure Atomicity. Protocols use
transaction manager to manage transaction termination. Some protocols use single transaction manager while some
use multiple transaction managers. Transaction Termination can affect replication performance, data availability,
and data consistency. It can be broken down into two categories:

(i) Voting Termination: Voting Termination requires round of messages to coordinate different replicas to ensure
atomicity. The complexity of round messages in Voting Mechanism can be complex or simple. It can be complex as
an atomic commitment protocol which generally includes two phase commitment protocol and it can be simple as
single confirmation from a slave, show in figure.

(ii) Non Voting Termination: In non-voting termination technique individual sites determine whether to commit or abort
a transaction on their own. It is also called lazy replication. To have replicas in non-voting technique is not necessary
because it will only help to behave deterministically and determinism only affects transaction which are serializable. Its
main advantage is that it is non-blocking and is doing so on the expense of data consistency. The idea behind non-voting
technique very simple. In this technique, master copy writes everything in the log file that it believes should be
committed or aborted and then the log file is read by all of its slaves. No voting or interaction between the masters and
slaves or between the slaves occurs during read of log file hence the name NON-VOTING.

© 2013, IJARCSSE All Rights Reserved Page | 1167

 Kaur et al., International Journal of Advanced Research in Computer Science and Software Engineering 3(9),
September - 2013, pp. 1166-1168
V. Goals Of Database Replication
The three primary goals for data replication are increased availability, increased fault tolerance and data consistency.
1) Increased Availability:-It is basically used to improve the service performance by having multiple copies of data
in various stores it also eliminates the downtime. When the client’s primary source of requested data is down or
has a long wait it can attempt to access data from another server.
2) Data Consistency:- Data consistency is another goal of eager database replication. We basically use two main
approaches for data consistency.
(i) Block access to all other copies of a file while one of them is being updated.
(ii) Copies of a file are merged after updates have taken place, which is a quite complex task. If
consistency is not of primary importance it can be sacrificed for availability and performance.
3) Fault-Tolerance:- Fault Tolerance is another goal of eager database replication. As the data is stored at more
than one site, if a data site fails the system can operate using replicated data and thus increases the fault
tolerance.
VI. Future Enhancement
The future scope of database replication include the higher flexibility of choosing, plugging in and swapping protocols in
order to optimally adapt the replication management and recovery strategies to different installations, current applications
and user with different profiles as determined by the number of alive and broken nodes, the current network traffic,
transmission rates, device properties etc. From the point of network designer and users network dynamics may behave
intentionally or unintentionally. Intentional changes may be scheduled (i.e. the opening and closing hours of business) or
adhoc (i.e. casual user log on and log offs). Unintentional changes may be accidental (e.g. crashes of sites or links due to
software or hardware failure) or malicious. Handling of intentional changes can be expected to be much easier than
unintentional ones, since the effect and consequences of the former can be anticipated much better. There are two another
major obstacles needs to be overcome when introducing replications
1. Developing replication protocols:- they are necessary for maintaining data consistency. They introduce
additional overhead.
2. Application specific needs:- each application has different degree of information consistency and availability.

VII. Conclusion
Database Replication is one of the best processes to find out different components of data that is used during share,
access, store, fetch or retrieve the data components from databases. Eager Replication is the technique that helps to
database designers and programmers to find out their necessity components of data during processing of databases.

References
[1]http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=885408&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%
2Fabs_all.jsp%3Farnumber%3D885408

[2]http://www.dbjournal.ro/archive/2/4_Cristian_Mazilu.pdf

[3]http://infoscience.epfl.ch/record/49996/files/WPS%2B00b.pdf

[4]http://www2.stetson.edu/mathcs/people/students/research/pdf/2007/acaloiaro/final.pdf

[5]http://www.waset.org/journals/waset/v59/v59-61.pdf

[6]http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.17.9166&rep=rep1&type=pdf

[7]http://jarrett.cis.unimelb.edu.au/papers/DataReplicationInDSChapter2006.pdf

© 2013, IJARCSSE All Rights Reserved Page | 1168