TimesTen 数据库复制学习：1. TimesTen复制概述

本文为TimesTen数据库复制系列的第一篇。

什么是复制

复制就是在多个数据库中存在多份数据拷贝，对性能影响最小的同时保证数据高可用，除了数据恢复外，还可以均衡工作负载，以最大化性能和实现滚动升级和维护

TT复制的实现是在master和subscriber数据库都有复制代理，一个负责读，一个负责加载，数据在rep agent间传递

TT推荐的方法是ASP(active standby pair)，TT支持复制整库，部分表，cache group, sequence等。ASP是唯一支持复制cache group的方案

TT也支持复制DDL

复制兼容性的要求

必须同平台，同字节顺序。

虽然可以复制同一主机上两个库，但最佳建议是不同主机上的两个库

复制的库必须具有相同字符集(DatabaseCharacterSet)和数据类型模式(TypeMode，缺省为Oracle)

复制代理

通过主机名和文件系统路径名可以唯一确定一个库，rep agent之间通过TCP/IP socket通讯

The replication agent on the master database reads the records from the transaction log and forwards any detected changes to replicated elements to the replication agent on the subscriber database. The replication agent on the subscriber database then applies the updates to its database. If the subscriber agent is not running when the updates are forwarded by the master, the master retains the updates in the transaction log until they can be transmitted.

复制传输模式

支持三种模式，按性能影响和数据一致性由小到大为：
1. NO RETURN (缺省，异步模式)
2. RETURN RECEIPT (对方接到即返回)
3. RETURN TWOSAFE (对方接到，并提交后返回)

缺省模式(异步)

缺省模式提供最佳性能，但存在数据丢失的风险。应用更新主库后，无需等待更新传递和加载到订阅库。主库和订阅库之间有内部机制确定更新被成功传递和加载，和应用完全独立。

几点说明：
* 应用在交易提交，然后写入log buffer后才可以返回，也就是完成步骤2后。
* replication agent负责将log buffer的数据flush到磁盘和传递到subscriber
* 在subscriber返回接受成功后，replication agent就可以删除不必要的日志了
* 更新的传递采用批量模式，以提高效率。

Return receipt(准同步)

应用阻塞，直到对方接受到更新后即可返回

几点说明：
* 对方接收到是指在内存中接受到即可，而后续写入log buffer和持久化不计在内
* 如果10秒内未返回receipt，应用可继续，此超时时间可配置。
* 超时的原因可能是网络，复制代理失效等

Return twosafe (全同步)

应用阻塞，直到交易在对方提交后方可继续。

几点说明：
* 交易先在备点提交再在主点提交
* 主点的复制代理在传递变化到备点前，并不需要将log buffer中的内容flush到磁盘。这点是和异步和return receipt是不同的。这也是为何return twosafe的性能其实是比return receipt要快的原因。
> Transmission of return twosafe transactions is nondurable, so the master replication agent does not flush the log records to disk before sending them to the subscriber, as it does by default when replication is configured for asynchronous or return receipt replication.
* 超时可配置，缺省为10秒。超时后可以设置为重新提交或无条件提交（不顾备点未接受到数据）

数据库复制模式(replication schemes)

这里的replication scheme称为replication pattern更好理解。

Active Standby Pair(主从组复制)

Active Standby Pair(以下简称ASP)是TimesTen最常用的的复制模式。
ASP是整库复制，也就是说replication element只能是datastore，尽管你可以排除掉某些表。

ASP中包含3个成员，分别是两个master和一组只读的subscriber（最多127个）。
其中active和standby都是master，只不过active为可读写，standby为只读。

几点说明：
* 既然ASP是Pair，说明active和standby是成对出现的，1个active对应多个standby是不支持的。
* 如果standby失效，active可以直接向subscriber复制；如果standby恢复，会先和active同步，然后重新承担起向subscriber复制的责任。

Classic replication（传统复制）

Classic复制和ASP不一样，既可以是整库复制，也可以是选择表作为replication element。
在Classic复制中，master和subscriber都是可读写的（待后续实验确认）

整库和选择性复制

以下为整库复制：

以下为选择性复制，可以复制同一个对象到多个目标，也可分别复制不同的对象到目标，如下图：

单向和双向复制

单向复制是1个master对应多个subscriber，而双向复制是指一个数据库既是master也是subscriber。

双向复制也有两种用法，一个是用于负载分担，即两个库分布承担不同的服务，如下图：

另一种是复制均衡，即两个库承担相同的服务，如下图：

直接复制和中转复制

这种模式考虑的更多的是网络带宽的影响和复制负载的分担。

下图为直接复制：

下图为中转复制，propagator和subscribers在一个网络内：

下图为复制负载分担的中转复制：

缓存组与复制

缓存组的复制只支持Active Standby Pair一种复制模式。支持复制的缓存组包括AWT和只读缓存组。

AWT缓存组的复制（一个Oracle数据库）

上图我们先关注左边active和standby两个库，更新是通过standby传递到Oracle数据库的。目的是为了减轻active master的负担。

如果master失效，standby会承担业务读写，并仍保持与Oracle数据库的同步。

如果standby失效，或者standby还未建立，这时active可以同时承担接受业务读写和与Oracle同步数据的职责。

standby变为新的active时, TimesTen会重写配置缓存组，使得新的standby承担起与Oracle同步的任务。

再来看看右边从standby到只读subscriber的复制，在只读subscriber上的复制目标不是cache group中的表，而只是普通的non-cache表。

AWT缓存组的复制（两个个Oracle数据库）

如果说上一种方式是针对HA，因为active和master是共享Oracle数据库的。那么此处的方式则面向D/R，因为主点和备点分别有不同的Oracle数据库。

只读缓存组的复制

在这种复制模式中，active 数据库自动同步来做Oracle的数据。其实standby也配置了autorefresh，只不过处于pause状态。

如果master失效，standby会接管，同时autorefresh状态改为ON。

由于TimesTen不仅会跟踪active与Oracle的同步状态，同时也会跟踪active和standby的同步状态，因此，当standby接管失效的master时，并不需要从头开始与Oracle同步。

不过对于只读缓存组的复制，如果master失效后，再配置新的master应该不是很容易。

序列与复制

TimesTen支持Sequence的复制，通常Sequence用来作为主键，唯一确定一行。在这种场景中，Sequence比TimeStamp更常用。

外键和复制

You may choose to replicate all or a subset of tables that have foreign key relationships with one another. However, the method for how to replicate the tables involved in the relationship differ according to the type of replication scheme.

Aging和复制

如果复制表定义了Aging策略，无论是基于时间戳还是LRU，那么：
* 源和目标的Aging策略必须一致
* 对于ASP，只有主点运用Aging策略，引起的数据删除通过复制传播到目标
* 如果不是ASP，则主点和备点分别运用自己的Aging策略
* 如果是AWT缓存组，Aging引起的数据删除并不传递到Oracle，这点其实与复制没关系，对于Aging来说，这是合理的行为。