【Kafka官方文档翻译】5.1.5. 老版本升级
官文原文地址：https://kafka.apache.org/0101/documentation.html#upgrade
从 0.8.x，0.9.x 或 0.10.x 升级到 0.10.1.0
0.10.1.0 在 wire protocol 上有些变化。通过下面推荐的滚动升级计划，你能保证在升级过程中无需停机。但是，请在升级之前查看0.10.1.0版本显著的变化
注意：因为引入了新的协议，在升级客户端之前请先升级Kafka集群（即：0.10.1.x 的客户端只支持 0.10.1.x 或更高版本的 broker，而 0.10.1.x 的 broker 支持老版本的客户端）
对于滚动升级：
1. 更新所有代理服务器上的 server.properties 文件，添加以下属性：
inter.broker.protocol.version=CURRENT_KAFKA_VERSION (例如 0.8.2.0, 0.9.0.0 or 0.10.0.0)
log.message.format.version=CURRENT_KAFKA_VERSION (了解此配置做什么的详细信息参见 [升级后潜在的性能影响](https://kafka.apache.org/0101/documentation.html#upgrade_10_performance_impact) )
2. 逐一升级代理服务器：关闭代理，更新代码，并重新启动。
3. 一旦整个群集升级成功，通过编辑 inter.broker.protocol.version 将其设置为0.10.1.0 的协议版本。
4. 如果以前的消息格式为0.10.0，改变 log.message.format.version 至 0.10.1（这是一个无效操作，因为0.10.0，0.10.1和0.10.2的消息格式相同）。如果以前的消息格式版本低于 0.10.0，不要改变log.message.format.version – 这个参数只能在所有的消费者都已经升级到 0.10.0.0 或更高版本之后才能改动。
5. 逐一重新启动代理服务器使新协议版本生效。
6. 如果这时 log.message.format.version 仍比 0.10.0 低，等到所有的消费者都已经升级到 0.10.0 或更高版本，然后更改每个代理服务器的 log.message.format.version 到0.10.1，然后逐一重新启动。
注意：如果愿意接受宕机，可以简单地把所有的代理服务器关闭，更新代码，然后重新启动他们。他们将默认使用新的协议。
注意：改变协议版本并重新启动可以在代理服务器升级之后的任何时间做，没有强制必须立刻重启。
0.10.1.0 的潜在突破变化
- 日志保留时间不再基于日志段的最后修改时间。它将基于日志段中消息的最大时间戳。
- 日志滚动时间不再取决于日志段创建时间。它将基于消息的时间戳。切确地说，如果段中的第一个消息的时间戳为 T，则当新消息的时间戳大于或等于 T + log.roll.ms 时，日志将被推出。
- 0.10.0 的打开文件处理程序将增加约33％，因为每个段都添加了时间索引文件。
- 时间索引和偏移索引共享相同的索引大小配置。 由于每次索引条目是偏移索引条目的大小的1.5倍。 用户可能需要增加 log.index.size.max.bytes 以避免频繁的日志滚动。
- 由于索引文件数量增加，在一些具有大量日志段（例如> 15K）的代理服务器中，服务器启动期间的日志加载过程可能会更长。 根据我们的实验，将 num.recovery.threads.per.data.dir 设置为 1 可能会减少日志加载时间。
0.10.1.0 的显著变化
- 新的Java消费者不再是测试版，我们推荐它用于所有新开发。 旧的Scala消费者仍然支持，但在下一个版本中将不再使用它们，并将在未来的主要版本中删除。
- 使用新的消费者工具像 MirrorMaker 和 Console Consumer 不再使用
--new-consumer和--new.consumer开关，通过 Kafka broker 的连接而不再通过连接 ZooKeeper 集群。另外，旧的消费者使用控制台消费已被弃用，并将在以后的主要版本中被删除。 - kafka 集群现在可以通过 cluster id 来唯一标识。当代理服务器升级到 0.10.1.0 时将自动生成。cluster id 可以使用在 kafka.server:type=KafkaServer,name=ClusterId ，它是元数据响应的一部分，Serializers, client interceptors 和 metric reporters 通过实现 ClusterResourceListener 接口可以接收 cluster id。
- BrokerState "RunningAsController" (value 4) 已经被删除，因为一个 bug，代理服务器在这个状态的时间非常短暂就会变为退出状态，因此删除的影响是最小的。检测给定的代理服务器是否是控制器推荐的方式是通过 kafka.controller:type=KafkaController,name=ActiveControllerCount 来衡量。
- 新的Java消费者现在允许用户通过分区上的时间戳搜索偏移量。
- 新的Java消费者现在支持后台线程心跳。有一个新的配置
max.poll.interval.ms控制在调用之前消费者主动离开组的最大时间（默认为5分钟）。request.timeout.ms的值必须大于max.poll.interval.ms的值，因为这是 JoinGroup 请求在消费者重新平衡时在服务器上阻塞的最长时间，因此我们已更改其默认值到5分钟以上。 最后，session.timeout.ms 的默认值已经被调整到10秒，max.poll.records 默认值已经被更改为500。 - 当使用授权并且用户对 topic 没有描述授权时，代理服务器将不会再将 TOPIC_AUTHORIZATION_FAILED
错误返回给请求，因为这会泄漏 topic 名称。而是返回 UNKNOWN_TOPIC_OR_PARTITION 错误代码。 这可能会导致生产者和消费者意外的超时或延迟，因为Kafka客户端通常会重新自动重复未知的主题错误。 如果怀疑这可能发生，应该查看客户端日志。 - 获取响应默认情况下具有大小限制（消费者为50 MB，复制为10 MB）。 现有的每个分区限制也适用（1 MB的消费者和复制）。 请注意，这两个限制都不是绝对最大值，如下一节所述。
- 如果发现大于响应/分区大小限制的消息，消费者和副本可以进行。 更具体地说，如果fetch的第一个非空分区中的第一个消息大于两个或两个限制，则该消息仍将被返回。
- 重载的构造函数被添加到 kafka.api.FetchRequest 和 kafka.javaapi.FetchRequest，以允许调用者指定分区的顺序（因为v3中的顺序是重要的）。 先前存在的构造函数已被弃用，并且在发送请求之前将分区进行混洗，以避免出现饥饿问题。
新协议版本
- ListOffsetRequest v1支持基于时间戳的精确偏移搜索。
- MetadataResponse v2引入了一个新的字段：“cluster_id”。
- FetchRequest v3支持限制响应大小（除了现有的每个分区限制），如果需要进行更新，则返回大于限制的消息，并且请求中分区的顺序很重要。
- JoinGroup v1引入了一个新的字段：“rebalance_timeout”。
