注意：本文档假设您对通道配置更新事务有很高的专业知识。由于迁移过程涉及多个通道配置更新事务，因此在未熟悉“ Add an Organization to a Channel”教程(该教程详细描述了通道更新过程)之前，不要尝试从Kafka迁移到Raft。
对于希望将channels从基于Kafka的转换为基于Raft的排序服务的用户，v1.4.2允许通过网络中每个通道上的一系列配置更新事务来完成此操作。
本教程将在较高的层次上描述这个过程，在必要时调用特定的细节，而不是详细显示每个命令。
在尝试迁移之前，请考虑以下因素：
此过程仅用于从Kafka迁移到Raft。目前不支持在任何其他orderer共识类型之间迁移。迁移是一种不可逆过程。一旦orderer服务迁移到Raft，并开始提交交易，就不可能回到Kafka。由于排序节点必须关闭并重新启动，因此在迁移期间必须允许停机。只有在本文档后面规定的迁移点进行备份时，才可以从不成功的迁移中恢复。如果您不进行备份，并且迁移失败，您将无法恢复以前的状态。所有通道都必须在同一个维护窗口中迁移。在恢复操作之前，不可能只迁移一些通道。在迁移过程结束时，每个channel都将具有相同的Raft节点的consenter集。这与排序系统channel中存在的同一个consenter集相同。可依此判断是否成功迁移。迁移是使用已部署的orderer节点的现有分类帐，在本地进行迁移的。迁移后可根据需求进行添加或删除orderer。迁移分五个阶段进行。
系统处于维护模式，其中应用程序事务被拒绝，并且只有排序服务管理员才能更改通道配置。系统停止，并在迁移期间发生错误时进行备份。系统启动，每个通道都有其共识类型和元数据修改。系统重新启动，现在正在Raft达成共识; 检查每个通道以确认它已成功达到法定人数。系统退出维护模式并恢复正常功能。在尝试迁移之前，您应该采取几个步骤。
设计Raft部署，决定哪些排序服务节点将作为Raft consenters保留。您应该在群集中部署至少三个排序节点，但请注意，如果节点出现故障，部署至少五个节点的同意者集将保持高可用性，而一个节点出现故障时，三节点配置将失去高可用性任何原因（例如，在维护周期中）。
准备用于构建Ratf
Metadata配置的材料。
注意：所有通道都应接收相同的Raft Metadata配置
。有关这些字段的更多信息，请参阅 Raft configuration guide
。注意:您可能会发现，使用Raft consensus协议引导一个新的排序网络，然后从其配置中复制和修改consensus元数据部分是最容易的。在任何情况下，您都需要(对于每个排序节点)
hostnameportserver certificateclient certificate编译系统中所有通道（系统和应用程序）的列表。确保您具有正确的凭据以签署配置更新。例如，相关的排序服务管理员身份。
确保所有排序服务节点都运行相同版本的Fabric，并且此版本为v1.4.2或更高版本。
确保所有对等体至少运行Fabric的v1.4.2。确保所有通道都配置了支持迁移的通道功能。
Orderer capabilityV1_4_2（或以上）。Channel capabilityV1_4_2（或以上）。在将排序服务设置为维护模式之前，建议停止网络的peers和clients。不过，让peers或clients保持正常运行也是安全的，只是这样排序服务将拒绝他们的所有请求，而且他们的日志将被非错误但有误导性的失败消息填满。
按照“ 将通道添加到通道” 教程中的过程**，从系统通道开始，提取，转换和调整每个通道**的配置范围。您应在此步骤中更改的唯一字段位于通道配置中/Channel/Orderer/ConsensusType。在通道配置的JSON表示中，这将是 .channel_group.groups.Orderer.values.ConsensusType。
在ConsensusType由三个值表示：Type，Metadata，和 State，其中：
Type是kafka或etcdraft（Raft）。该值只能在维护模式下更改。如果Type是kafka，Metadata将是空的。如果ConsensusType是etcdraft。必须携带有效Raft metadata，更多关于此的信息见后文。State应该是NORMAL–>当信道正在处理的事务，或者是MAINTENANCE–>在迁移过程中。在通道配置更新的第一步中，仅将State 从NORMAL更改为MAINTENANCE。不要改变现有的Type或Metadata。请注意，目前Type应该是kafka。
在维护模式下，Deliver将拒绝正常事务、与迁移无关的配置更新以及用于检索新块的peers请求。这样做是为了防止在包括迁移期间备份和必要时还原peer的需要，因此它们仅在迁移成功完成后才接收更新。换句话说，我们希望将排序服务备份点（详见下一步）保持在peer的分类帐之前，以便能够在需要时执行回滚。
但是，排序节点管理员可以发出Deliver请求（他们需要能够执行这些请求才能继续迁移过程）。
验证每个排序服务节点是否已在每个通道上进入维护模式。这可以通过获取最后一个配置块并确保每个通道上的 Type, Metadata, State分别为kafka、empty(记住kafka没有Metadata)和MAINTENANCE来实现。
如果通道已成功更新，则排序服务现在可以进行备份。
关闭所有排序节点，Kafka服务器和Zookeeper服务器。首先关闭排序服务节点这是非常重要的一点。然后，在允许Kafka服务将其日志刷新到磁盘（这通常需要大约30秒，但可能需要更长时间，具体取决于您的系统）后，应关闭Kafka服务器。在关闭排序服务节点的同时关闭Kafka brokers可能导致订货人的文件系统状态比Kafka brokers更新，这可能会阻止您的网络启动。
创建这些服务器的文件系统的备份。然后重新启动Kafka服务，然后重新启动排序服务节点。
迁移过程的下一步是为每个通道更新另一个通道配置。在此配置中，切换Type到etcdraft （Raft），同时保持State在MAINTENANCE，并填写 Metadata配置。强烈建议在所有通道上都使用相同的 Metadata配置。如果要使用不同的节点建立不同的consenter集，在系统重新启动到etcdraft模式后，您将能够重新配置 Metadata。提供相同的元数据对象，从而提供相同的consenter集，意味着当重新启动节点时，如果系统通道形成法定人数并且可以退出维护模式，则其他通道可能也能够这样做。如果向每个通道提供不同的consenter集可以使一个通道成功形成集群，而另一个通道将失败。
然后，ConsensusType 通过拉动和检查每个通道的配置来验证每个排序服务节点是否已提交更改配置更新。
注意：更改的事务ConsensusType必须是重新启动节点之前的最后一个配置事务（在下一步中）。如果在此步骤之后发生某些其他配置事务，则节点很可能在重新启动时崩溃，或导致未知的行为。
注意:重启后必须退出维护模式。
在ConsensusType每个通道上完成更新后，停止所有排序服务节点，停止所有Kafka代理和Zookeepers，然后仅重新启动排序服务节点。它们应该作为Raft节点重新启动，每个通道形成一个集群，并在每个通道上选择一个领导者。确保通过检查节点日志来验证每个渠道上的领导者是否已经当选（您可以在下面查看要查找的内容）。这将确认该过程已成功完成。
选举领导者时，日志将显示每个频道：
"Raft leader changed: 0 -> node-number channel=channel-name node=node-number "例如：
2019-05-26 10:07:44.075 UTC [orderer.consensus.etcdraft] serveRequest -> INFO 047 Raft leader changed: 0 -> 1 channel=testchannel1 node=2在该示例中node 2报告说，通过channel testchannel1的集群选择了一个leader (the leader is node 1)）。
在每个通道上执行另一个通道配置更新（将配置更新发送到您之前发送配置更新的相同排序节点），将State从MAINTENANCE切换为NORMAL。像往常一样，从系统通道开始。如果在排序系统channel上取得成功，则迁移很可能在所有channel上成功。要进行验证，请从排序节点获取系统通道的最后一个配置块，验证它是否State 为现在NORMAL。为了完整性，请在每个排序节点上进行验证。
完成此过程后，排序服务现在可以接受所有渠道上的所有交易。如果您按照建议停止了peers和应用程序，现在可以重新启动它们。
如果在退出维护模式之前在迁移过程中出现问题，只需执行下面的回滚过程。
关闭排序节点和Kafka服务（服务器和Zookeeper集合）。在更改之前，将这些服务器的文件系统回滚到维护模式下的备份ConsensusType。重启所述服务器，排序节点将以维护模式引导至Kafka。发送退出维护模式的配置更新以继续使用Kafka作为您的共识机制，或在备份点后恢复说明并修复阻止Raft仲裁形成的错误，并使用更正的Raft配置重试迁移Metadata。有一些状态可能表明迁移失败：
某些节点崩溃或关闭。日志中没有每个频道成功领导者选举的记录。试图在系统通道上切换到NORMAL模式失败。