fabric1.4.2从kafka迁移到raft(命令版)
这一篇用来记录具体命令,及遇到的一些问题。
构建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/Admin@example.com/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
构建Metadata
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 "original=@config.pb" -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一下即可