实际操作中需要自己手动 执行docker run imageid，而且执行完，会一直wait ，需要另外窗口去执行接下来的操作

以1.14版本为例，主要支持的源和目标如下
支持的源端：mysql
支持的目标端: kafka,rabbitmq,rocketmq,es6,es7,hbase,kudu,mysql,oracle,postgresql,sql server

一直就是Waiting for console to start
[root@bi-cloud-canal01 cloudcanal]# sh startup.sh
No clougence_mysql_volume is in use, we will create clougence_mysql_volume…
clougence_mysql_volume
cloudcanal docker images are already in use.
cloudcanal-network is already in use.
cloudcanal is starting…
docker-compose.log is already in use.
View output from containers.

Usage: logs [options] [SERVICE…]

Options:
–no-color Produce monochrome output.
Unsupported config option for services service: ‘prometheus’
Waiting for console to start
…
Waiting for console to start
…
Waiting for console to start
…
Waiting for console to start
…

您好，canal运维控制台是支持集群化运维的。一般可以 按照如下操作：

创建集群
498575cf-c722-473e-9243-fda5910c1faa-image.png 添加server到刚才创建的集群
33eb747f-859f-4532-a1e9-81e87b4b1aeb-image.png

这里主要注意：一个集群的所有server会共享一份全局canal.properties配置

另外关于控制台的使用可以参考github的官方资料：https://github.com/alibaba/canal/wiki/Canal-Admin-Guide

@微希夷 不好意思，回复有点晚。

private CustomFieldV2 isDel_0 = CustomFieldV2.buildField(“is_del”, 0, Types.TINYINT, false, true, false);

把最后一个字段isUpdated 改成true.

@神经蛙-0 打开脚本，把检查的那一行注释下。可能有shell兼容问题

这个报错是你消息体过大了，可以尝试下如下的方式：

修改 canal/conf/canal.properties配置，调整更大的值 canal.mq.maxRequestSize = 10485760 修改kafka/config/producer.properties ，调整更大的值 max.request.size=12695150 修改kafka/config/server.properties ，调整更大的值 message.max.bytes=12695150 重启服务

首先源端 mysql binlog 必须是工作在 row 模式下，这个是 CloudCanal 的工作基础。

基于此前提下批量清理 delete 会 mysql 被拆分为不同的 event，在 CloudCanal 上可以选择不订阅 delete 事件。 即可达到要求，但同时也会丢失所有 delete 事件的同步。

您好，是可以同步DDL的。可以看下canal.properties中的配置

canal.instance.filter.query.ddl

官方文档关于配置的说明可以参考：https://github.com/alibaba/canal/wiki/AdminGuide

超时了 检查下网络吧

你使用的jdk版本能给下吗？还有能否查看下你机器的可用内存情况。这个一般是剩余内存不足导致分配失败，可以适当减少下下startup.sh启动脚本中jvm分配的堆大小。
fbfbdd9f-7c2f-4510-b123-3898024c48a0-image.png

update data_task_fsm set active=0 where id=7; 就可以停止了

已经私聊做过一些沟通，根据用户反馈的日志信息，怀疑是rabbitmq server重启导致，日志时间匹配。rabbitmq client有个配置AutomaticRecoveryEnabled可以设置下，断连可以自动恢复连接的

可以参照下这个帖子，在社区提问下先。麻烦提供下异常信息和日志信息。https://www.askcug.com/topic/142

这个canal可以控制的，你可以通过调整batch size等手段来调节发送的频率的。另外es如果消费不过来，建议也有先评估下这种情况是否合理。

报错原因1：kafka的配置文件config/server.properties中listeners=PLAINTEXT://your.host.name:9092以及advertise.listeners=PLAINTEXT://your.host.name:9092没有配置，导致canal无法与kafka进行socket通信。
解决方案：补充上述两项配置，重启kafka即可。

报错原因2：canal的配置文件conf/canal.properties中kafka.bootstrap.servers = x.x.x.x:9092没有把所有的kafka节点配上。报错是因为只配了一台kafka节点，而我是以集群模式启动了三个kafka节点。
解决方案：修改conf/canal.properties中为kafka.bootstrap.servers = x.x.x.1:9092,x.x.x.2:9092,x.x.x.3:9092，重启canal即可。

因为你的上下文描述不够详细，我假设你源端字段是个varchar类型，你将数组内容存储到源端数据库后默认按照逗号分隔。

这样可以考虑在从kafka接受消息之后，自己实现一个方法，将收到的字符串内容，按照分隔符进行拆分，生成一个数组对象，然后直接写入ES。es的字段本来就支持接收数组的写入，这个可以参考es官方文档：[Arrays]
(https://www.elastic.co/guide/en/elasticsearch/reference/current/array.html)
1dd02f7a-838d-45e4-9460-38c813ebd445-image.png

这个问题本质是序列化方式的选择:

json: 优点主要是使用简单，可读性好。json处理起来也非常容易 二进制：二进制传输取决于你具体用什么序列化框架了，不同的二进制序列化方式有不同的优缺点。但是总体上相比json，二进制的序列化方式一般会在性能、数据大小方面(数据小，紧凑可以减少网络I/O开销)相比json有更好的表现。这块内容感兴趣的话可以参考以下网上的文章。例如美团分享的一个博客《序列化和反序列化》

可以参考下博客区的文章《Canalv1.1.4版本搭建HA集群
》 看了之后还有问题可以直接再回复哈~

你们hbase有开启鉴权的话能否贴下现在已经给哪些用户授权了？用已经授权的用户来启动canal进行数据访问~