这里假设各位读者大大已经根据 FISCO BCOS 官网 成功搭建了一条 FISCO BCOS 链，启动链成功，并且熟悉如何如何使用 console 控制台。下面将基于此条件，讲解下 FISCO BCOS 节点中的 group.x.ini 文件中的各个配置项。
1. consensus
这一块的配置比较抽象，主要是用于共识优化，无法使用实验的方式进行可视化展示。所以大家参考 官方文档 上的描述进行理解即可 。正常情况下，默认值即可满足我们的要求，如有特殊需求，再根据官方文档进行优化。
2. storage 之 type ( mysql & rocksdb )
这里的配置主要是关于存储的，可以根据需要切换存储为 rocksdb, mysql , scalable 这三种。下面我们来看看如何进行切换。
首先，我们看到默认的存储模式为 rocksdb, 以 node0 为例，进入到 fisco/nodes/127.0.0.1/node0/data/group1 目录，可以看到 rocksdb 的数据存储在这个目录下
进入到 nodes/127.0.0.1/node0/conf 目录，修改 group.1.ini 中的配置如下。首先修改 type=mysql, 然后在输入 db_ip, db_port, db_usrename, db_name 这个几个参数。注意，配置 type=mysql 时，需要预先在对应的服务器上安装 mysql （ 这里因为我是 在本机上安装了 mysql , 所以配置的是 127.0.0.1 ）
接下来，我们就来重启 node0。 进入到 fisco/nodes/127.0.0.1/node0/ 目录，执行 如下命令。
进入到 fisco/nodes/127.0.0.1/node0/log 目录，取最新的日志文件，检查下 node0 的共识情况。这里我们看到 node0 节点共识正常。
继续看下 node0 对应的 mysql 数据库 （ 这里是 node0 库 )。这里我们看到 node0 库中自动创建了系统表。
这里，不知道大家有没有注意到下面几点：
1) node0 库我们没有预先创建，启动 node0 节点后，FISCO BCOS 自动为我们进行了创建。同时 node0 库中的系统表也自动进行了创建。
2) 我们只修改了 node0 的存储类型为 mysql , 其他节点 node1/node2/node3 的存储类型不变，还是为 rocksdb，这表明各个节点的存储是独立的，互不影响的
3） 修改 node0 的存储为 mysql 后，node0 原始的 rocksdb 数据我们没有做任何改动，那么这部分数据有什么影响呢 ?
4) 如果再从 mysql 切换回 rocksdb 会有什么影响吗 ？
针对上面第三点，我们做一下实验看看效果。进入到 fisco/nodes/127.0.0.1/node0 目录，执行 mv 命令，把 data 目录重命名。 其实这里可以直接用 rm 命令删除 data ，但后续的实验会用到这个旧的 rockdb 数据，所以这里进行了重命名。
然后是重启 node0 ，我们看到这里重新生成了 data 目录。
但是当我们进入到这个 data 目录中查看详细数据的时候，发现只有一个 pbftMsgBackup目录，缺少了 block 目录 （ 章节开头部分可以看到 rockdb 存储模式下，是存在 block 目录的 ) 。说明这个 data 目录就是个花架子，根本没有任何数据，实际的数据还是存储在 mysql 中。至此，我们确认了一点，就是当存储从 rocksdb 切换到 mysql 后，所有的数据就会相应的存储在 mysql 中 ( 当然，节点会把历史数据从其他节点同步过来后再存储到 mysql 中， 而不会从 rocksdb 中同步 )， 原始 rocksdb 对应的 data 目录不再使用。
那么我们继续来看第 4 点 “如果再从 mysql 切换回 rocksdb 会有什么影响吗 ？“ 。 首先，node0 在 mysql 存储下，我们使用 console 登陆节点，然后执行 deploy HelloWorld 部署 （ 这里执行 deploy 只是单纯的为了增加块高。具体 console 的配置使用可以参考 官方文档 ）
接下来，我们进入 fisco/nodes/127.0.0.1/node0 目录。还记得我们上面备份的 data 目录吗，现在我们要把它还原，模拟从 mysql 切换为 rocksdb 的场景。别看这里操作比较多，其实就一个目的，模拟下从 mysql 切换回 rocksdb 后，mysql 数据库和原始 rocksdb data 目录有什么影响。
接下来，停止 node0 。 然后修改 conf/group.1.ini 中 type=rocksdb。
这里，为了观察到实验效果，我们删除掉 mysql 中的 node0 数据库 （ 实际应用中，可以不用删除，不影响 )
接着，我们启动 node0 ， 然后查看 node0 的共识。发现 node0 启动成功，共识也正常。这里发生的数据变化状态如下，首先我们假设所有节点的数据状态变化为 0 -> 1 -> 2 。当 node0 从 rocksdb 切换为 mysql 的那一刻，node0 处于的数据状态为 0 （ 这里假设处于 0 状态，其他所有节点也是处于 0 状态 ）。 然后 node0 切换为 mysql， 这时 mysql 中的数据状态也是处于 0。 因为紧接着，我们执行了两次 deploy ，所以 mysql 数据状态变为了 2。之后，又应为我们从 mysql 切换回了 rocksdb, 当 node0 启动的时候，node0 对应的 rocksdb 数据状态还是处于 0, 同时node0 向其他节点发送数据状态查询信息，其他节点返回当前状态为 2，这样 node0 知道自己的数据状态落后了，它向其他节点请求 1，2 的变更数据，最后把自己的 rocksdb 的数据更新到状态 2。
以上就是我们模拟的 node0 在 rocksdb 和 mysql 之间进行来回切换后，node0 的数据发生的变化。也是大家在实际应用过程中可能碰到的问题，但是实际情况下，没有人会这样来回切换存储类型，因为没必要。
