Replication工具

所有工具都在$KAFKA_HOME/bin目录下

kafka-topics.sh

该工具可用于创建、删除、修改、查看某个Topic，也可用于列出所有Topic。另外，该工具还可修改某个Topic的以下配置。
unclean.leader.election.enable
delete.retention.ms
segment.jitter.ms
retention.ms
flush.ms
segment.bytes
flush.messages
segment.ms
retention.bytes
cleanup.policy
segment.index.bytes
min.cleanable.dirty.ratio
max.message.bytes
file.delete.delay.ms
min.insync.replicas
index.interval.bytes

Replica Verification Tool

kafka-replica-verification.sh

该工具用来验证所指定的一个或多个Topic下每个Partition对应的所有Replica是否都同步。可通过topic-white-list这一参数指定所需要验证的所有Topic，支持正则表达式。
Preferred Replica Leader Election Tool
用途
有了Replication机制后，每个Partition可能有多个备份。某个Partition的Replica列表叫作AR（Assigned Replicas），AR中的第一个Replica即为“Preferred Replica”。创建一个新的Topic或者给已有Topic增加Partition时，Kafka保证Preferred Replica被均匀分布到集群中的所有Broker上。理想情况下，Preferred Replica会被选为Leader。以上两点保证了所有Partition的Leader被均匀分布到了集群当中，这一点非常重要，因为所有的读写操作都由Leader完成，若Leader分布过于集中，会造成集群负载不均衡。但是，随着集群的运行，该平衡可能会因为Broker的宕机而被打破，该工具就是用来帮助恢复Leader分配的平衡。
事实上，每个Topic从失败中恢复过来后，它默认会被设置为Follower角色，除非某个Partition的Replica全部宕机，而当前Broker是该Partition的AR中第一个恢复回来的Replica。因此，某个Partition的Leader（Preferred Replica）宕机并恢复后，它很可能不再是该Partition的Leader，但仍然是Preferred Replica。
原理
1. 在ZooKeeper上创建/admin/preferred_replica_election节点，并存入需要调整Preferred Replica的Partition信息。
2. Controller一直Watch该节点，一旦该节点被创建，Controller会收到通知，并获取该内容。
3. Controller读取Preferred Replica，如果发现该Replica当前并非是Leader并且它在该Partition的ISR中，Controller向该Replica发送LeaderAndIsrRequest，使该Replica成为Leader。如果该Replica当前并非是Leader，且不在ISR中，Controller为了保证没有数据丢失，并不会将其设置为Leader。
用法
kafka-preferred-replica-election.sh --zookeeper localhost:2181
在包含8个Broker的Kafka集群上，创建1个名为topic1，replication-factor为3，Partition数为8的Topic，使用如下命令查看其Partition/Replica分布。
kafka-topics.sh --describe --topic topic1 --zookeeper localhost:2181
查询结果如下图所示，从图中可以看到，Kafka将所有Replica均匀分布到了整个集群，并且Leader也均匀分布。

手动停止部分Broker，topic1的Partition/Replica分布如下图所示。从图中可以看到，由于Broker 1/2/4都被停止，Partition 0的Leader由原来的1变为3，Partition 1的Leader由原来的2变为5，Partition 2的Leader由原来的3变为6，Partition 3的Leader由原来的4变为7。

再重新启动ID为1的Broker，topic1的Partition/Replica分布如下。可以看到，虽然Broker 1已经启动（Partition 0和Partition5的ISR中有1），但是1并不是任何一个Parititon的Leader，而Broker 5/6/7都是2个Partition的Leader，即Leader的分布不均衡——一个Broker最多是2个Partition的Leader，而最少是0个Partition的Leader。

运行该工具后，topic1的Partition/Replica分布如下图所示。由图可见，除了Partition 1和Partition 3由于Broker 2和Broker 4还未启动，所以其Leader不是其Preferred Repliac外，其它所有Partition的Leader都是其Preferred Replica。同时，与运行该工具前相比，Leader的分配更均匀——一个Broker最多是2个Parittion的Leader，最少是1个Partition的Leader。

启动Broker 2和Broker 4，Leader分布与上一步相比并未变化，如下图所示。

再次运行该工具，所有Partition的Leader都由其Preferred Replica承担，Leader分布更均匀——每个Broker承担1个Partition的Leader角色。
除了手动运行该工具使Leader分配均匀外，Kafka还提供了自动平衡Leader分配的功能，该功能可通过将auto.leader.rebalance.enable设置为true开启，它将周期性检查Leader分配是否平衡，若不平衡度超过一定阈值则自动由Controller尝试将各Partition的Leader设置为其Preferred Replica。检查周期由leader.imbalance.check.interval.seconds指定，不平衡度阈值由leader.imbalance.per.broker.percentage指定。
Kafka Reassign Partitions Tool
用途
该工具的设计目标与Preferred Replica Leader Election Tool有些类似，都旨在促进Kafka集群的负载均衡。不同的是，Preferred Replica Leader Election只能在Partition的AR范围内调整其Leader，使Leader分布均匀，而该工具还可以调整Partition的AR。
Follower需要从Leader Fetch数据以保持与Leader同步，所以仅仅保持Leader分布的平衡对整个集群的负载均衡来说是不够的。另外，生产环境下，随着负载的增大，可能需要给Kafka集群扩容。向Kafka集群中增加Broker非常简单方便，但是对于已有的Topic，并不会自动将其Partition迁移到新加入的Broker上，此时可用该工具达到此目的。某些场景下，实际负载可能远小于最初预期负载，此时可用该工具将分布在整个集群上的Partition重装分配到某些机器上，然后可以停止不需要的Broker从而实现节约资源的目的。
需要说明的是，该工具不仅可以调整Partition的AR位置，还可调整其AR数量，即改变该Topic的replication factor。
原理
该工具只负责将所需信息存入ZooKeeper中相应节点，然后退出，不负责相关的具体操作，所有调整都由Controller完成。
1. 在ZooKeeper上创建/admin/reassign_partitions节点，并存入目标Partition列表及其对应的目标AR列表。
2. Controller注册在/admin/reassign_partitions上的Watch被fire，Controller获取该列表。
3. 对列表中的所有Partition，Controller会做如下操作：

* 启动RAR - AR中的Replica，即新分配的Replica。（RAR = Reassigned Replicas， AR = Assigned Replicas）
* 等待新的Replica与Leader同步
* 如果Leader不在RAR中，从RAR中选出新的Leader
* 停止并删除AR - RAR中的Replica，即不再需要的Replica
* 删除/admin/reassign_partitions节点

用法
该工具有三种使用模式

* generate模式，给定需要重新分配的Topic，自动生成reassign plan（并不执行）
* execute模式，根据指定的reassign plan重新分配Partition
* verify模式，验证重新分配Partition是否成功

下面这个例子将使用该工具将Topic的所有Partition重新分配到Broker 4/5/6/7上，步骤如下：
1. 使用generate模式，生成reassign plan
指定需要重新分配的Topic （{"topics":[{"topic":"topic1"}],"version":1}），并存入/tmp/topics-to-move.json文件中，然后执行如下命令
kafka-reassign-partitions.sh --zookeeper localhost:2181
--topics-to-move-json-file /tmp/topics-to-move.json
--broker-list "4,5,6,7" --generate
结果如下图所示

  1. 使用execute模式，执行reassign plan
    将上一步生成的reassignment plan存入/tmp/reassign-plan.json文件中，并执行
    kafka-reassign-partitions.sh --zookeeper localhost:2181
    --reassignment-json-file /tmp/reassign-plan.json --execute
    此时，ZooKeeper上/admin/reassign_partitions节点被创建，且其值与/tmp/reassign-plan.json文件的内容一致。
  2. 使用verify模式，验证reassign是否完成
    执行verify命令
    kafka-reassign-partitions.sh --zookeeper localhost:2181
    --reassignment-json-file /tmp/reassign-plan.json --verify
    结果如下所示，从图中可看出topic1的所有Partititon都根据reassign plan重新分配成功。

接下来用Topic Tool再次验证。
kafka-topics.sh --zookeeper localhost:2181 --describe --topic topic1
结果如下图所示，从图中可看出topic1的所有Partition都被重新分配到Broker 4/5/6/7，且每个Partition的AR与reassign plan一致。

需要说明的是，在使用execute之前，并不一定要使用generate模式自动生成reassign plan，使用generate模式只是为了方便。事实上，某些场景下，generate模式生成的reassign plan并不一定能满足需求，此时用户可以自己设置reassign plan。
State Change Log Merge Tool
用途
该工具旨在从整个集群的Broker上收集状态改变日志，并生成一个集中的格式化的日志以帮助诊断状态改变相关的故障。每个Broker都会将其收到的状态改变相关的的指令存于名为state-change.log的日志文件中。某些情况下，Partition的Leader election可能会出现问题，此时我们需要对整个集群的状态改变有个全局的了解从而诊断故障并解决问题。该工具将集群中相关的state-change.log日志按时间顺序合并，同时支持用户输入时间范围和目标Topic及Partition作为过滤条件，最终将格式化的结果输出。
用法
kafka-run-class.sh kafka.tools.StateChangeLogMerger
--logs /opt/kafka_2.11-0.8.2.1/logs/state-change.log
--topic topic1 --partitions 0,1,2,3,4,5,6,7

时间： 2024-11-03 18:25:43

Replication工具的相关文章

如何管理一台集群的虚拟机

现如今的企业组织需要保证全年的每一天都24小时全天候的正常运营.而且,他们的服务必须保持时刻在线,否则就会失去客户.同时,在今天的全球市场上,确保企业的系统总是可用,以使得企业组织保持竞争优势,进而保持和提升用户满意度是至关重要的.数据中心的高度可用性可以通过几种方式来实现,但最常见的和最简单的方式则是通过服务器虚拟化和故障转移群集(Failover Cluster). 服务器虚拟化为许多企业组织的IT部门带来了诸多的益处,包括允许他们将多款不同的系统整合到一台单一的主机服务器,带来了更高的资源

Replication的犄角旮旯（九）-- sp_setsubscriptionxactseqno，赋予订阅活力的工具

原文:Replication的犄角旮旯(九)-- sp_setsubscriptionxactseqno,赋予订阅活力的工具 <Replication的犄角旮旯>系列导读 Replication的犄角旮旯(一)--变更订阅端表名的应用场景 Replication的犄角旮旯(二)--寻找订阅端丢失的记录 Replication的犄角旮旯(三)--聊聊@bitmap Replication的犄角旮旯(四)--关于事务复制的监控 Replication的犄角旮旯(五)--关于复制identity列

使用Opatch工具应用过渡性Patch

Last Updated: Saturday, 2004-12-04 10:04 Eygle         很多时候,在推出一个完整的补丁集之前,Oracle会依据Bug的严重程度发布一些过渡性或临时性Patch,修正一些Bug.这些Patch通常没有setup安装程序,需要使用Oracle的opatch工具安装,本文就opatch的使用进行示范说明. 1.下载 Opatch的最新版本可以从Metalink下载,参考 Note:224346.1 2.使用 在NT/UNIX,Opatch都需要p

【转载】MySQL复制的概述、安装、故障、技巧、工具

概述 首先主服务器把数据变化记录到主日志,然后从服务器通过I/O线程读取主服务器上的主日志,并且把它写入到从服务器的中继日志中,接着SQL线程读取中继日志,并且在从服务器上重放,从而实现MySQL复制.具体如下图所示: MySQL复制 整个过程反映到从服务器上,对应三套日志信息,可在从服务器上用如下命令查看: mysql> SHOW SLAVE STATUS;   Master_Log_File & Read_Master_Log_Pos:下一个传输的主日志信息. Relay_Master_

SQL Server 2000 的工具

1.3.4 ProfilerSQL Server Profiler 是一个图形化的管理工具用于监督记录和检查SQL Server 数据库的使用情况对系统管理员来说它是一个监视用户活动的间谍 1.3.5 Client Network Utility SQL Server Client Network Utility 用于配置客户端的连接测定网络库的版本信息以及设定本地数据库的相关选项 1.3.6 Server Network UtilitySQL Server Server Network Uti

IBM Infosphere Data Replication产品族Replication Server与Change Data Cap

IBM Infosphere Data Replication产品族Replication Server与Change Data Capture的异同比较 一,简介 在如今信息快速变化的商业时代,必须在第一时间做出商业决策并采取行动才能在激烈的竞争中保持领先地位.如果商业数据不能保证同步,那么生产和利润势必会遭受损失,但是,面对信息量激增并且分布存储的特点,保证数据的可信性并非易事. IBM 的 InfoSphere Data Replication 产品族针对这一问题为应用提供了一系列数据同步

用开发工具和编程语言开发ODBC应用程序

ODBC 应用程序 您可以使用多种开发工具和编程语言开发 ODBC 应用程序. 例如,在与 SQL Anywhere Studio 一起提供的应用程序中, InfoMaker和 SQL Modeler 使用 ODBC 连接到数据库. 嵌入式 SQL 应用程序 您可以使用嵌入式 SQL 编程接口开发 C 或 C++ 应用程序.例如,命令行数据库工具就是以此方式开发的应用程序. 嵌入式 SQL 也是 UltraLite 应用程序的编程接口. Open Client 应用程序 Open Client

Cassandra数据库中的冗余(Replication)

什么是Replication? 在Cassandra中,Replication是存储数据的到多个节点来保证可靠性和出错容忍性.当你创建一个keyspace时候(相当于关系数据库中的表)的时候,就必须给出一个副本放置策略 (Replica Placement Strategy) 什么是副本因子(Replica Factor)? 这个数决定了有几份副本,比如如果设置为1,则表示每一行只有一个副本,以此类推.所有的副本地位都是相等的, 没有主从之分.注意,副本因子最多不可以超过节点的数量,(没这么多节

Win2k“秘密武器”之DNS工具(一)

在网络环境下应用的工具:对从事维护人的员来说用处较大.并需要注意:有些工具需要另一个工具作为基础才好用,即某个工具在工作时,作为基础的另一个工具必须先被执行.这些工具有: 远程文件储存诊断 远程文件储存分析 分布式文件系统实用工具 由于网络越来越普及,分布式文件系统应用越来越多,其应用也越来越广,基于网络来排除故障的工具的使用价值也在不断上升.对需要经常与网络打交道的朋友,这部分不可不看. 基于网络的工具,也不是仅仅这些.Windows2000的资源工具中配备了相当多的此类软件――也就是下面将介