canal支持mysql到clickhouse，本以为canal会把mysql dml语法转换成clickhouse dml语法，可是并没有。
clickhouse，tidb，mysql，这三个数据库都是现在在用的。准备了一些测试数据，测试一下读取数据的速度。
clickhouse不支持自增ID，primary key可以重复。这对于习惯了mysql的人来说，肯定很不爽。如果写入到mysql，mysql同步数据到clickhouse，然后从clickhouse来读，这样就很完美了。
采用MaterializeMySQL引擎局限性比较大，同步的表数据只能在clickhouse集群中的某一台机器上，这样集群资源不能充分利用。
我想达到目的，在clickhouse中创建Distributed+ReplicatedMergeTree+zookeeper来实现分布式库和表，然后能过canal把mysql数据同步到过去。这样能充分利用系统资源，也能克服clickhouse的弊端。
clickhouse不支持自增ID，primary key可以重复。这对于习惯了mysql的人来说，肯定很不爽。如果写入到mysql，mysql同步数据到clickhouse，然后从clickhouse来读，这样就很完美了。
数据量比较大的情况下，elasticsearch单表操作要比mysql快很多，全文检索也比mysql快很多。试用了一下阿里的canal，感觉还不错。
dm从上游mysql同步数据到tidb，如果报错就会导致同步中止。上篇文章写了zabbix 监控ticdc同步，本篇与上篇会有稍许的不同
mysql没有宕机，却收到这个邮件，有点莫名。
前面说到了通过dm server把mysql的数据同步到tidb，现在又为什么要把tidb的数据同步到mysql？
其实还是对tidb不太放心，就算把tidb当做正式数据库使用，也希望用mysql来兜底，观察一段时间后，如果不出问题就可以把同步停掉了，脱离mysql。
为啥要把mysql数据同步到tidb呢？
现有mysql的读写分离，也能满足oltp和olap的需求，但是因mysql不支持横向扩展，随着数据量的增加，越来越慢是迟早的事情。
因tidb是小众数据库，也不太敢冒然从mysql迁到tidb，所以就想把tidb做mysql的从库之一，以检测tidb的性能与稳定性。
一张表longtext字段比较多，导入数据时报错如下：
Row size too large (> 8126). Changing some columns to TEXT or BLOB or using ROW_FORMAT=DYNAMIC or ROW_FORMAT=COMPRESSED may help. In current row format, BLOB prefix of 768 bytes is stored inline.