摘要：
本文是Druid配置文件系列博文的第三篇，之前的文章已经介绍了Druid配置文件整体的组织结构以及公共配置文件，接下来将逐个介绍Druid的五大组件，本文是第一个组件Coordinator的介绍。
以下配置都在coordinator/runtime.properties文件中。
Coordinator Process Config
| 属性 | 含义 | 备注 | 是否需要修改 |
|---|
| druid.host | 组件所在的主机 | 默认InetAddress.getLocalHost().getCanonicalHostName() | 一般不需要修改 |
| druid.bindOnHost | 组件的内部jetty服务是否和druid.host绑定 | 默认false | 一般不需要修改 |
| druid.plaintextPort | 实际监听端口 | 默认8081 | 一般不需要修改 |
| druid.tlsPort | TLS端口号 | 默认8281 | 一般不修改 |
| druid.service | 用于服务发现的名字 | 默认druid/coordinator | 一般不修改 |
这些配置在其他组件中也都有，含义与这里相同，接下来将不再逐个介绍
Coordinator Operation
| 属性 | 含义 | 备注 | 是否需要修改 |
|---|
| druid.coordinator.period | coordinator每隔一段时间会运行去查看可用的segment和处于服务中的segment，这个属性表示这个时间间隔 | 默认PT60S | 按需修改 |
| druid.coordinator.period.indexingPeriod | 每隔多久去发送压缩/合并/转换任务 | 默认PT1800S，推荐要大于druid.manager.segments.pollDuration | 一般不需要 |
| druid.coordinator.startDelay | Coordinator运行时假设自己知道最新的所有状态，但是ZK不允许Coordinator知道它是否已经得到全部最新状态，所以需要一个时间间隔给足够的时间让Coordinator可以假设自己已经得到全部最新状态 | 默认PT300S | 一般不修改 |
| druid.coordinator.load.timeout | 分配一个segment到historical的超时时间 | 默认PT15M | 一般不修改 |
| druid.coordinator.kill.pendingSegments.on | 是否清理元数据中的pendingSegments表的老条目，清理的时间间隔是druid.coordinator.period，killPendingSegmentsSkipList里的数据源不会被清理 | 默认false | 按需修改 |
| druid.coordinator.kill.on | Coordinator是否提交kill任务去删除元数据和深存储中的无用数据清理的时间间隔是druid.coordinator.kill.period，durationToRetain是保留时间，在这个时间内的segment不会被删除，白名单可以通过killAllDataSources和killDataSourceWhitelist设置 | 默认false | 按需修改 |
| druid.coordinator.kill.period | 发送kill任务的时间间隔 | 默认P1D | 按需修改 |
| druid.coordinator.kill.durationToRetain | 在最近这个时间内的segment不会被删除 | 默认PT-1S | 默认值无效，如果kill打开必须设置 |
| druid.coordinator.kill.maxSegments | 每个kill任务最多删除的segment数量 | 默认0 | 默认值无效，如果kill打开必须设置 |
| druid.coordinator.balancer.strategy | segment平衡策略 | 默认cost，可选值是cachingCost、diskNormalized、random，cachingCost是cost的优化版将取代cost，diskNormalized尽量保证磁盘使用均匀，random随机分配segment | 按需修改 |
| druid.coordinator.balancer.cachingCost.awaitInitialization | 使用cachingCost策略时，是否在创建cachingCost策略之前等待segment视图初始化 | 默认false | 按需修改 |
| druid.coordinator.loadqueuepeon.repeatDelay | 管理segment加载和删除的loadqueue的开始和重复延迟时间 | 默认PT0.050S (50 ms) | 按需修改 |
| druid.coordinator.asOverlord.enabled | 是否Coordinator也充当Overlord的角色，这个用来简化集群，没有部署overlord时使用 | 默认false | 一般不修改 |
| druid.coordinator.asOverlord.overlordService | 如果druid.coordinator.asOverlord.enabled为true，用于服务发现 | 默认null，应该和overlord组件的druid.service属性和middle manager组件的druid.selectors.indexing.serviceName属性相同 | 如果druid.coordinator.asOverlord.enabled为true，需要修改 |
Segment Management
| 属性 | 含义 | 备注 | 是否需要修改 |
|---|
| druid.serverview.type | segment发现的方法 | 默认batch，可选值http，batch使用zk方式 | 按需修改 |
| druid.coordinator.loadqueuepeon.type | 分配segment的方式 | 默认curator，可选值http | 按需修改 |
| druid.coordinator.segment.awaitInitializationOnStart | Coordinator是否在开始之前等待segment视图完全初始化 | 默认true | 按需修改 |
druid.coordinator.loadqueuepeon.type设置为http时需要配置以下属性
| 属性 | 含义 | 备注 | 是否需要修改 |
|---|
| druid.coordinator.loadqueuepeon.http.batchSize | 在一个http请求里加载或删除的segment数量 | 默认1，需要小于druid.segmentCache.numLoadingThreads | 按需配置 |
Metadata Retrieval
| 属性 | 含义 | 备注 | 是否需要修改 |
|---|
| druid.manager.config.pollDuration | manager多久拉一次配置表用于更新 | 默认PT1M | 按需修改 |
| druid.manager.rules.pollDuration | manager多久拉一次用于更新活跃segment | 默认PT1M | 按需修改 |
| druid.manager.rules.defaultTier | 默认tier，默认的规则将从tier中加载 | 默认_default | 按需修改 |
| druid.manager.rules.alertThreshold | 失败的拉多久后会报警 | 默认PT10M | 按需修改 |
Dynamic Configuration
Coordinator有一个通过HTTP的动态配置方式，具体如下：
url：POST http://<COORDINATOR_IP>:/druid/coordinator/v1/config
可选的Header：
| 属性 | 含义 |
|---|
| X-Druid-Author | 改变配置的用户名 |
| X-Druid-Comment | 描述配置修改内容的注释 |
一个Body的例子：
{
"millisToWaitBeforeDeleting": 900000,
"mergeBytesLimit": 100000000,
"mergeSegmentsLimit" : 1000,
"maxSegmentsToMove": 5,
"replicantLifetime": 15,
"replicationThrottleLimit": 10,
"emitBalancingStats": false,
"killDataSourceWhitelist": ["wikipedia", "testDatasource"],
"decommissioningNodes": ["localhost:8182", "localhost:8282"],
"decommissioningMaxPercentOfMaxSegmentsToMove": 70,
"pauseCoordinator": false
}
一个GET请求相同的url会得到当前这些配置属性的值
下面分别介绍这些属性的含义：
| 属性 | 含义 | 备注 | 是否需要修改 |
|---|
| millisToWaitBeforeDeleting | Coordinator在删除元数据中的segment之前需要活跃多久 | 默认900000（15分钟） | 按需配置 |
| mergeBytesLimit | 合并segment的最大未压缩字节大小 | 默认524288000L | 按需修改 |
| mergeSegmentsLimit | 合并的最大segment数量 | 默认100 | 按需修改 |
| maxSegmentsToMove | 最大的能被移动的segment数量 | 默认5 | 按需修改 |
| replicantLifetime | 对于要复制的segment，在报警之前Coordiantor运行的最大次数 | 默认15 | 按需修改 |
| replicationThrottleLimit | 一次复制的最大segment数量 | 默认10 | 按需修改 |
| balancerComputeThreads | 在segment平衡是，计算移动cost的线程池大小 | 默认1 | 按需修改 |
| emitBalancingStats | 是否emit平衡相关统计 | 默认false，这是一个昂贵的操作 | 按需修改 |
| killDataSourceWhitelist | 发送kill任务的数据源白名单（白名单中的dataSource会被kill） | 默认none | 按需使用 |
| killAllDataSources | 是否对所有dataSource发送kill任务，与killDataSourceWhitelist只能使用其中一个 | 默认false | 按需使用 |
| killPendingSegmentsSkipList | kill pending状态segment时跳过的数据源列表 | 默认none | 按需使用 |
| maxSegmentsInNodeLoadingQueue | 最大的segment排毒数量 | 默认0，这个值可以在有慢节点或segment调度不均匀时加速segment加载过程，可以设置为1000然后根据情况调节 | 按需使用 |
| decommissioningNodes | 退役historical列表，将不分配新的segment到退役节点上 | 默认none | 按需使用 |
| decommissioningMaxPercentOfMaxSegmentsToMove | 再一次Coordinator运行时，从退役节点上移动到非退役节点上的segment数量 | 默认70 | 按需使用 |
Lookups Dynamic Configuration
略
Compaction Dynamic Configuration
通过API来设置Compaction任务
| 属性 | 含义 | 备注 | 是否需要修改 |
|---|
| dataSource | 要Compaction的数据源名字 | | 需要设置 |
| taskPriority | 任务优先级 | 默认25 | 不需要设置 |
| inputSegmentSizeBytes | 最大的总的segment的字节数 | 默认419430400 | 不需要设置 |
| maxRowsPerSegment | 每个segment的最大行数 | | 不需要设置 |
| skipOffsetFromLatest | 搜索要压缩的segment的offset | 默认P1D | 不需要设置，对于实时数据源推荐去设置 |
| tuningConfig | 里面的参数之后在详细介绍 | | 不需要配置 |
| taskContext | 环境参数 | | 不需要设置 |
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
