brokercap / bifrost

Bifrost ---- 面向生产环境的 MySQL,MariaDB,kafka 同步到Redis,MongoDB,ClickHouse,StarRocks,Doris,Kafka等服务的异构中间件

Bifrost ---- 面向生产环境的 MySQL,MariaDB 同步到Redis,ClickHouse,Elasticsearch等服务的异构中间件

English

漫威里的彩虹桥可以将 雷神 送到 阿斯加德 和 地球

而这个 Bifrost 可以将数据 全量 , 实时的同步到 多个目标端

目标端支持

目标端	DDL	备注
Redis	NO
MongoDB	NO
MySQL	YES
ClickHouse	YES
Memcache	NO
RabbitMQ	YES
Kafka	YES	支持canal,debezium格式，以及kafka 消息字符串
ActiveMQ	YES
Http 自定义服务	YES
Hprose RPC 自定义服务	YES
StarRocks	YES	use mysql protocol
Doris	YES	use mysql protocol

源端支持

源端	全量	增量	格式	备注
MySQL	YES	YES	Binglog & Select	模式MySQL Slave&全版本
MariaDB	YES	YES	Binglog & Select	模式MySQL Slave&全版本
Percona	YES	YES	Binglog & Select	模式MySQL Slave&全版本
Kafka	NO	YES	string	将kafka数据作为一个queue_data字段进行处理
Kafka	NO	YES	canal	将canal的格式自动转成biforst格式进行处理
kafka	NO	YES	bifrost	Bifrost可以作为源写入到kafka,再由Bifrost消费kafka的数据
kafka	NO	YES	debezium	debezium将数据写入kafka，Bifrost消费kafka的数据自动转换处理
Mongo	NO	YES	oplog
kafka	NO	YES	customer json	支持自定义JSON格式数据转换Bifrost格式的功能
Mock	NO	YES	MySQL Binlog	对于OutPut插件开发的时候 ,不再需要部署MySQL等源端进行开发阶段的测试了

---

WIKI : https://wiki.xbifrost.com

---

Bifrost 特点

• 支持 MySQL,MariaDB 所有存储类型

• 界面化动态灵活配置不同的数据表及目标库

• 多种数据源,多种目标库支持

• 同时支持 增量 及 全量 数据同步

• 一个Binlog解析线程,多个目标库并行同步

• 宕机后重启自动恢复配置,位点精确控制

• 支持 Email 及 微信企业号等监控报警功能

• 提供第三方监控平台访问接口(Http Basic验证)HTTP API

• MySQL,ClickHouse 插件支持 DDL 同步

• 简单即可实现插件开发

源码下载

Github , Gitee

你的点击 star 就是对 Bifrost 最大的支持!!!

Bifrost在线界面体验

https://www.xbifrost.com/demo/goto.html

用户名： Bifrost

密码 : Bifrost123

Bifrsot Diagram

MySQL 版本（经过测试）

• 5.1.73

• 5.5.42

• 5.6.36

• 5.7.18

• 8.0.21

安装

编译

git clone https://github.com/brokercap/Bifrost.git

make install prefix=./target

二进制文件安装

wget https://github.com/brokercap/Bifrost/releases/download/v2.3.6-beta/bifrost_v2.3.6-beta_Linux-amd64-bin.tar.gz

tar -zxvf bifrost_v2.3.6-beta_Linux-amd64-bin.tar.gz

cd bifrost_v2.3.6-beta_Linux-amd64-bin/bin && chmod a+x ./Bifrost*

启动

./Bifrost-server start

停止

./Bifrost-server stop

界面管理

https://127.0.0.1:21036

用户名和密码是在 etc/Bifrost.ini 配置文件中配置的

默认用户名和密码

用户名：Bifrost

密码：Bifrost123

Docker启动

docker pull jc3wish/bifrost

mkdir -p /data/BifrostData

docker run -d -p21036:21036 -v /etc/localtime:/etc/localtime -v /data/BifrostData:/linux/data jc3wish/bifrost

配置

vim Bifrost.ini

[user]
#登入用户名和密码
#用户名在前，= 号后面是密码
Bifrost=Bifrost123
BifrostMonitor=Bifrost123

[groups]
#administrator 管理人员可以添加删除等操作
#monitor 只能查看数据
Bifrost=administrator
BifrostMonitor=monitor

[Bifrostd]
#log写到入的文件夹，默认为启动文件所在文件夹下的logs目录
#log_dir=/data/log/

#监听端口,默认 0.0.0.0:21036
listen=0.0.0.0:21036

#通过界面配置的信息保存文件夹,默认为启动文件所在文件夹下的data目录
data_dir=./

#设置同步给第三方服务的队列大小，默认5000
toserver_queue_size=10000

#通道队列的大小，默认1000
channel_queue_size=1000

#是否支持动态加plugin so 插件，默认为false
#这个参数只在 linux 下有效，其他平台全部为false
dynamic_plugin=false

#是否支持https
tls=true

#server.key 及 server.crt 相对于 Bifrost 的路径，也可以填绝对路径
tls_key_file=./etc/server.key
tls_crt_file=./etc/server.crt

#是否开启文件队列功能 true|false
file_queue_usable=false

#统计是否启文件队列的时间，单位毫秒
file_queue_usable_count_time_diff=5000

#file_queue_usable_count_time_diff 时间内内存队列被挤满的次数
file_queue_usable_count=10

#采用什么方式存储,默认文件方式
meta_storage_type=redis

#存储介质的连接地址
meta_storage_path=127.0.0.1:6379

#用于区别实例的名字
cluster_name=bifrostTestClusterName

#是否开启文件队列功能 true|false
file_queue_usable=false

#统计是否启文件队列的时间，单位毫秒
file_queue_usable_count_time_diff=5000

#file_queue_usable_count_time_diff 时间内内存队列被挤满的次数
file_queue_usable_count=10

#在没有数据的情况下,间隔多久提交一次插件,单位 秒
plugin_commit_timeout=5

#在同步出错的情况下,每2次重试之后 间隔多久再重试 ,单位 秒
plugin_sync_retry_time=5

生成https证书

参考证书生成

感谢相关依赖包提供者

• github.com/gmallard/stompngo
• github.com/hprose/hprose-golang
• github.com/Shopify/sarama
• github.com/bradfitz/gomemcache/memcache
• gopkg.in/mgo.v2
• github.com/streadway/amqp
• github.com/go-redis/redis/v8
• github.com/syndtr/goleveldb/leveldb
• github.com/ClickHouse/clickhouse-go
• github.com/olivere/elastic/v7

QQ群号： 70331601

捐赠

bifrost's Issues

报警设置未生效

使用的是数据导入到Clickhouse中，
设置好邮件报警后，测试邮件发送成功。

配置了表对表关系，把clickhouse服务停掉了，连接失败后并没有发送报警邮件。

将MySQL同步到elastic Bifrost 插件

将数据实时同步到 elastic

支持普通 模式和日志模式同步

1.普通模式
数据源里update和delete里，elastic里也相应的 update和delete操作

2. 日志模式
   不管数据源里是insert, update,delete，统一是以新增的方式同步到elastic

elastic 插件需要支持自定义索引名称及对 BIfrost 标签的功能

点击add后，不能进行取消操作，del功能直接就删表了，有点危险

支持大多数源数据库

支持大多数源数据库，常见的关系型数据库，Oracle，Mysql，postgresql

用户登入日志显示

管理人员可以查看到 所有用户的登入日志，包括密码错入的日志

binlog不消费

SUPER

为什么mysql数据库需要super权限 这样很多云数据库拿不到

Com_stmt_close没有关闭

[mysqld-5.5.17-log]Can't create more than max_prepared_stmt_count statements (current value: 16382)

binlog 不消费,web 后台显示running , log 最后一行显示 已经关闭 mysql 连接

日志文件

| 2020/10/10 02:00:56 jw monitor: parseEvent err:runtime error: index out of range [-1]
sync_1 | 2020/10/10 02:00:56 jw monitor: running
root@iZ2vch9tv2s5388awaj4r8Z:~/docker/bifrost# docker-compose logs --tail=100 sync
Attaching to bifrost_sync_1
sync_1 | created by github.com/brokercap/Bifrost/server.(*db).Start
sync_1 | /Users/apple/Desktop/WorkSpae/go/Bifrost/server/db.go:467 +0x56e
sync_1 |
sync_1 | 2020/10/10 02:16:32 jw monitor: parseEvent err:runtime error: index out of range [-1]
sync_1 | 2020/10/10 02:16:32 jw monitor: running
sync_1 | 2020/10/10 02:16:37 jw monitor: starting
sync_1 | 2020/10/10 02:16:37 jw monitor: running
sync_1 | 2020/10/10 02:16:37 binlog_checksum: true
sync_1 | 2020/10/10 02:16:37 root:root@tcp(mysql:3306)/new_julietswhisper ROTATE_EVENT mysql-bin.000005 0
sync_1 | 2020/10/10 02:16:37 goroutine 2443 [running]:
sync_1 | runtime/debug.Stack(0xc00036d110, 0x26, 0x0)
sync_1 | /usr/local/Cellar/[email protected]/1.14.9/libexec/src/runtime/debug/stack.go:24 +0x9d
sync_1 | github.com/brokercap/Bifrost/Bristol/mysql.(*mysqlConn).DumpBinlog.func2.1(0xc00014fd48)
sync_1 | /Users/apple/Desktop/WorkSpae/go/Bifrost/Bristol/mysql/binlog.go:578 +0xcb
sync_1 | panic(0xc617e0, 0xc000553ac0)
sync_1 | /usr/local/Cellar/[email protected]/1.14.9/libexec/src/runtime/panic.go:969 +0x166
sync_1 | github.com/brokercap/Bifrost/Bristol/mysql.(*eventParser).parseEventRow(0xc0000796c0, 0xc0004f5d10, 0xc0003e11e0, 0xc00034cf40, 0x7, 0x8, 0x0, 0x0, 0x0)
sync_1 | /Users/apple/Desktop/WorkSpae/go/Bifrost/Bristol/mysql/event_row.go:379 +0x526b
sync_1 | github.com/brokercap/Bifrost/Bristol/mysql.(*eventParser).parseRowsEvent(0xc0000796c0, 0xc0004f5d10, 0xe5, 0x10000c0001800f8, 0x0)
sync_1 | /Users/apple/Desktop/WorkSpae/go/Bifrost/Bristol/mysql/event_row.go:65 +0x381
sync_1 | github.com/brokercap/Bifrost/Bristol/mysql.(*eventParser).parseEvent(0xc0000796c0, 0xc0001aaa01, 0x41, 0x41, 0x0, 0x42, 0x0, 0xc0001aaa00, 0x0)
sync_1 | /Users/apple/Desktop/WorkSpae/go/Bifrost/Bristol/mysql/binlog.go:181 +0x935
sync_1 | github.com/brokercap/Bifrost/Bristol/mysql.(*mysqlConn).DumpBinlog.func2(0xc00014fd48, 0xc0000796c0, 0xc0001aaa00, 0x42, 0x42, 0xc00014fd38)
sync_1 | /Users/apple/Desktop/WorkSpae/go/Bifrost/Bristol/mysql/binlog.go:581 +0xa0
sync_1 | github.com/brokercap/Bifrost/Bristol/mysql.(*mysqlConn).DumpBinlog(0xc000d157a0, 0xc0001495c0, 0x10, 0x8ec3b3, 0xc0000796c0, 0xc000259330, 0xc00034a300, 0x0, 0x0, 0x0, ...)
sync_1 | /Users/apple/Desktop/WorkSpae/go/Bifrost/Bristol/mysql/binlog.go:582 +0x3fa
sync_1 | github.com/brokercap/Bifrost/Bristol/mysql.(*BinlogDump).startConnAndDumpBinlog(0xc0001ae420, 0xc00034a300)
sync_1 | /Users/apple/Desktop/WorkSpae/go/Bifrost/Bristol/mysql/binlog.go:863 +0x3d5
sync_1 | github.com/brokercap/Bifrost/Bristol/mysql.(*BinlogDump).StartDumpBinlog(0xc0001ae420, 0xc0003575a0, 0x10, 0xca008e4084, 0xc00034a300, 0x0, 0x0, 0x0)
sync_1 | /Users/apple/Desktop/WorkSpae/go/Bifrost/Bristol/mysql/binlog.go:741 +0x464
sync_1 | created by github.com/brokercap/Bifrost/server.(*db).Start
sync_1 | /Users/apple/Desktop/WorkSpae/go/Bifrost/server/db.go:467 +0x56e
sync_1 |
sync_1 | 2020/10/10 02:16:37 jw monitor: parseEvent err:runtime error: index out of range [-1]
sync_1 | 2020/10/10 02:16:37 jw monitor: running
sync_1 | parseEvent err:runtime error: index out of range [-1]
sync_1 | 2020/10/10 02:16:41 This.mysqlConn close ,connectionId: 329032
sync_1 | 2020/10/10 02:16:42 jw monitor: starting
sync_1 | 2020/10/10 02:16:42 jw monitor: running
sync_1 | 2020/10/10 02:16:42 binlog_checksum: true
sync_1 | 2020/10/10 02:16:42 root:root@tcp(mysql:3306)/new_julietswhisper ROTATE_EVENT mysql-bin.000005 0
sync_1 | 2020/10/10 02:16:42 goroutine 2443 [running]:
sync_1 | runtime/debug.Stack(0xc00030e6f0, 0x26, 0x0)
sync_1 | /usr/local/Cellar/[email protected]/1.14.9/libexec/src/runtime/debug/stack.go:24 +0x9d
sync_1 | github.com/brokercap/Bifrost/Bristol/mysql.(*mysqlConn).DumpBinlog.func2.1(0xc00014fd48)
sync_1 | /Users/apple/Desktop/WorkSpae/go/Bifrost/Bristol/mysql/binlog.go:578 +0xcb
sync_1 | panic(0xc617e0, 0xc000ac6660)
sync_1 | /usr/local/Cellar/[email protected]/1.14.9/libexec/src/runtime/panic.go:969 +0x166
sync_1 | github.com/brokercap/Bifrost/Bristol/mysql.(*eventParser).parseEventRow(0xc0000796c0, 0xc000411170, 0xc0000cc9a0, 0xc000a3b080, 0x7, 0x8, 0x0, 0x0, 0x0)
sync_1 | /Users/apple/Desktop/WorkSpae/go/Bifrost/Bristol/mysql/event_row.go:379 +0x526b
sync_1 | github.com/brokercap/Bifrost/Bristol/mysql.(*eventParser).parseRowsEvent(0xc0000796c0, 0xc000411170, 0xe5, 0x10000c0001800f8, 0x0)
sync_1 | /Users/apple/Desktop/WorkSpae/go/Bifrost/Bristol/mysql/event_row.go:65 +0x381
sync_1 | github.com/brokercap/Bifrost/Bristol/mysql.(*eventParser).parseEvent(0xc0000796c0, 0xc0002246e1, 0x41, 0x41, 0x0, 0x42, 0x0, 0xc0002246e0, 0x0)
sync_1 | /Users/apple/Desktop/WorkSpae/go/Bifrost/Bristol/mysql/binlog.go:181 +0x935
sync_1 | github.com/brokercap/Bifrost/Bristol/mysql.(*mysqlConn).DumpBinlog.func2(0xc00014fd48, 0xc0000796c0, 0xc0002246e0, 0x42, 0x42, 0xc00014fd38)
sync_1 | /Users/apple/Desktop/WorkSpae/go/Bifrost/Bristol/mysql/binlog.go:581 +0xa0
sync_1 | github.com/brokercap/Bifrost/Bristol/mysql.(*mysqlConn).DumpBinlog(0xc000d15e60, 0xc0001495c0, 0x10, 0x8ec3b3, 0xc0000796c0, 0xc000259330, 0xc00034a300, 0x0, 0x0, 0x0, ...)
sync_1 | /Users/apple/Desktop/WorkSpae/go/Bifrost/Bristol/mysql/binlog.go:582 +0x3fa
sync_1 | github.com/brokercap/Bifrost/Bristol/mysql.(*BinlogDump).startConnAndDumpBinlog(0xc0001ae420, 0xc00034a300)
sync_1 | /Users/apple/Desktop/WorkSpae/go/Bifrost/Bristol/mysql/binlog.go:863 +0x3d5
sync_1 | github.com/brokercap/Bifrost/Bristol/mysql.(*BinlogDump).StartDumpBinlog(0xc0001ae420, 0xc0003575a0, 0x10, 0xca008e4084, 0xc00034a300, 0x0, 0x0, 0x0)
sync_1 | /Users/apple/Desktop/WorkSpae/go/Bifrost/Bristol/mysql/binlog.go:741 +0x464
sync_1 | created by github.com/brokercap/Bifrost/server.(*db).Start
sync_1 | /Users/apple/Desktop/WorkSpae/go/Bifrost/server/db.go:467 +0x56e
sync_1 |
sync_1 | 2020/10/10 02:16:42 jw monitor: parseEvent err:runtime error: index out of range [-1]
sync_1 | 2020/10/10 02:16:42 jw monitor: running
sync_1 | parseEvent err:runtime error: index out of range [-1]
sync_1 | 2020/10/10 02:16:47 jw monitor: starting
sync_1 | 2020/10/10 02:16:47 jw monitor: running
sync_1 | 2020/10/10 02:16:47 binlog_checksum: true
sync_1 | 2020/10/10 02:16:47 root:root@tcp(mysql:3306)/new_julietswhisper ROTATE_EVENT mysql-bin.000005 0
sync_1 | parseEvent err:runtime error: index out of range [-1]
sync_1 | 2020/10/10 02:16:47 goroutine 2443 [running]:
sync_1 | runtime/debug.Stack(0xc00036dcb0, 0x26, 0x0)
sync_1 | /usr/local/Cellar/[email protected]/1.14.9/libexec/src/runtime/debug/stack.go:24 +0x9d
sync_1 | github.com/brokercap/Bifrost/Bristol/mysql.(*mysqlConn).DumpBinlog.func2.1(0xc00014fd48)
sync_1 | /Users/apple/Desktop/WorkSpae/go/Bifrost/Bristol/mysql/binlog.go:578 +0xcb
sync_1 | panic(0xc617e0, 0xc000037fa0)
sync_1 | /usr/local/Cellar/[email protected]/1.14.9/libexec/src/runtime/panic.go:969 +0x166
sync_1 | github.com/brokercap/Bifrost/Bristol/mysql.(*eventParser).parseEventRow(0xc0000796c0, 0xc000469920, 0xc0003e1b80, 0xc00034d280, 0x7, 0x8, 0x0, 0x0, 0x0)
sync_1 | /Users/apple/Desktop/WorkSpae/go/Bifrost/Bristol/mysql/event_row.go:379 +0x526b
sync_1 | github.com/brokercap/Bifrost/Bristol/mysql.(*eventParser).parseRowsEvent(0xc0000796c0, 0xc000469920, 0xe5, 0x10000c0001800f8, 0x0)
sync_1 | /Users/apple/Desktop/WorkSpae/go/Bifrost/Bristol/mysql/event_row.go:65 +0x381
sync_1 | github.com/brokercap/Bifrost/Bristol/mysql.(*eventParser).parseEvent(0xc0000796c0, 0xc0002ff451, 0x41, 0x41, 0x0, 0x42, 0x0, 0xc0002ff450, 0x0)
sync_1 | /Users/apple/Desktop/WorkSpae/go/Bifrost/Bristol/mysql/binlog.go:181 +0x935
sync_1 | github.com/brokercap/Bifrost/Bristol/mysql.(*mysqlConn).DumpBinlog.func2(0xc00014fd48, 0xc0000796c0, 0xc0002ff450, 0x42, 0x42, 0xc00014fd38)
sync_1 | /Users/apple/Desktop/WorkSpae/go/Bifrost/Bristol/mysql/binlog.go:581 +0xa0
sync_1 | github.com/brokercap/Bifrost/Bristol/mysql.(*mysqlConn).DumpBinlog(0xc000c1a3c0, 0xc0001495c0, 0x10, 0x8ec3b3, 0xc0000796c0, 0xc000259330, 0xc00034a300, 0x0, 0x0, 0x0, ...)
sync_1 | /Users/apple/Desktop/WorkSpae/go/Bifrost/Bristol/mysql/binlog.go:582 +0x3fa
sync_1 | github.com/brokercap/Bifrost/Bristol/mysql.(*BinlogDump).startConnAndDumpBinlog(0xc0001ae420, 0xc00034a300)
sync_1 | /Users/apple/Desktop/WorkSpae/go/Bifrost/Bristol/mysql/binlog.go:863 +0x3d5
sync_1 | github.com/brokercap/Bifrost/Bristol/mysql.(*BinlogDump).StartDumpBinlog(0xc0001ae420, 0xc0003575a0, 0x10, 0xca008e4084, 0xc00034a300, 0x0, 0x0, 0x0)
sync_1 | /Users/apple/Desktop/WorkSpae/go/Bifrost/Bristol/mysql/binlog.go:741 +0x464
sync_1 | created by github.com/brokercap/Bifrost/server.(*db).Start
sync_1 | /Users/apple/Desktop/WorkSpae/go/Bifrost/server/db.go:467 +0x56e
sync_1 |
sync_1 | 2020/10/10 02:16:47 jw monitor: parseEvent err:runtime error: index out of range [-1]
sync_1 | 2020/10/10 02:16:47 jw monitor: running
sync_1 | 2020/10/10 02:16:51 This.mysqlConn close ,connectionId: 329034

后台状态

补充说明

1. 后台日志显示mysql 断开连接后没有其他日志产生了, 且web后台显示的还是running 状态 (会重新连接, 日志没打印全)
2. binlog 已经不消费了, 一直重复这个错误 大概15s 出现一次 重启也没用, 除非我跳过这个位点
3. Bristol/mysql/event_row.go:379 +0x526b 该错误产生频率较高,不太了解mysql binlog 的数据包结构, 这个是属于正常情况吗
4. go version go1.15.2 linux/amd64

mysql to clickhouse 中文乱码

mysql库的字符集是gbk,源库支持设置字符集？

v1.6.4版本，同步多表，全量同步任务中断导致中断前正在同步的表不会继续

表名匹配模式为 abc* , 就是在全量任务的时候，正在同步abc1表的数据，还没同步完，然后我stop了全量任务以后，再start,全量任务会自动从abc2表开始，这种情况下，就会导致abc1表在全量阶段缺失了一部分数据

输出到kafka里，有大量空的commit数据在里面

Version:

• Bifrost Version: [e.g. v1.6.0-beta.03]
• Os Version: [e.g. CentOS Linux release 7.7.1908]
• Browse: [e.g. Chrome]

Describe the bug

A clear and concise description of what the bug is.

To Reproduce

Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Expected behavior

A clear and concise description of what you expected to happen.

Screenshots

If applicable, add screenshots to help explain your problem.

Additional context

Add any other context about the problem here.

报警配置, 带 - 的邮箱域名不能使用

如图

发件人收件人都不行

能否只允许insert操作

设想是用mysql做中间库，通过bifrost入库到clickhouse
从mysql同步到clickhouse的时候，需要定时删除mysql的数据防止数据源过大。
这样就需要bifrost忽略掉delete的操作，请问可以设置吗？

能否提供一个监控同步通道的接口名称？

能否提供一个监控同步通道的接口名称呀？我们想打算通过获取接口值进行监控通道状态。

连接 MySQL tls 功能支持

对 MySQL tls 连接功能支持

安装后配置数据源的时候点提交后页面显示空白

Version:

• Bifrost Version: [v1.6.2]
• Os Version: [ CentOS Linux release 7.6.1908]
• Browse: [Chrome]

2020/12/22 19:33:50 xgo doController: runtime error: invalid memory address or nil pointer dereference goroutine 170 [running]:
runtime/debug.Stack(0xc00072d498, 0xc02640, 0x126a130)
/usr/local/go/src/runtime/debug/stack.go:24 +0x9f
github.com/brokercap/Bifrost/admin/xgo.(*routeController).DoController.func1()
/mnt/hgfs/project/gopath/src/github.com/brokercap/Bifrost/admin/xgo/xgo.go:71 +0x78
panic(0xc02640, 0x126a130)
/usr/local/go/src/runtime/panic.go:969 +0x1b9
github.com/brokercap/Bifrost/admin/controller.(*DBController).Detail(0xc0002005a0)
/mnt/hgfs/project/gopath/src/github.com/brokercap/Bifrost/admin/controller/db_detail.go:26 +0x9e
reflect.Value.call(0xce4680, 0xc0002005a0, 0x2613, 0xcfc1be, 0x4, 0x0, 0x0, 0x0, 0xe0e9c0, 0xc0000316e0, ...)
/usr/local/go/src/reflect/value.go:476 +0x8c7
reflect.Value.Call(0xce4680, 0xc0002005a0, 0x2613, 0x0, 0x0, 0x0, 0xc0002005a0, 0x2613, 0xc0001a6660)
/usr/local/go/src/reflect/value.go:337 +0xb9
github.com/brokercap/Bifrost/admin/xgo.(*routeController).DoController0(0xc0001a86c0, 0xdfd7a0, 0xc0001e0620, 0xc000172200)
/mnt/hgfs/project/gopath/src/github.com/brokercap/Bifrost/admin/xgo/xgo.go:87 +0x245
github.com/brokercap/Bifrost/admin/xgo.(*routeController).DoController(0xc0001a86c0, 0xdfd7a0, 0xc0001e0620, 0xc000172200)
/mnt/hgfs/project/gopath/src/github.com/brokercap/Bifrost/admin/xgo/xgo.go:76 +0xae
github.com/brokercap/Bifrost/admin/xgo.rounteFunc(0xdfd7a0, 0xc0001e0620, 0xc000172200)
/mnt/hgfs/project/gopath/src/github.com/brokercap/Bifrost/admin/xgo/xgo.go:144 +0x217
net/http.HandlerFunc.ServeHTTP(0xd37cc8, 0xdfd7a0, 0xc0001e0620, 0xc000172200)
/usr/local/go/src/net/http/server.go:2042 +0x44
net/http.(*ServeMux).ServeHTTP(0x1284d80, 0xdfd7a0, 0xc0001e0620, 0xc000172200)
/usr/local/go/src/net/http/server.go:2417 +0x1ad
net/http.serverHandler.ServeHTTP(0xc0001e0380, 0xdfd7a0, 0xc0001e0620, 0xc000172200)
/usr/local/go/src/net/http/server.go:2843 +0xa3
net/http.(*conn).serve(0xc000114320, 0xdff360, 0xc0001a9a00)
/usr/local/go/src/net/http/server.go:1925 +0x8ad
created by net/http.(*Server).Serve
/usr/local/go/src/net/http/server.go:2969 +0x36c

1.5.0-beta1 升级 1.5.0-release 后报错

mysql aliyun rds 5.7

Bifrost 之前版本是 1.5.0-beta1, 然后升级到1.5.0-release

重启之后手动指定了一次 mysql 的 Position, start 后报错:

2020/10/15 11:35:45 clickhouse:......  ROTATE_EVENT  mysql-bin.001002
2020/10/15 11:35:45 goroutine 66 [running]:
runtime/debug.Stack(0xd0ae2c, 0x3d, 0xc00008d8b0)
        /usr/local/go/src/runtime/debug/stack.go:24 +0x9f
github.com/brokercap/Bifrost/Bristol/mysql.(*mysqlConn).DumpBinlog.func2.1(0xc0006161a0, 0xc00008dd58)
        /root/BifrostBuildSource/v1.5.x/Bristol/mysql/binlog.go:582 +0x1b3
panic(0xbe9320, 0x1231000)
        /usr/local/go/src/runtime/panic.go:969 +0x175
github.com/brokercap/Bifrost/Bristol/mysql.(*eventParser).parseEvent(0xc0006161a0, 0xc0001c63c1, 0x46, 0x46, 0x0, 0x0, 0x47, 0x0, 0xc0001c63c0)
        /root/BifrostBuildSource/v1.5.x/Bristol/mysql/binlog.go:204 +0xc37
github.com/brokercap/Bifrost/Bristol/mysql.(*mysqlConn).DumpBinlog.func2(0xc0006161a0, 0xc00008dd58, 0xc0001c63c0, 0x47, 0x47, 0xc00008dd48)
        /root/BifrostBuildSource/v1.5.x/Bristol/mysql/binlog.go:585 +0xad
github.com/brokercap/Bifrost/Bristol/mysql.(*mysqlConn).DumpBinlog(0xc0002c05a0, 0xc00018ef50, 0x10, 0x11152dae, 0xc0006161a0, 0xc0000978e0, 0xc000031920, 0x0, 0x0, 0x0, ...)
        /root/BifrostBuildSource/v1.5.x/Bristol/mysql/binlog.go:586 +0x425
github.com/brokercap/Bifrost/Bristol/mysql.(*BinlogDump).startConnAndDumpBinlog(0xc0000d6580, 0xc000031920)
        /root/BifrostBuildSource/v1.5.x/Bristol/mysql/binlog.go:867 +0x3e5
github.com/brokercap/Bifrost/Bristol/mysql.(*BinlogDump).StartDumpBinlog(0xc0000d6580, 0xc000492b40, 0x10, 0x111151c27, 0xc000031920, 0x0, 0x0, 0x0)
        /root/BifrostBuildSource/v1.5.x/Bristol/mysql/binlog.go:745 +0x452
created by github.com/brokercap/Bifrost/server.(*db).Start
        /root/BifrostBuildSource/v1.5.x/server/db.go:468 +0x5c8

2020/10/15 11:35:45 planet_prod monitor: parseEvent err:err:runtime error: invalid memory address or nil pointer dereference ;lastMapEvent:*mysql.TableMapEvent ;binlogFileName:mysql-bin.001002 ;binlogPosition:286600622

之后无论怎么改 position(不管是最新还是旧的), start 也都是同样的错误

然后把 Bifrost 版本降回 1.5.0-beta1, 开启同步, 没有报错

配置恢复不了

之前版本的配置文件数据恢复不了，，全量还是增量都不行，

Unknown prepared statement handler (1) given to mysqld_stmt_execute

Version:

• Bifrost Version: v1.7.4-release
• Os Version: CentOS Linux release 7.5.1804 (Core)
• Browse: Chrome
• mysql版本：MariaDB 10.1.9 (兼容Mysql 5.6)

Describe the bug

添加数据源报错，点击 check 按钮，报错：

Error 1243: Unknown prepared statement handler (1) given to mysqld_stmt_execute

我在网上找到了一个类似的问题：
go-sql-driver/mysql#455

用户登入可以指定 哪些 IP 可以访问

1. 支持配置用户登入的 host 地址，类似于 MySQL user 里的 Host 字段，允许哪些IP可以访问，多个用 逗号隔开，* 代表所有IP都可以访问登入
2. 默认帐户是 * 配置，允许所有地址访问
3. Host 支持在线修改

recorery db content errors; json: cannot unmarshal string into Go struct field ToServer.TableMap.ToS

升级版本的时候，导入原有的数据，会有这个报错。
在本地/开发/测试环境，ok
在正式环境就异常了。

recorery db content errors; json: cannot unmarshal string into Go struct field ToServer.TableMap.ToServerList.ErrorWaitData of type driver.PluginDataTypeCopy

mysql to clickhouse datetime field timezone issue

mysql datetime field timezone is UTC+8, clickhouse timezone setting is `Asia/Shanghai

after sync date from mysql to clickhouse, the datetime field add 8 hours

mysql> select now();
+---------------------+
| now()               |
+---------------------+
| 2020-09-26 21:49:27 |
+---------------------+
1 row in set (0.00 sec)

mysql> select create_time from table1 order by id desc limit 1;
+---------------------+
| create_time         |
+---------------------+
| 2020-09-26 21:45:53 |
+---------------------+
1 row in set (0.00 sec)

clickhouse :) select now();

SELECT now()

┌───────────────now()─┐
│ 2020-09-26 21:45:53 │
└─────────────────────┘

clickhouse :) select create_time from table1 order by id desc limit 1

SELECT create_time
FROM table1
ORDER BY id DESC
LIMIT 1

┌─────────create_time─┐
│ 2020-09-27 05:46:28 │
└─────────────────────┘

GTID 的支持

对 GTID 的支持，解决 mysql 主从自动切换，的高可用问题

您好，请教这个原理是基于CDC 日志同步的吗

您好，请教这个原理是基于CDC 日志同步的吗

同步mysql decimal(21,6)数据类型到clickhouse时，数据异常

mysql该字段保存的是经纬度坐标,可为空。
如果设置clickhouse字段类型是Nullable(decimal(18,6)），实时同步的数据存在随机被置为0的情况（不是所有行都会这样），
如：longtitude:116.588591 latitude:39.944301 同步到clickhouse之后会变成 longtitude:116.588591 latitude:0.000000

如果设置clickhouse字段类型是Nullable(string)，同步的数据经纬度小数位会出现负号，
longtitude:118.-1093,latitude:31.-31143.

另外，不会go，只是觉得这里的异常捕获是不是写错了：
plugin\clickhouse\src\data.go

func (This *ClickhouseDB) Exec(sql string,value []driver.Value) error {
This.conn.Begin()
defer This.conn.Commit()
stmt,e:=This.conn.Prepare(sql)
if e != nil{
return e
}
defer stmt.Close()
_,e1:= stmt.Exec(value)
if e != nil{ #此处是不是应该是e1？
return e1
}
return nil
}

当binlog流量中断或者复制库故障时，重新设置binlog和position失败

Describe the bug
当binlog流量中断或者复制库故障时，重新设置binlog和position失败

To Reproduce
复制库故障无法恢复，需要从相关库重新设置数据源的binlog和position信息，此时后台报错如下：

Expected behavior
能够根据位点的大致时间，设置新的位点信息

Screenshots
If applicable, add screenshots to help explain your problem.

对 json 存储类型 字段的同步支持

当前并不支持 同步拥有 json 存储类型的数据

tinyint(1) 类型数据不同步，全部同步成0，，MySQL到MySQL

tinyint(1) 类型数据不同步，全部同步成0，，MySQL到MySQL

能否添加对Oracle数据库的支持？

简单试了一下Bifrost，很棒的软件。
要是能支持同步到Oracle数据库就好了。请问是否有在考虑这个功能？
谢谢。

nginx 配置外部域名，无法访问

您好，请教个问题。
docker 启动之后，证书也有做相应替换。
IP+端口 是可以访问的。
配置域名之后，https访问一直失败，400错误。
请问下这是什么问题。

8.0.22与8.0.18偶尔binlog解析不全

Version:

• Bifrost Version: [e.g. v1.6.2-realease]
• Os Version: [e.g. CentOS Linux release 7.7.1908]
• Browse: [e.g. Chrome]

Describe the bug
最简单的一个表，反复进行delete全表，从另外一个表插入数据
create table tab1(id integer not null,name varchar(20),primary key(id));
insert into tab1 select * from bak_tab1;
delete from tab1;
反复执行几次，会发现偶发性的要么没有解析到Insert，要么没有解析到delete, 我设置的batchsize=1

在plugin/mysql/mysql.go的Query函数入口打断点，发现在出错时根本不会到这，所以怀疑解析有bug，请作者告知如何排查

可否支持MongoDB实时迁移到ClickHouse

如题

二进制部署后，首页不显示

Version:

• Bifrost Version: [e.g. bifrost_v1.7.4-release_Linux-amd64-bin]
• Os Version: [e.g. CentOS Linux release 7.3.1611 (Core) ]
• Browse: [e.g. Chrome]

首页不刷新
使用chrom浏览器F12查看，发下错误如下

Uncaught SyntaxError: Unexpected token *
Uncaught ReferenceError: IntervalFun is not defined timeInterval.js:40

Uncaught SyntaxError: Unexpected token * (index):530
Uncaught ReferenceError: IntervalFun is not defined timeInterval.js:40

function doIntervalFun(){
IntervalFun(); <----提示错误
$("#lastUpdateTimeBox").text(getNowFormatDate());
}

请教下是否缺少什么包吗没有安装吗，我的linux系统是最简安装的

后台反渲染式插件开发

背景:

1. 当前目标库是插件式开发, 不同目标库 在界面上所需要用户填写的 input 内容 是不一样的, 当前每个目标库插件开发的时候 ,都得写一个html文件及js文件,由 Bifrost 界面去动态加载, 这样对 html 存放是有要求的,并且假如 Bifrost 界面如果做了大改动,那插件的 html 及 js 文件都得做相应的修改,

2. 假如提供数据源及告警等插件式开发,那界面这块,其实界面这块管理起来,可能随着插件的种类的增多,会没那么管理

当前思路:

寻找一套标准,或者自定义一套标准格式,,给每个 输入框 定义一套标准 , 插件开发的时候, 把只要把需要的input , select ,textarea, radio, checkbox 等定义好在一个 json 变量中, Bifrost server 层直接调用插件层的 go 代码即可,,不需要再单独写html

但有几个问题

1). 前端的选择不同, 插件要展示的 input 也不一样,比如 clickhouse插件,选择了 追加模式 , 下面的其他的input 可配置的输入框就不一样, 怎么解决?

希望有相关经验的小伙伴 提提建议!!!

是否支持特定表特定字段的同步？

是否支持特定表特定字段的同步？

集群方案讨论

基于etcd的embed模式
预计方案设计
当启动Bifrost的时候,指定集群参数(nodeName, client, peerurl, clienturl等等etcd需要的参数)
Bifrost等待其他节点加入
当所有节点加入以后,
etcd所有的节点开始watch key(配置前缀和元数据前缀和位点前缀)
leader将自己本地的ini配置,元数据配置,位点信息,put进etcd的kv引擎中,同步给所有其他节点
每一个从节点开始监听自己是否变成master节点,当成为master节点后会根据当前节点列表,以及元数据中的db列表,生成一份db分配到哪一个节点的资源分配表
每个node都会监听资源分配表,来决定在本节点启动哪几个dbslave,同步binlog以及推给target

每当节点下线或者新增删除db信息,资源表会被master更新,所有node重新关闭/启动dbslave协程

每个node会定时同步自己正在执行的db的position信息到etcd

以上为简要描述,后续考虑添加流程图及相关信息完善

同步到目标库的队列满了情况下，也不阻塞其他数据表同步

Bifrost 每个表的每一个目标库同步都是相互独立的，都各自有一个队列，这个队列大小可以通过 toserver_queue_size 来配置

但是每个队列 是保存在内存中的，假如一个表设置了同时配置到3个目标库

在3个目标库中同步有，一个目标库出现异常了， 一直同步失败，那队列满了的情况下，会影响其他目标库也同步不了

这里需要在这种队列满了的情况下，将新数据到磁盘队列中去，做到真正不阻塞的方式同步

这里要考滤到解析很快，所有的同步都 慢的情况下，这里就没必要刷到磁盘了，还不如阻塞 在那里，所以这里，应该提供在线设置，某一个同步，是否启用磁盘队列

mysql插件同步，能否也支持日志模式同步

1. 普通模式

源的insert, udpate,delete 之后，目标库MySQL 也做相应的操作

2. 日志模式

源的insert, udpate,delete ，在目标库 MySQL 中全做 insert 方式操作

Decimal128 is not supported (clickhouse)

Describe the bug

mysql -> clickhouse

Decimal128 is not supported when sync

To Reproduce

field type is Decimal128: Decimal(38, 6)

v1.6.6批量提交redis插件会全部返回error

如题

clickhouse 同步，合并 delete操作

当前 同步到 clickhouse delete 是一条一条数据 操作的

能否通过多条数据合并于一条delete 语句执行？进行性能优化

全量同步使用主键分批获取MySQL数据

Describe the bug
SELECT * FROM table_name WHERE create_data = '2020-01-01' LIMIT 1000000000, 1000;

To Reproduce
全量同步，并设置create_data = '2020-01-01'时

Expected behavior
SELECT * FROM table_name WHERE create_data = '2020-01-01' and id >= ?????? and id < ??????;

Screenshots

请教一下Biforst同步到ClickHouse的问题

1.请问对于update delete

是使用这种方式处理的吗吗 https://mp.weixin.qq.com/s/a8OfsBn9VFnj7oxp0IIVGg
ReplacingMergeTree + 视图(argMax)? + is_delete列?

2.全量数据拉取完成后, 咱们这边是如何知道从哪个点消费binlog做增量呢? 是类似逻辑备份的原理吗

FLUSH /*!40101 LOCAL */ TABLES
' # 对整个实例加全局读锁，如果存在表锁将阻塞加全局读锁语句'

FLUSH TABLES WITH READ LOCK
' #在session级别修改隔离级别为RR'

SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ
'# 开启一个一致性快照事务，必须在隔离级别RR下才能开启一个快照事务'

START TRANSACTION /*!40100 WITH CONSISTENT SNAPSHOT */
'#查看是否开启GTID'

SHOW VARIABLES LIKE 'gtid_mode'
'#如果开启GTID则查看当前的事务GTID集合'

SELECT @@GLOBAL.GTID_EXECUTED
'#查看当前数据的binlog pos'

SHOW MASTER STATUS
'#释放全局读锁'

UNLOCK TABLES

开始对指定表执行SELECT获取全量数据
FTWRL 目的获取binlog file pos 或 GTID. 开启RR级别保证后续所有表的查询结果都是在一个一致性的视图中获取
增量同步时是根据binlog file pos 还是 GTID呢?

3.写入clickhouse是否使用batch insert

对于OLTP数据库 DML可能是频繁地小事务, clickhouse建议batch insert, 避免too many part合并不过来, 咱们这边对源端产生的语句转换为INSERT后有做缓存然后再Batch insert写入clickhouse吗?还是就是源端来1条clickhouse就插一次
比如mysql执行1000个insert , clickhouse是执行1000个insert还是1个insert values1000个?

4.MySQL源端DDL

• DDL如何处理? 尤其是使用PT-OST GH-OST等类似工具时

工具原理是创建影子表, DDL应用在影子表上, 全量增量数据同步后再和源表做切换, 那么消费binlog就不能只是消费源表的binlog还要消费影子表的binlog(至少要消费影子表的ALTER语句)

• 加索引. 加索引clickhouse会自行忽略吗

跟amd64架构绑定,不支持aarch64架构

build.sh中写死了编译架构. 能否通过自动识别单板架构支持aarch64呢?

    CGO_ENABLED=0 GOOS=$mode GOARCH=amd64 go build ./Bifrost.go

单线程进行全量同步功能完善

全量同步个人感觉最好可以提供一种可以单线程抽数据的模式，通过FTWRL+RR一致性快照读的方式，可以不用怕源库对应表上有写入，因为有些系统可能源库不太好停写。

目前全量同步是不通过FTWRL+RR快照读的方式，所以如果主库有写入，就会导致增量GTID不准，数据会有误差。

可以增加一种类似于官方MaterializeMySQL全量同步方式，全量过程中记录GITD信息，完成全量后更新增量的GTID信息，就可以避免主库停写了

mysql5.6 数据同步ck ，使用自动创建CK方式，全量同步报错

bifrost版本：1.5.2 release 或者 1.6.0 beta01 均有以下问题
Percona-Server-server-56-5.6.37-rel82.2.el7
使用bifrost，从mysql全量同步至CK

1. 使用自动创建CK表，表字段某些会和源表不一致，mysql为varchar，而CK创建的字款类型为date。导致报错信息如下
   Error:parsing time "3" as "2006-01-02": cannot parse "3" as "2006"
2. 同步时，前后不同的表，当主键名称不一致时，也会报错。
   会提示，某个字段不存在。这个不存在的字段，往往是上一张表中的主键名

增量同步时候报错，全量没有问题，

阿里云数据库同步到本地数据库
runtime error: invalid memory address or nil pointer dereference

unexpected end of JSON input

版本号v1.1.0-beta.06
/table/addtoserver
出入参数：
dbname: tct
schema_name: xxx
table_name: xxx
toserver_key: mq
plugin_name: rabbitmq
mustbe: true
FilterQuery: true
FilterUpdate: true
fieldlist: xxx,xxx

输出：
{"status":false,"msg":"unexpected end of JSON input"}

某个数据源delay很大延迟，closing假死状态

某个数据源delay很大延迟：

1. 生产碰到过两次确认没有报警
2. 状态一直是closing，按文档已经刷新了很多次，状态不变。mysql 命令：SHOW PROCESSLIST 没有找到长时间卡住的pid查询，一切正常。最后重启Bifrost后 恢复正常，delay积压的消息被逐步消费

从情况来看，是Bifrost判断数据源状态有问题，真实mysql连接早已断开了，Bifrost上一直显示的 closing状态，重启后显示正常，重新start就ok了。