Survey on Comparative Analysis of Database Replication Techniques

Transcription

1 72 Survey on Comparative Analysis of Database Replication Techniques Suchit Sapate, Student, Computer Science and Engineering, St. Vincent Pallotti College, Nagpur, India Minakshi Ramteke, Student, Computer Science and Engineering, Nagpur Institute of Technology, Nagpur, India ABSTRACT Database Replication is one of the interesting and important aspects for distributed database systems. Most of the applications are of distributed nature thus their performance is an important issue. Database replication servers both fault tolerant as well as better performance feature to such distributive applications. In distributed system, database replication is often used to provide the high availability and performance for accessing the data. This paper presents basic understanding of database replication and different techniques or ways of replicating databases. This paper will go through both eager and lazy replication techniques. Consistency is the main area of eager replication, whereas bigger increase in performance in cost of consistency is the main area of lazy replication. This paper also provides the comparison of replication strategy so that database designer can decide which replication technique fulfils his requirements. Keywords Replication, Database Replication, Replication strategy, Replication control mechanism, Design issues 1. INTRODUCTION A database system is one of the computer systems which offer efficient data storage facilities to the applications. A database system is used to control the collection of data items. Database systems play a vital role in contemporary applications, such as administration, social sites, search-engines, and banking systems. Database systems offer abstractions, data consistency and concurrent data access due to this database system got huge success in real world applications, for example, the standard file system of the operating system. A database system [2] provides an interface which can used to solve the problems of data storage and retrieval. allows concurrent data access with maintaining the data integrity. survives from the server crashes or power failures without corrupting data The scalability and performance are the key problems as the database system gets bigger. When database system increase from smaller system to larger system in that case performance is degraded and one point performance can become the bottleneck in the database system. Because of this, much research has been done in these areas of database systems [1]. Replication is one of the good ways to increase the performance of the database system by separate out the database by maintaining the different servers. Workload on a single server can be decreased by maintain the different database servers [1]. 2. REPLICATION CONCEPTS For better understanding the database replication and its methods this paper start with the term Replication. Replication in computing involves sharing information so as to ensure consistency between redundant resources, such as software or hardware components, to improve reliability, fault-tolerance, or accessibility. Figure 1 shows the basic replication model. In this model user or client does not know the multiple physical copies of data exits. Data replication is a combination of database and distributed system. Database replication can be defined as it is the process of creation and maintenance of the duplicate copy of database objects in a distributed database system [3]. In other words database replication is the frequent electronic copying data from a database located in one computer or server to a database in another database may be located on other or same computer or server so that all users can access the same information with high speed [4]. Database replication provides the alternate data access options to improve the high data availability, performance and fault tolerance of applications. For example, users can access a local database instead of a remote database due to this network traffic can be minimize and database performance can also be increased. The main features of database replication are as follows [4] Database locality: This feature of database replication maintains the database locally so that geographically for distance users can access data with high speed. These users can access data from local servers instead of far distance servers because data access speed will be much higher than far distance area network. By providing database as closer to the user as possible contribute to higher performance of a system.

2 73 Fig. 1:- Basic Replication Model Performance: Database replication is typically focus on to improving both read performance or write performance, while improving both read and write performance simultaneously is a more challenging task. When application is widely used across the large network but database is stored at a single server in that case database server can be a bottleneck of that system and the whole system allows down, i.e. slow response time and low request throughput capacity. Multiple replicas offer the system which servers the data parallel. Availability and fault tolerance: High availability of database requires low downtime of database system. In database system there are two downtimes are two downtimes are exits first is planned and another one is unplanned. Planned downtime incurred during the maintenance operation of all the software and hardware. Unplanned downtime can strike at any time and it is due to predictable or unpredictable failures such as hardware failures, software bugs, human error, etc. Downtime is usually the primary optimization area of database replication to increase the database availability. If a database item is stored At a single server and that server does not respond or down or it might be crashes. In that case database replication is the solution of this problem which has capability to provide fault tolerance database system. The replica of database server can provide the data item to the users when server failure. This replica can also use for restoring the data of failure servers. In this way database replication increase the data availability and formed the fault tolerant system. [4] 3. REPLICATION STRATEGIES A replication strategy may be selected based on two basic characteristics: Where and When [7, 8]. When characteristic is based on when the data is updated at one site, the updates have to be propagated to the respective replicas. When the updates can be propagated can be achieved by two methods that are Synchronous (eager) and Asynchronous (lazy). Where characteristic is based on where the updates can take place and it can be achieved by two methods that are update everywhere (group) and primary copy (master-slave) methods. Synchronous replication works on the principle of Two- Phase commit protocol. In a two-phase commit protocol, when client send an update request to the one site of database system, then that site first connected to all other database systems, locks all those databases at the record level and then updates them simultaneously. If one of the database is not available, the data may not be updated. Synchronous replication strategy mainly focuses on data consistency; however it requires availability of all the database sites at the time of propagation of updates because of this synchronous replication not widely used in mobile applications. Mobile devices works with the offline database for example mobile application updated the local copy of database once all databases are connected then all copies are refreshed accordingly due to limitation of network bandwidth and utilization capacity. Due to this Asynchronous replication are more popular than the synchronous replication. There exists two variations of Asynchronous replication i.e. Periodic and Aperiodic. In Periodic replication, the data items are updated at

3 74 specific intervals, whereas in aperiodic replication the updates are propagated only when necessary [1]. In Update anywhere method, the update request can be handled on any of the database system site whereas in a Primary Copy method only one copy (i.e. primary copy or master) handles the update requests and all other sites (i.e. secondary or slave) copies the changes from the master site. Other ways of replication strategies are as follows [1]: Snapshot Replication: In snapshot replication, a snapshot or plain copy of data is taken from one database server and moved to another server of database or to another database on the same server. Snapshot replication refreshes the data periodically. This is the easiest form of replication. This replication used for the backup purpose because this replication copy all data items each time a table is refreshed [14]. Transactional Replication: Transactional replication contains the replication agent which monitors the database server for changes and transmits those changes to the other database servers [9]. Transactional Replication refresh the replicas on the basis of transactions instead of whole data items of table and transaction transmission can take place immediately or on periodic basis. This replication method uses the log reader agent to read the logs and stores the new transactions in the distribution database. The distribution agent then transfers the transaction from the publisher site to the subscriber site [14]. Statement based replication: The statement based replication collects every SQL query before execute or commit it any replica and sends it to different replicas [10]. Each replica operates independently that means any replica can handle read-write operations. To resolve the conflicts, Read-Write queries are sent to all servers whereas read only queries can be execute on only one server and it will not propagate on other servers. Merge Replication: Merge replication allows the replicas to work independently [9]. In merge replication database entities can work offline that means it is not essential that all entities are always in online while accessing the data of database through any application. When they are connected, the merge replication agent checks for changes on both sets of data and modifies each database accordingly. A. Eager replication In eager replication updates are propagated within the boundaries of a transaction that is the user does not receive the commit notification until sufficient copies in the system have been updated. In eager replication all replicas are active or consistent all the time. Therefore this replication has no serialization anomalies and no need for reconciliation in eager replication. Eager replication uses locking mechanism for maintaining the data consistency [7]. Figure 2 describes the steps for replicating the database in the eager replication strategy. Fig. 2:- Eager replication steps for replicating database Eager replication is the safest type of replication when it comes to consistency and reliability. Performance is the main problem of eager replication. Eager replication also suffers by deadlock because of the larger synchronization requirements [7]. B. Lazy Replication Lazy replication updates the local copy and after the commit of transaction some time it propagates the update transaction to other database replicas. In other words this method propagates the updates once the transaction has already committed. This allows a fast transaction completion, but does not provide the

4 75 consistent data all the time. This method allows concurrent data access may lead to a high abort rate. This method has been used in several commercial DBMSs and it is the main option when mobile or disconnected databases are considered [11]. Figure 3 describes the steps for replicating the database in the lazy replication strategy. Fig. 3:- Lazy replication steps for replicating database This method gives a less waiting time for clients to receive a response from a node, but on the other hand no agreement has been made in the system that the transaction can be executed without interfering with other transactions running in parallel. Due to this conflicting transactions may occur [6, 12]. Even though the data inconsistent problems with lazy replication still today s many systems uses this technique as it gives the better performance and high data availability[1]. C. Primary Copy Replication All client application communicates with the primary servers when client want to update a particular data item. Only primary server can propagates the updates to all other replica managers, called slaves Client application may read data items from slaves If primary server fails, an election algorithm can elect a new primary. In the primary copy replication technique all the update transactions are forwarded to and executed by a single replica, called as primary replica. The other replicas are only its backups or secondaries. These replicas are used for recovery purpose when some replica crashes or failure. The secondary replicas are read only replicas [11]. Figure 4 describes the way a primary copy system could work. The main problem of this technique is its lack of scalability, since updating transactions should be executed by a single replica due to this approach compromises its performance. However, this approach introduces some performance gains, since this approaches removes the need of coordination among multiple replicas in order to decide the outcome of each transaction [11]. Fig. 4:- Primary Copy Replication

5 76 This approach can be used to increase the performance of a middleware based data replication system. A system can be divides the database into different subsets, and assign a master replica to each of such subsets. Each incoming transaction is forwarded by its delegate replica to associated primary replica of that subset. In this way, the load can be easily balanced in the system and the concurrency control can be locally managed by each primary replica. As a result, the performance is highly increased [13]. D. Update Everywhere Replication Update Everywhere does not contain a primary node, instead all nodes in the system are considered equal. That means any database node in the system can handle the update transaction instead of only one primary node. The database node which receives the update transaction has some mechanism to propagating the update transaction to the other nodes for making consistent data among all the database nodes [1]. Figure 5 describes the way a update everywhere replication system could work. This method speeds up the access time for users as they can access any database node, but this method required coordination between al the nodes to synchronizing the transaction among the all the replication nodes of the database system. This replication method demanding the locking and commit-protocols for coordination mechanism because data retrieval can be inconsistent when update transaction performs on one node and accesses that data from separate nodes [6]. Fig. 5:- Update Everywhere Replication 4. CLASSIFICATION OF REPLICA CONTROL MECHANISM There are four basic classifications has been created by combining above four strategies Fig. 6:- Classification of replica control mechanisms Fig. 7:- Eager Primary Copy

6 77 A. Eager Primary Copy In an eager Primary Copy system no updates are done in the primary system until all secondary databases also has received the update. Figure 7 shows an example of an eager Primary Copy system where all update transactions are directly handled by the primary database and read operations can be performed on secondary site. When the primary database receives an update transaction the transaction is first performed, but not committed, in the primary database. That update transaction is propagate to all secondary databases that performs the update. With the help of a 2PC protocol all databases agree on the update and then it is committed on all database sites. In last phase primary database send a response to the client after the agreement that all databases have committed the update. With the help of an such mechanism the system is always consistent, which means that all the secondary databases contain the latest copy of the database. This ensures that the reads done by a client on its local secondary copy receives the proper values [1,6,7]. other databases in the system. If all database sites are granted for lock, the transaction execution proceeds on all databases and a 2PC protocol is used to make sure that all databases have committed the updates. When the transaction is finished all locks are released and other transactions get the ability to lock and use the data item. Update everywhere with Atomic Broadcast: Atomic broadcast method don t use locks for ordering the transactions. This method instead uses broadcasts where all conflicting transactions have a total order between them. The atomic broadcast has two important aspects by which it guarantees that all database will be consistent after the transaction is committed. A first aspect says that if one node in the system receives a transaction, all other databases will also eventually receive the same transaction. The second aspect says that if one node will receive two transactions, transaction T1 and T2, in a certain order, all other databases will receive them in the same order as well [1,6]. B. Eager Update Everywhere There are mainly two different approaches are used to maintain the consistency with the eager update everywhere strategy. The first is to use locking for avoiding concurrent transactions on the same data. The second approach is to use an atomic broadcast in the system that decides the total order in which conflicting transactions should be dealt with [1,6]. Update Everywhere with locking: Locking techniques is used for deciding whether the system to grant or not grant locks for all data to access before a transaction is executed. When a client sends a transaction to its local database, then the local database sends out a locking request to the C. Lazy Primary Copy Lazy primary copy systems works in similar way as the eager systems, except on when the primary database propagate the updates on the secondary site. Figure 8 describes the way a lazy primary copy system could work. Client s sends update and read transactions to the local secondary copy. All read transactions will be handled on the secondary database. When an update transaction is received then it is sent to the primary database. When the primary database receives an update transaction it is executed and committed. The primary database is then propagated new copy to the secondary databases so that all replicas update their copy of the database. Fig. 8:- Lazy Primary Copy

7 78 This system works in a lazy way due to this there is no guarantees when the new database copy will be propagated and copied in the secondary database nodes. There could be also differing in the time when the different secondary database nodes receive the updated copy. This means that there always is the risk that an old copy of a data item is read by a user as the new value of the item haven't been updated in the node yet [1]. D. Lazy Update Everywhere Lazy Update Everywhere gives a substantial performance gain during the transaction but presents a complicated problem during the synchronization points in the system. For example the same data item could have been updated in different nodes at the same time. This require some decision mechanism in the system on which transaction to keep and which transactions to undo [1, 6]. 5. DESIGN ISSUES IN REPLICATED DATABASE SYSTEM Replication Data item size: Decide whether to replicate an entire table, a subset of a table, or data from more than one table. The cost of this is factor depends upon the amount of data to refresh the replica, the overall table size, and the complexity of the link. Replication frequency: This factor decides when the replicas have to update or the appropriate timing when the updates take place on replicas. Data transmission volume: This factor decides whether sending all changes for any one row, or just sends the net effect of all the changes. Replication unit: It identifies the unit of data that will be transmitted from the updated replica to the non-updated replica. For high risk of conflicts environments, it can also be an only change in a cell within a record set. Security: It ensures the right level of security to the replicated data so that data should not be linked while replicating the data from updated replica to non-updated one. Initiator Decide: It identifies the level of responsibility of source and destination replicas. Such as whether the source pushes the data or the target pulls it. Locking issues: It determines the locking impact of the system whether it is accepted or not. If it is not acceptable, then slight decrease in consistency at that time to the avoid lock conflict. Replication topology: It identifies the players, their roles, and the overall integrity of the replicas. Key updates: Key updates means the source replicas can allows the updates to the key of records belonging to the replication set. This factor determines whether it is applied in the replication system or not. If it is applied in the replication system in that case, special care must be taken for managing the consistent replication of such key updating operations. Referential integrity: Referential integrity means the change in one table triggers a target change in another replicated table. This factor determines whether it is applied in the replication system or not. If it is applied in the replication system in that case, system needs rules to maintain the data integrity. 6. CHOOSING A DATA REPLICATION METHOD Selection of a data replication method should start with a business impact analysis to determine required data recovery time objectives and data recovery point objectives. For applications that can't accept data loss that is recovery time is equal to zero or it is negligible, synchronous replication is required. But in synchronous replication all replica sites should be online because it will drag down application I/O performance. If there is any risk of network latency or unreliable bandwidth, asynchronous replication is required to improve the application performance. On the basis of bandwidth requirements, impact on bandwidth cost, and how data replication will impact other applications and users. If bandwidth & its cost is very limited then the lazy replication method is the best solution but it compromises with the data consistency. If application data is highly sensitive and client agree to spend more money on high bandwidth & network devices then the eager replication is required. 7. COMPARISON FOR DATABASE REPLICATION STRATEGIES E. Primary Copy vs. Update Everywhere Theoretically update everywhere is a more elegant solution because it does not introduce bottlenecks. Still primary copy replication is more popular in practice. Update everywhere system might not scale up as more server nodes are added unless there is a significant amount of read operations in the overall load. To improve the performances of update everywhere is to perform preprocessing operations at one site and send the results to the other sites. That s way, the processing does not need to be done everywhere. Update everywhere becomes a more attractive solution since it is more robust to failures and facilitates distributing the load among the sites.

8 79 F. Eager Replication vs. Lazy Replication Eager replication is also known as synchronous replication. No concurrency anomalies occur because this replication gives serializable execution. In other hand, lazy replication is also known as asynchronous replication. In this case, if the transactions are committed, they are sent to the different sites for the updates to occur. Eager systems propagate updates to replicas within the scope of the original updating transaction. This makes it relatively easy to guarantee transaction serialization. However, since transactions are distributed and relatively long-lived, the approach does not scale well. Lazy schemes, on the other hand, update replicas using separate transactions. One of the challenges in database replication is to introduce replication without severely affecting performance. Because of this difficulty, current database products use lazy replication, which is very efficient but can compromise consistency. As an alternative, eager replication guarantees consistency but most existing protocols have a prohibitive cost. 8. COMPARISON FOR DATABASE REPLICATION MODELS Where When Eager Lazy Primary Copy Advantages Site coordination mechanism does not require. That means updates do not need to be coordinated All replicas are active so no data inconsistencies occur. All updates performed on single site so there is no chance of deadlocks. Disadvantage Longest response time This replication system useful with few updates. Secondary copies can be used only for read operations. Too expensive. Not used in practice. Advantages Site coordination mechanism does not necessary. That means updates do not necessarily coordinated. Short response times. Disadvantage Updates propagation performs lazily due to this; secondary copies are not up to date. So data inconsistencies problem exists in it. Feasible in most of the application. Update Everywhere Advantages All replicas are active so no data inconsistencies occur. Updates can be occurring in any site that s why this is elegant solution of database replication. Disadvantage Long response times Need site coordination mechanism to coordinated the updates Too expensive. Does not scale well in large system because of deadlocks. Advantages No centralized coordination required just like in eager or primary copy replication methods. Shortest response times. Disadvantage Updates propagation performs lazily due to this; replicas are not up to date. So data inconsistencies problem exists in it. Reconciliation mechanism required to handle serializations anomalies. Feasible in some applications. 9. CONCLUSION Database Replication provides an easy solution when data must be highly distributed. Comparing the replication techniques several conclusion can be drawn. All the techniques have both pros and cons. The primary copy strategies are good for redundancy and do not have the same problem with inconsistency as the Update Everywhere techniques can suffer from. But a primary copy system suffers with the bottleneck problem as all updates must be done in the primary database. In other hand update everywhere has a good potential of distributing the load among the sites but it need the

9 80 synchronization and coordination mechanism to ensure the consistency between the databases. In commercial database systems, lazy method is used commonly for the database replication, lazy method ensuring the good performance, but without guaranteeing full replica consistency. This may lead to some transaction losses in case of failure. To overcome these problems, eager replication method with group communication support have been proposed in the last decade. Lazy replication is a popular technique for improving the performance and availability of database system but it compromises with data consistency. In other hand eager replication maintains the consistency but it is more expensive and compromise with database performance. If performance and availability is important than the consistency then the lazy replication is the best solution. Transection deadlock depends on the transaction rate & size. When higher the transaction rate means dramatically higher deadlock rates. Lazy replication scheme will solve this problem. Lazy update everywhere scheme converts the waits & deadlock into reconciliation. Lazy primary copy replication has slightly better behavior than eager primary copy replication. But both schemes suffers when transaction rate or secondary sites increases dramatically. REFERENCES [1] Fredrik Nilsson, Patrik Olsson. A survey on reliable communication and replication techniques for distributed databases [2] R. Elmasri and S. B. Navathe. Fundamentals of Database Systems. The Benjamin/Cummings Publishing Company, Inc., [3] Salman Abdul Moiz, Sailaja P., Venkataswamy G., Supriya N. Pal. Database Replication: A Survey of Open Source and Commercial Tools. International Journal of Computer Applications ( ) Volume 13 No.6, [4] Heinz Stockinger. Data Replication in Distributed Database Systems, 1999 [5] M. Wiessman, A. S. Comparison of database replication techniques based on total order broadcast. IEEE Transactions on Knowledge and Data Engineering 17 (2005), 551{566. [6] M. Wiessman, F. Pedone, A. S. B. K. G. A. Understanding replication in databases and distributed systems. In Proceedings of the 20th IEEE International Conference on Distributed Computing Systems (Taipei, Taiwan, April 2000). [7] J. Gray, P. Helland, P. E. O Neil, and D. Shasha. The dangers of replication and a solution. In Proc. of the ACM SIGMOD Int. Conf. on Management of Data, pages , Montreal, Canada, June [8] Gustavo Alonso. IKS. ETH Zürich. Introduction of database replication. [9] Sujoy P.Paul, Pro SQL Server 2008 Replication [10] PostgreSQL 8.4 Server Administration, Volume II- The PostgreSQL Global Development Group, [11] F. D. Mu noz, H. Decker, J. E. Armend ariz, J. R. Gonz alez de Mend ıvil. Database Replication Approaches, [12] B. Kemme, G. A. A new approach to developing and implementing eager database replication protocols. ACM Transactions on Database Systems 25 (2000), 333{379. [13] M. Pati no-mart ınez, R. Jim enez-peris, B. Kemme, and G. Alonso. MIDDLE-R: Consistent database replication at the middleware level. ACM Trans. Comput. Syst., 23(4): , [14] Sanjay Kumar Tiwari, A.K. Sharma, and Vishnu Swaroop: DISTRIBUTED REAL TIME REPLICATED DATABASE: Concept and Design. ISSN Volume 3 No.6, 2005.