fabric1.4.2从kafka迁移到raft(命令版)
实现所依赖的原理详见https://blog.csdn.net/qq_42750537/article/details/96428765
这一篇用来记录具体命令，及遇到的一些问题。
构建RatfMetadata
1)创建一个基于raft的网络（v1.4.2），需使用和现kafka网络相同的证书文件
2）在新的raft网络中执行创建通道–>执行交易的相关命令
3）执行以下命令，拉取系统通道的配置信息
切换环境
export CORE_PEER_LOCALMSPID="OrdererMSP"
export CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto-config/ordererOrganizations/example.com/orderers/orderer1.example.com/msp/tlscacerts/tlsca.example.com-cert.pem
export CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto-config/ordererOrganizations/example.com/users/[email protected]/msp
export ORDERER_CA=/opt/gopath/src/github.com/hyperledger/fabric/peer/addorg/crypto-config/ordererOrganizations/example.com/orderers/orderer1.example.com/msp/tlscacerts/tlsca.example.com-cert.pem
export CH_NAME=testchainid
export CONFIGTXLATOR_URL=http://127.0.0.1:7059
configtxlator start > log.log 2>&1 &
echo $CH_NAME
生成可读配置块文件
peer channel fetch config config_block.pb -o orderer1.example.com:7050 -c $CH_NAME --tls --cafile $ORDERER_CA
curl -X POST --data-binary @config_block.pb "$CONFIGTXLATOR_URL/protolator/decode/common.Block" | jq . > config_block.json
jq .data.data[0].payload.data.config config_block.json> config.json
1）打开config.json。搜索ConsensusType。
2）取出ConsensusType部分,修改状态为STATE_MAINTENANCE。保存为文件raft.json
进入维护状态
在kafak-fabric网络中转换每个通道的的配置
执行以下命令
1.切换环境
2.生成可读配置块文件
3.修改配置块信息
jq ".channel_group.groups.Orderer.values.ConsensusType.value.state = \"STATE_MAINTENANCE\"" config.json > modified_config.json
4.将修改后的信息与原有配置信息组合
curl -X POST --data-binary @config.json "$CONFIGTXLATOR_URL/protolator/encode/common.Config" > config.pb
curl -X POST --data-binary @modified_config.json "$CONFIGTXLATOR_URL/protolator/encode/common.Config" > modified_config.pb
curl -X POST -F channel=$CH_NAME -F "[email protected]" -F "updated=@modified_config.pb" "${CONFIGTXLATOR_URL}/configtxlator/compute/update-from-configs" > config_update.pb
curl -X POST --data-binary @config_update.pb "$CONFIGTXLATOR_URL/protolator/decode/common.ConfigUpdate" | jq . > config_update.json
echo '{"payload":{"header":{"channel_header":{"channel_id":"'$CH_NAME'", "type":2}},"data":{"config_update":'$(cat config_update.json)'}}}' | jq . > config_update_in_envelope.json
curl -X POST --data-binary @config_update_in_envelope.json "$CONFIGTXLATOR_URL/protolator/encode/common.Envelope" > config_update_in_envelope.pb
5.获得半数以上的组织签名（这里只写出签名命令）
export CORE_PEER_LOCALMSPID=OrdererMSP
export CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto-config/ordererOrganizations/example.com/users/Admin\@example.com/msp
export CORE_PEER_ADDRESS=peer0.org1:7051
export CORE_PEER_TLS_ENABLED=true
export CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto-config/ordererOrganizations/example.com/orderers/orderer1.example.com/tls/ca.crt
export CORE_PEER_TLS_KEY_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto-config/ordererOrganizations/ecample.com/orderers/orderer1.example.com/tls/server.key
export CORE_PEER_TLS_CERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/addorg/crypto-config/ordererOrganizations/example.com/orderers/orderer1.example.com/tls/server.crt
peer channel signconfigtx -f config_update_in_envelope.pb
6.更新配置
peer channel update -f config_update_in_envelope.pb -c $CH_NAME -o orderer1.example.com:7050 --tls true --cafile $ORDERER_CA
pkill configtxlator
切换export CH_NAME=其他用户通道，依次执行上述操作
备份文件并关闭服务器
1.可选，主要在生产环境下迁移失败时回滚使用。测试环境可不执行
在维护模式下切换到Raft
新建scripts文件夹，将之前准备的raft.json导入。
在每个通道上依次执行以下命令
1.切换环境
2.生成可读配置块文件
3.修改配置块信息
jq -s '.[0]*{"channel_group":{"groups":{"Orderer": {"values": {"ConsensusType": .[1]}}}}}' config.json ./scripts/raft.json > modified_config.json
4.将修改后的信息与原有配置信息组合
5.获得半数以上的组织签名（这里只写出签名命令）
6.更新配置
切换export CH_NAME=其他用户通道，依次执行上述操作
重启并验证领导者
停止所有排序服务节点，停止所有Kafka代理和Zookeepers，然后仅重新启动排序服务节点.
启动成功查看orderer日志
选举成功
切换到正常模式
但是此时还不能正常交易，需切换配置快的状态为NORMAL
在每个通道上依次执行以下命令
1.切换环境
2.生成可读配置块文件
3.修改配置块信息
jq ".channel_group.groups.Orderer.values.ConsensusType.value.state = \"STATE_NORMAL\"" config.json > modified_config.json
4.将修改后的信息与原有配置信息组合
5.获得半数以上的组织签名（这里只写出签名命令）
6.更新配置
切换export CH_NAME=其他用户通道，依次执行上述操作
完成此过程后，排序服务现在可以接受所有渠道上的所有交易。如果您按照建议停止了peers和应用程序，现在可以重新启动它们。
问题点记录
1.排序节点重启报错：no such hosts：
问题原因：原fabric网络orderer镜像的映射里没包含orderer节点的映射
解决办法：进入到orderer容器，添加orderer节点映射
2：排序节点重启报错，tls连接失败
原因：原yaml文件的tls相关配置是kafka识别的，raft无法识别。需新增raft可识别配置
解决方法，进入响应容器中的/etc/profile里加入如上配置，source一下即可