TimesTen 数据库复制学习：13. 设置复制系统

设置复制环境

本章全部适用于classic复制，只有少部分适用于ASP复制。

创建数据库

保持源数据库存在，源复制表存在，目标数据库的DSN存在。然后建立目标的表：
* 若是AWT复制，目标表通过ttRepAdmin -duplicate 建立
* 若是Classic复制，目标表通过SQL建立

复制数据库的连接属性

DatabaseCharacterSet ： 必须相同，复制不字符集转换
ReplicationParallelism & ReplicationApplyOrdering ：并行复制
ReceiverThreads ：目标数据库上的日志并行apply

配置并行复制

缺省复制时，在源数据库上只有一个log reader(传输线程)，在目标数据库上只有一个log applier(接受线程)。可以配置多个线程并行执行以提升性能。

并行复制可以保证交易提交顺序和交易依赖性。

Parallel replication enforces transactional dependencies and applies changes in commit order.

有两种并行复制策略，都通过设置属性ReplicationApplyOrdering 和 ReplicationParallelism 实现。由于此二属性为DataStore属性，因此并行复制必须在创建数据库时建立。

自动并行复制

自动并行复制通过设置 ReplicationApplyOrdering=0，缺省就是打开的。
缺省 ReplicationParallelism =1 ，可以设置 ReplicationParallelism 为2-32之间值设定并行传输和并行apply的线程数。此数字不能超过LogBufParallelism的一半

在TimesTen中，AWT缓存组也是一种复制，只不过是从TimesTen到Oracle。简单来说就是用CacheAWTParallelism 替代了ReplicationParallelism做设置

用户定义的自动复制

用户定义的自动复制只适用于classic 复制。
这种复制不考虑交易依赖性，因此吞吐量可以提高，例如仅是insert。
简单来说，就是每一个连接都匹配一个track。因此除定义前面所说的参数外，即ReplicationApplyOrdering = 1，ReplicationParallelism > 1，还需定义ReplicationTrack。
由于用的较少，这里不再赘述。

几个配置参数：

call ttconfiguration;

< ReplicationApplyOrdering, 0 >
< ReplicationParallelism, 1 >
< ReplicationParallelismBufferMB, 64 >
< ReplicationTrack, -1 >

管理复制数据库的交易日志

有专门的subdaemon (Flusher)负责定期将log buffer中的内容写磁盘。可以是同步写或异步写。log buffer的大小由LogFileSize 定义。缺省为32M

如果LogFlushMethod=1 (缺省)，则所有的写盘是异步的(buffer write); 如果LogFlushMethod=2，则所有的写盘是同步的，保证durable commit。

除了定期写外，应用也可以触发将log buffer的内容写盘，例如：
* ttDurableCommit 过程
* 数据库复制时，如果源数据库定义了TRANSMIT DURABLE(缺省)-其实就是no return 和 return receipt，则会先写盘，然后再传输。
* 即使没有定义TRANSMIT DURABLE，例如return twosafe，复制代理也会定期写盘(100ms或日志累积到256k)。

在非复制系统中，日志会在checkpoint截断；而在复制系统中，只有当源数据库确认被目标端完全处理后，日志才会被清理。

In a replicated database, transactions remain in the log buffer and transaction log files until the master replication agent confirms they have been fully processed by the subscriber. Only then can the master consider purging them from the log buffer and transaction log files.

当目标数据库无法联络，日志就会不断累积，可用ttLogHolds检查复制日志的阻塞。

与日志相关的连接属性：
1. LogBufMB - 日志buffer大小，满时会写盘，最小值=LogBufParallelism *８M
2. LogFileSize - 单个日志文件的大小，满时会新生成日志文件
以上两个属性越大性能越好
3. log failure threshold - 超过此值就会将目标数据库设置为failed 状态（如果状态为failed，后续只能从主库通过ttRepAdmin -duplicate克隆）

可以通过ttBookmark 查看源库和复制库的日志差异

加载复制策略到数据库

create replication 或
create active standby pair

从源数据库克隆复制库

ttRepAdmin -duplicate 实现
克隆数据库必须满足以下条件：
* instance administrator 执行复制操作
* 两个数据库的instance administrator必须一致
* 提供一个具有ADMIN权限的用户
* 目标DSN不能有C/S特性 ???

克隆数据库执行的步骤如下：
1. 创建复制scheme，scheme中包含目标数据库
2. 启动复制代理
3. 在源数据库，建立具有ADMIN权限的用户

配置多个目标库

Classic复制可以有128个propagator，每个propagator可以有128 subscriber。
ASP复制可以有 127个 read-only subscribers

如果配置的目标库较多，需要保证：
* 加大log buffer size，保证SYS.MONITOR中的LOG_FS_READS为0或近似于0，这表示磁盘读较少
* 由于每一个目标库都需要一个线程，因此需要有足够的CPU

跨版本数据库复制

基本不支持。

启停复制代理

ttAdmin -repStart masterDSN
ttAdmin -repStart subscriberDSN
或者
ttIsql masterDSN
Command> call ttRepStart;
Command> call ttRepStop;

replication 代理重启策略：

通常是manual，也可以设置成auto，即timesten daemon启动时自动启动
例如：ttAdmin -repPolicy manual DSN

设置目标数据库的复制状态

subscriber (目标)数据库的复制代理的状态在master数据库中记录，可以通过ttRepAdmin -state或ttRepSubscriberStateSet 设置。

有四个状态: start, pause, stop, failed，状态说明如下：

设置命令示例

ttRepAdmin -dsn masterds -receiver -name subscriberds -state stop 
或
Command> CALL ttRepSubscriberStateSet('repscheme', 'repl', 'subscriberds', 'system1', 2);

参考

• A description of how the Log Buffer Flusher works (Doc ID 392247.1)