数据库复制：理论与实践

需积分: 9 148 浏览量更新于2024-07-24 收藏 1.74MB PDF 举报

"数据库复制（Database Replication）是数据管理领域的一个重要主题，涉及如何在多个数据库之间同步和分发数据。这一技术被广泛应用于确保数据的高可用性、容错性和性能优化。《Database Replication》这本书由Bettina Kemme、Ricardo Jiménez Peris和Marta Patiño-Martínez合著，于2010年出版，可能详细探讨了数据库复制的各种技术和策略。" 数据库复制是数据库系统中的一种机制，它允许数据在不同的物理位置之间复制和分发，以提高系统的可靠性和性能。这种技术对于那些需要在多地存储和访问数据的应用程序，或者对数据实时性要求极高的服务来说至关重要。例如，在云服务、电子商务和金融交易系统中，数据库复制可以确保即使在一个站点发生故障时，数据仍然可以被其他地方的用户访问，从而降低了单点故障的风险。《Database Replication》可能会涵盖以下几个核心知识点： 1. **复制类型**：全复制、部分复制、主从复制、多主复制等不同复制模式的优缺点和应用场景。 2. **复制协议**：如定时复制、事件驱动复制和异步复制，它们决定了何时以及如何更新副本。 3. **冲突检测与解决**：在多个副本同时进行修改时，如何识别和处理冲突，以保持数据的一致性。 4. **性能优化**：包括批量复制、延迟复制和选择最佳复制路径等策略，以减少网络负载和提高效率。 5. **安全性与故障恢复**：如何保证数据安全，以及在主服务器故障后如何快速切换到备用副本。 6. **分布式事务管理**：在复制环境中，如何管理和协调跨多个节点的事务。 7. **复制的挑战与问题**：比如网络延迟、数据一致性、同步延迟以及系统扩展性问题。 8. **应用案例**：实际场景中数据库复制的部署和实施，以及如何根据业务需求选择合适的复制策略。此外，书中的其他章节可能还讨论了与数据库复制相关的技术，如数据分区、分布式数据库、NoSQL系统中的复制策略，以及如何将数据库复制与其他数据管理技术（如数据流管理系统、数据仓库、XML处理、数据挖掘等）相结合。《Database Replication》这本书作为数据管理系列的一部分，为读者提供了深入理解数据库复制及其在现代信息系统中关键作用的宝贵资源。它不仅适合数据库管理员、软件开发者，也适合对数据管理和分布式系统感兴趣的学者和研究人员。通过阅读此书，读者将能够更好地应对大数据时代的数据分布、高可用性和安全性挑战。

1.1. MOTIVATION 3

Figure 1.2: Wide area architecture

Figure 1.3: Cluster architecture

multiple replicas within a local area network,resulting in what is often called a cluster (see Figure 1.3).

The cluster appears as one unit to the outside, and as requests come in, they are distributed across

the replicas. By adding new replicas, the system can scale up to increasing demands. In this case,

replication serves the purpose of scalability as it is able to provide increasing throughput.

However, as our company expands and attracts customers worldwide, it realizes that the

quality of service for users that are far away from the company’s headquarters suffers due to the

long network delay for each message exchange. Therefore, the company also replicates its database

at geographically strategic locations, providing acceptable response times to all their customers as

they can now connect to a close-by replica. We call this replication for fast local access. At the same

time, as more replicas are added across the world, the company is also able to increase the overall

throughput of their system.

4 1. OVERVIEW

Figure 1.4: Primary copy approach

Cluster and wide area replication are not the only replication conﬁgurations. For example,

assume the company also sells their puppets to toy stores and large department stores.Its saleswomen

traverse the country, packed with their laptops to show the products to these stores and sell them in

large scale. For that, they replicate at least parts of the database onto their laptops. This is a scenario

where replicas are often in a disconnected mode, and the different replicas have quite different scale.

Nevertheless, the purpose of replication remains the same: data remain available for the sales people

although no network connection might exist, and the access is fast because it is local.

1.2 CHALLENGES

Despite its advantages, replication is not a straightforward technique to apply, and there are many

hurdles to overcome before one has a suitable replication solution that ﬁts the application require-

ments. We will discuss some of the issues in this book. At the forefront will be replica control:

assuring that data copies remain consistent. Other issues are the architectural design options and

autonomic support to provide self-management.

1.2.1 REPLICA CONTROL

When a data item is updated, its physical copies need to be updated. As easy as this might sound,this

task, called replica control, is not a straightforward approach as there are many possible approaches,

each having its advantages and its drawbacks depending on the application and the conﬁguration.

Let us illustrate this with an example. Assume our puppet company has decided to deploy a

cluster of database replicas as depicted in Figure 1.4.Each node maintains a full copy of the database.

When a client request arrives, it is redirected to one of the replicas that controls its execution. In

most applications, there are two major request types: update requests, such as purchase() in the

ﬁgure, update at least one data item; and read-only requests, such as check-status(), only read

1.2. CHALLENGES 5

data items. Our company employes a Read-one-write-all (ROWA) replication strategy: the update

of a data item is performed at all replicas, while a read operation accesses a single replica. ROWA

can be implemented in various ways. The fundamental differences between existing approaches lie

in where and when copies are updated [Gray et al., 1996]. In regard to where, our company uses a

primary copy approach.There is one database replica that is considered the primary (replica). It holds

the primary copy of the database. The other replicas hold secondary copies and are called secondary

(replicas). All update requests are sent to the primary replica and are ﬁrst executed there. An update

request might read and write several data items. All writes are forwarded to the secondaries where

they are also executed. Read-only requests can be executed at the primary or the secondaries. They

can execute completely locally without coordination with other replicas.

In regard to when copies are updated, our company uses an eager approach, also referred to

as synchronous replication. The secondaries apply the changes to their own copies immediately when

they receive them, and then send a conﬁrmation to the primary. Only when the primary knows that

all secondaries have the changes, it conﬁrms to the user that the execution was successful.

Primary copy vs. update anywhere. The use of a primary replica forces all updates to be executed

ﬁrst at a single node.This simpliﬁes the coordination of concurrent update requests. However, it has

several disadvantages. For example, the primary can become a bottleneck. The alternative is to use

an update anywhere approach (also called update everywhere). Each replica accepts both update and

read-only requests and is responsible for their execution. While it avoids the pitfalls of the primary

copy approach, it has its own problems. In particular, it is much harder to guarantee consistency as

data copies might now be updated concurrently at different replicas.

Eager vs. lazy. By using eager replication, the primary only returns a conﬁrmation to the user once

all secondaries have the updates executed. Thus, copies are “virtually" consistent. However, clients

might experience prolonged response times due to the replication coordination.Especially with wide

area replication, this can become a serious problem. Also network connectivity can be spotty in wide

area networks, and the entire service might render unavailable if one replica is not reachable due to

network problems.The alternative is to use lazy replication, also called asynchronous replication. With

lazy replication, an update request is completely executed at one replica, which propagates the writes

to the other replicas after returning a conﬁrmation to the client.Thus, the coordination tasks do not

affect the user. However, maintaining consistency is more difﬁcult, as the same update takes place

at different times at the various replicas.

Additionally, when lazy replication is combined with update anywhere, two updates concur-

rently submitted to two replicas can update the same data item and succeed. Later,when the updates

are propagated, the system has to detect such conﬂict, possibly undo one of the updates despite the

fact that the client was already informed that the update was successful.

Transactions. Although we have not yet mentioned it, but to many readers, it will probably already

be obvious that many of the applications that require replication will also require transactions and

their properties – in particular atomicity, isolation and durability. In fact, it is pretty straightforward

6 1. OVERVIEW

to map the execution of a client request to a transaction.Each request reads and/or writes several data

items.From the outside,the execution of the request should appear as one logical execution unit.That

is exactly the deﬁnition of a transaction. A transaction is a user-deﬁned sequence of read and write

operations on data items, and the system provides a set of properties for their execution. Atomicity

guarantees that a transaction either executes entirely and commits, or it aborts not leaving any

changes in the database. Thus, database systems provide rollback mechanisms to abort transactions

and provide distributed commit protocols for distributed transactions, i.e., for transactions that

access data items residing on different nodes. Isolation provides a transaction with the impression

that no other transaction is currently executing in the system. Concurrency control mechanisms

such as locking are in charge of that. Durability guarantees that once the initiator of the transaction

has received the conﬁrmation of commit, the changes of the transaction are, indeed, reﬂected in

the database (they can, of course, later be overwritten by other transactions). Sophisticated logging

protocols guarantee durability despite individual node failures.

Replication does not make it easier to achieve these properties. In fact, replica control, atomic

commit protocols and concurrency control often work tightly together to let a replicated system

appear as a single transactional system. In this book, transactions will be ﬁrst-class citizens in con-

sidering and analyzing replica control algorithms. Note that while the next chapter describes the

transactional properties in more detail, we assume the reader to be familiar with transactions and

the basic mechanisms to implement them. Appendix A provides a short introduction if this is not

the case.

In total, Chapters 2, 3, 6, 7 and 8 are dedicated to replica control. Chapter 2 introduces con-

sistency criteria, extending the traditional atomicity, consistency, isolation and durability properties

of transactions to a replicated environment. Chapter 3 provides a ﬁrst introduction to some basic

replication protocols exploring in more detail the design choices eager vs. lazy, and primary copy

vs. update anywhere. The following chapters then discuss individual replica control strategies in

more detail. Chapter 6 is dedicated to eager replication. As snapshot isolation has become a very

popular concurrency control mechanism in recent years, we dedicate the full Chapter 7 to it. Finally,

Chapter 8 focuses on lazy replication.

1.2.2 OTHER ISSUES

Transforming an abstract replication solution into a concrete implementation is not a straightforward

endeavor. There are many design choices when architecting a solution for a concrete environment.

In Chapter 4, we present several important architectural patterns. One important issue is where the

replication logic is implemented: within the database system or as an external middleware layer.

The choice has strong inﬂuence on the replica control algorithms, performance, and maintainability.

Another question is how write operations are actually executed at the replicas. Efﬁcient handling

is crucial as they have a major impact on the scalability of the system. Partial replication is another

aspect. With partial replication, each data item might only be replicated on some of the nodes.

The idea is to reduce update costs. An update has to be applied to all copies of a data item. The

1.2. CHALLENGES 7

more copies exist, the higher is the update load in the system. Partial replication provides a tradeoff

between providing enough copies to be able to distribute read requests and keep the update costs

low.

Chapter 4 also introduces the main ideas behind using group communication systems to support

database replication. Group communication systems provide powerful multicast and group mem-

bership protocols that turn out to be very useful to manage a replicated system and support replica

control.

Chapter 5 discusses performance.We do not provide any performance comparisons of the many

replication approaches that exist, as they often depend on speciﬁc conﬁguration and engineering

details. But as performance analysis plays such a crucial role in building the right solution, we do not

want to completely ignore it. Therefore, we present a simple analytical model that provides insights

into how far a replicated database system can actually scale. We only consider a few parameters, but

they already indicate the level of variation among design choices, and how small optimizations can

have a huge inﬂuence on the performance.

Chapter 9 presents the self-properties a replicated system should provide. A replicated system

is never static. Nodes might fail, new nodes might be added to the system, and the load must be

dynamically distributed across the nodes. Chapter 9 describes how a replicated system can manage

these tasks in an autonomic way. It describes how a replicated system can be self-healing by automat-

ically removing failed nodes from the system and recovering them after restart, self-optimizing by

autonomously distributing varying load across replicas, and self-provisioning by determining dynam-

ically how many nodes are required in order to handle the current workload. These self-properties

are the fundamental building blocks for elastic computing,as it is now required for cloud computing.

Finally, Chapter 10 brieﬂy outlines other topics related to database replication that are out of

the scope of this book. For instance,databases are typically deployed as the backend-tier of multi-tier

architectures, and data are often distributed across all tiers. Replication of any of the tiers should

be coordinated with the other tiers. This chapter also shortly outlines other domains, such as data

replication in mobile environments and peer-to-peer systems.

剩余153页未读，继续阅读

halfho

粉丝: 0
资源: 18

数据库复制：理论与实践

db2 data replication

Oracle TimesTen In-Memory Database Replication Guide 11g Release

DB - Middleware-based Database Replication.pdf

Microsoft SQL Server Replication

undo log,redo log,binlog

docker 配置mysql 双主双从加读写分离操作，详细到每一步

sqlserver实时同步mysql

oracle数据备份

在centos7中部署replication

jdbc:mysql:replication 读写分离配置

最新资源