Otter容器化部署问题总结

1、docker部署时网页链接使用了docker 容器 ip，导致不通

将 网页链接使用的域名和端口通过环境变量传入覆盖下，需要修改app.sh

覆盖otter.properties文件中的otter.domainName和otter.port

2、使用root账号启动JVM

解决 create navtive thread 异常问题

官方的app.sh 脚本使用的是admin账号操作的，默认 ulimit=1024，日志中出现 ：java.lang.OutOfMemoryError: unable to create new native thread

3、Canal配置时最好开启心跳(前提：在源库上建立retl库)

这个心跳可以解决一个问题：如果数据库长时间没有数据变更，那么同步进度中的位点信息就不会更新，它记录的是上一次有数据变更时的位点信息，假如你的binlog只保留24小时，过期后被删除了，那么就会报找不到binlog的异常，卡住通道。

4、zookeeper 数据丢失后 ，进入manger系统报错

现象：

Problem accessing /channel_list.htm. Reason:    Failed to invoke Valve[#2/3, level 3]: com.alibaba.citrus.turbine.pipeline.valve.PerformTemplateScreenValve#2055833f:PerformTemplateScreenValve    Caused by: com.alibaba.citrus.webx.WebxException: Failed to execute screen: ChannelList    Caused by: org.I0Itec.zkclient.exception.ZkNoNodeException: org.apache.zookeeper.KeeperException$NoNodeException: KeeperErrorCode = NoNode for /otter/channel/2/1/process    Caused by: org.apache.zookeeper.KeeperException$NoNodeException: KeeperErrorCode = NoNode for /otter/channel/2/1/process    com.alibaba.citrus.webx.WebxException: Failed to execute screen: ChannelList

原因：zk里面的数据丢失了

解决方法：访问如下地址进行数据恢复

http://127.0.0.1:8080/system_reduction.htm

5、canal 过滤表达式

解析关注的表，Perl正则表达式.
多个正则之间以逗号(,)分隔，转义符需要双斜杠(\) 
常见例子：
1.  所有表：.*   or  .*\..*
2.  canal schema下所有表：canal\..*
3.  canal下的以canal打头的表：canal\.canal.*
4.  canal schema下的一张表：canal.test1
5.  多个规则组合使用：canal\..*,mysql.test1,mysql.test2 (逗号分隔)
注意：此过滤条件只针对row模式的数据有效(ps. mixed/statement因为不解析sql，所以无法准确提取tableName进行过滤)

6、自由门同步数据，表使用了联合主键，列的物理分布顺序和主键顺序不一致，导致反查数据失败

#这是生成的sql样式
insert into retl.retl_buffer(ID,TABLE_ID, FULL_NAME,TYPE,PK_DATA,GMT_CREATE,GMT_MODIFIED) 
(select null,0,'ttk_data_dev_0015.es_user_cust','I', concat(agencyId,char(1),roleId,char(1),customerId,char(1),sysUserId) ,now(),now() from ttk_data_dev_0015.es_user_cust);

以上报错是因为利用了 information_schema.key_column_usage和information_schema.table_constraints获取的主键信息并按从小到大排序，但是与otter的不一致，所以出错。otter中使用了  information_schema.column表取出的主键顺序，要解决这个问题，需要换成 从 information_schema.column表取主键信息。

7、库里有一百来张表，想排除某几张表的同步，该如何配置？

有两种方法：

第一种方法：配置canal的过滤器

canal管理-》canal编辑-》填写过滤表达式

第二种方法：配置数据表时使用正则表达式

第三种方法：在如下位置添加自定义过滤器：

Channel管理  >  Pipeline管理  >  映射关系管理  >  映射关系信息

用Event Processor:


 package com.ttk;


import java.util.Arrays;
import java.util.List;
import com.alibaba.otter.shared.etl.extend.processor.EventProcessor;
import com.alibaba.otter.shared.etl.model.EventData;


public class DescMessageEventProcessor implements EventProcessor {


    //黑名单
    List<String> excludeTable = Arrays.asList(
        "ba_currency_daily"
    );
    //白名单
    List<String> includeTable = Arrays.asList(
        "edf_org"
    );


    @Override
    public boolean process(EventData event) {
        return includeTable.contains(event.getTableName());
    }
}

8、docker部署 manager和node

manager要先启动，配置好node信息，再启动node

nid通过环境变量传入Node容器，相同NID的容器只能启动1份

10、使用正则表达式批量配置需要同步的表信息

11、node节点监控原理：(和hadoop/hbase原理基本一致，利用zookeeper)

1）每个node在启动完成后，都会在zookeeper中创建一个Ephemerals节点(此节点特点，当node节点发生crash之后，与zookeeper建立的sesstion因为没有心跳，超过一定时间后就会出现SesstionExpired，然后zookeeper会删除该节点)

2）manager监听整个node节点列表的变化，任何一个node节点的消失，都会收到zookeeper watcher通知，与内存中上一个版本进行比较，判断出当前消失的node节点

3）针对该消失的node节点，会有一段保护期(因为可能正常的发布，会关闭node，同样会触发该watcher)，如果该node在保护期内重新启动了，则不做任何处理。默认保护期为90秒

4）如果保护期内node节点未正常启动，说明node是异常crash，通过查询配置，找到使用了该node的所有同步任务，对每个同步任务发起一个RESTART指令，让所有同步任务重新做一次负载均衡选择，避免挂死在老的node上，一直死等其结果返回。

12、Otter扩展性

EventProcessor接口 : 自定义数据处理，可以改变一条变更数据的任意内容

FileResolver接口 : 解决数据和文件的关联关系

13、同步模式配置

a. 同步一致性

基于数据库反查 (简单点说，就是强制反查数据库，从binlog中拿到pk，直接反查对应数据库记录进行同步，回退到几天前binlog进行消费时避免同步老版本的数据时可采用)

基于当前日志变更 (基于binlog/redolog解析出来的字段变更值进行同步，不做数据库反查，推荐使用)

（同时binlog消息中也有完整的其它字段信息）

b. 同步模式

行模式 (兼容otter3的处理方案，改变记录中的任何一个字段，触发整行记录的数据同步，在目标库执行merge sql)（全部字段更新一遍，因为无论是基于数据库反查还是当前日志变更，都有完整的字段信息）

列模式 (基于log中的具体变更字段，按需同步（你更新了哪个字段，我就只更新哪个）)

c. 特殊组合：(同样支持)

基于数据库反查+列模式（这个好理解，虽然我反查了全部列数据，但只更新本次变更的列数据）

基于当前日志变更+行模式（这个的疑问就是基于当前日志变更能否得到全量行数据，我通过观察canal的消息看到里面是有全量行数据的，所以这个也就可以理解了，但是这个全量行数据只是产生binlog那一时刻的快照数据）

14、同步进度

mainstem状态：代表canal模块当前的运行节点(也即是binlog解析的运行节点，解析会相对耗jvm内存)

position状态：当前同步成功的最后binlog位点信息 (包含链接的是数据库ip/port，对应binlog的位置，对应binlog的变更时间此时间即是计算延迟时间的源库变更时间)

同步进度：每个同步批次会有一个唯一标识，可根据该唯一标示进行数据定位，可以查看每个批次的运行时间，找出性能瓶颈点

15、otter在zookeeper中注册的信息