作者:吴金玲

爱可生 dble 我的项目团队成员,次要负责 dble 相干的日常测试工作,善于对 dble 中呈现的问题进行排查。酷爱测试工作,余生欲将测试工作进行到底。

本文起源:原创投稿

*爱可生开源社区出品,原创内容未经受权不得随便应用,转载请分割小编并注明起源。


本文谨献给 dble 的新粉。在首次应用 dble 的时候,老手们常常会遭逢 dble 启动失败的状况,而且启动失败个别都是因为配置不正确导致的。家喻户晓,dble 启动失败了,咱们能够去 wrapper.log 外面查找启动失败的起因,并且可喜的是个别都能从 wrapper.log 里很直观的找到启动失败的起因。但多数启动失败的起因就不是那么直观,要想疾速的定位及解决问题,那就须要咱们对dble启动时具体都做了些什么有所理解。本文以 3.22.01.0 版本为例,简略介绍一下 dble 在启动的时候是如何对配置文件的正确性进行校验的。

具体如何配置请参考 dble 的官网文档:https://actiontech.github.io/... 。

一、首先让咱们简略理解一下 dble 都有哪些配置文件,以及他们的次要作用是什么

下载 3.22.01.0 版本的装置压缩包,解压后进入 dble 装置目录的根目录,外面有个 conf 的配置文件目录(罕用的配置文件外面都有模板文件),从配置文件目录可知,dble 次要分为4种类型的配置文件(.cnf、.xml、.properties、.txt),每个配置文件的次要作用如下表:

文件名次要作用留神点参考链接
cluster.cnf集群参数配置文件批改此文件须要进行多个dble实例,从新初始化集群元数据,而后再一一启动dblehttps://actiontech.github.io/...
bootstrap.cnfdble实例启动时加载的零碎参数配置文件文件分为两局部,第一部分为JVM启动参数,第二局部为dble零碎参数https://actiontech.github.io/...
bootstrap.dynamic.cnf个别为能够通过治理命令热失效的零碎参数当dble重启时会替换bootstrap.cnf中对应的值来失效配置https://github.com/actiontech...
user.xml登录用户配置文件(dble次要分四种用户)次要留神sql权限和ip白名单的配置https://actiontech.github.io/...
db.xml后端数据库和组的配置文件为了dble能失常工作,后端MySQL用户需开启特定的权限https://actiontech.github.io/...
sharding.xml虚构库、表、算法的配置文件留神全局序列的配置办法https://actiontech.github.io/...
sequence_conf.propertie分布式offset-step形式的全局序列配置文件联合cluster.cnf配置,sequenceHandlerType=4https://actiontech.github.io/...
sequence_db_conf.propertiesMySQL-offset-step形式的全局序列配置文件联合cluster.cnf配置,sequenceHandlerType=1https://actiontech.github.io/...
.txt文件不同分片算法对应的配置文件罕用,须要时可参照文档配置https://actiontech.github.io/...
log4j2.xml日志归档规定及日志记录级别配置当出错时可将日志级别调整为debug来定位具体的错误信息https://actiontech.github.io/...
cacheservice.propertiesdble的cache的总配置文件不罕用,须要时可自行参照文档配置https://actiontech.github.io/...
ehcache.xmdble的缓存实现配置文件不罕用,须要时可自行参照文档配置https://actiontech.github.io/...
$DBLE_HOME/lib目录下jar包自定义拆分算法文件不罕用,须要时可自行参照文档配置https://actiontech.github.io/...
dble_alert.properties自定义告警配置文件不罕用,须要时可自行参照文档配置https://actiontech.github.io/...

二、上面通过列举几个新粉常常遇到的 dble 启动失败的例子,来阐明 dble 在加载配置文件时做了哪些检测

1.首先以以下 boostrap.cnf 配置为例启动 dble (其余配置文件请按需配置,此处省略):

进入 dble 装置的根目录,执行 dble 启动命令 bin/dble start ,而后执行 bin/dble status 查看 dble 的状态,发现启动失败了:

进入 wrapper.log 中查看,发现报错如下:

从日志中能够看出,报错是因为22端口被占用。这是因为 dble 在启动的时候会初始化一个虚拟机,从 bootstrap.cnf 读取 JVM 参数。dble 启动过程中会占用三个端口:业务端口(默认8066),治理端口(默认9066),jvm 对外提供 jmx 服务端口,所以配置的时候这三个端口不能雷同,且不能被其余程序占用。具体参考:https://actiontech.github.io/... 。所以将端口改为未被占用的端口即可启动胜利。

2.再以以下 boostrap.cnf 配置启动(其余配置文件请按需配置,此处省略):

发现 dble 启动报错,报错信息如下:

从日志中能够看出,此处有4个谬误:

  • -D与参数名“NIOFrontRW”之间有个空格,这不合乎JSW对配置文件的要求,也就是不能有空格,具体请参见 https://wrapper.tanukisoftwar...;
  • sqlExecuteTimeout的属性值类型谬误,此处应该是long类型,错配成了字符类型,将“30s”改成“30”即可;
  • 误将“frontWorker”写成了“frontWorkers”。留神,bootstrap.cnf文件里的属性名要严格依照文档里的写法,大小写也须要严格统一,否则报错;
  • fakeMySQLVersion的值不正确,将“5.7”改写成“5.7.26”即可。

3.针对 xml 文件,dble 启动时同样也会对配置文件格式、属性名、属性值、属性类型等做校验,此处不再赘述。另外,针对 db.xml ,dble 在启动时还会对后端 MySQL 节点的可连接性做检测,还会获取所有后端 MySQL 节点的版本号和大小写敏感参数值。

dble 用以下 db.xml 配置启动(其余配置文件请按需配置,此处省略):

发现 dble 启动失败,查看 wrapper.log 日志,发现如下谬误:

这个谬误示意后端 MySQL 节点连贯检测失败。针对这种报错,个别常见的排查手法就是用 MySQL 客户端依照配置里的连贯参数登录后端 MySQL 节点,如下:

此处是因为连贯端口配置谬误,将数据库的连贯端口“3306”批改成“3307”即可启动胜利。这种报错还有可能是用户和明码不对,也有可能是用户没有权限,具体可能起因及解决办法请对照参考:https://actiontech.github.io/...。

4.dble 用以下 db.xml 配置启动(其余配置文件请按需配置,此处省略):

dble 启动报错,wrapper.log 中报错如下:

以上报错阐明后端 MySQL 节点大小写敏感参数值不统一。dble 启动时,会依据 db.xml 的配置,获取所有节点的大小写敏感参数值,dble 要求此参数值在所有 MySQL 节点中必须保持一致,否则报错。将 hostM1 中的大小写改成敏感后 dble 即可启动胜利。

5.dble 用以下 bootstrap.cnf 配置启动(其余配置文件请按需配置,此处省略):

发现 dble 启动失败,且 wrapper.log 里报如下谬误:

谬误提醒 dble 里配置的 version 值高于后端节点的版本值。这是因为 dble 在启动时会获取 db.xml 里配置的所有节点的 MySQL 版本,而后和 bootstrap.cnf 里配置的 fakeMySQLVersion 进行比拟,要求配置的 fakeMySQLVersion 的值不能高于后端 MySQL 节点的最低版本号,否则报错。

除了以上列举的例子外,dble 还会对其余配置文件做各自非凡的校验,比方分片算法正确性,用户类型和实例组的正确配对,maxPacketSize 同步等等,因为篇幅起因,本文不再一一举例,因为个别 dble 启动失败都能够通过 wrapper.log 里的谬误提醒失去解决。

简略总结来说就是,dble 在启动的时候会对所有配置文件进行合法性校验,包含配置文件的格局,属性名,属性类型、属性值等。还会对后端 MySQL 节点做可连性测试,大小写一致性检测,fakeMySQLVersion 合法性检测,maxPacketSize 同步等。还会校验各配置文件之间是否正确配置等等。