启动 OceanBase 数据库时 -o 内的参数是否会持久化

通常，除了 bootstrap 首次启动 OBServer 时需要通过 -o 来指定集群配置项外，日常的 OBServer 重启不需要指定配置项。使用 -o 选项既可以指定集群配置项，也可以采用 key@tenant_id=value 的形式指定租户配置项，如下所示。

./observer -o "freeze_trigger_percentage@1001=30,freeze_trigger_percentage@1003=30,enable_monotonic_weak_read=false"

其中，freeze_trigger_percentage 只对 tenant_id 为 1001 和 1003 的租户生效，enable_monotonic_weak_read 对所有租户生效。注意，等号两侧不能有空格。 ​ 使用 -o 来指定集群或租户的配置项是一种临时性的行为，是解决已有问题的权宜之计，它不具有传递性和可继承性。按照目前的设计，-o 选项设置的配置项不会刷到内部表中，这可能导致重启后 -o 选项设置的值被覆盖，是否会被覆盖，取决于该配置项在使用 -o 参数设置前，有没有通过alter system set 修改过。 ​ 举例以动态生效的集群级配置项 memory_limit_percentage 为例（默认值为 81），使用 deploy.py 部署。

1. reboot 集群，不在 -o 中设置 memory_limit_percentage。

2. 以 sys 租户登录 alter system set memory_limit_percentage=81;，并使用 select gmt_create, gmt_modified, name, value, config_version from __all_sys_parameter; 查看内部表。

   

3. stop 集群。在 config.py 中增加 ObCfg.init_config['memory_limit_percentage']=82；然后再 start 集群。以 sys 租户登录后进行以下操作，结果如图。

   

   这是因为，处理 -o 参数时会将当前时间戳设为配置项的版本号，因此，alter system set 触发的刷内部表行为不会把 -o 设的值覆盖掉。

4. stop 集群。在 config.py 中去掉对 memory_limit_percentage 的设置。然后再 start 集群。以 sys 租户登录后进行以下操作，结果如图。

   

可以看到，memory_limit_percentage 的值变成了 81，和内部表中的值一样了。这是因为，OBServer 会从内部表中读取配置项的值，但同时会将该配置项对应的版本号强设为 0。而重启时，OBServer 会刷内部表，于是，memory_limit_percentage 的值就被内部表中的值覆盖了。

注意​:

1. 如果通过 -o 设置某配置项之前，没有通过 alter system set 修改过该配置项（即没有上面的步骤 2），那么，无论之后再重启多少次，该配置项的值都是通过 -o 设置的值。这是因为，-o 设置的值不会写入内部表，所以内部表中就不会有该配置项，也就不存在“内部表中的值把 -o 的值覆盖”的情况了。
2. 对于重启生效的配置项，在步骤 4 中并不会看到截图所示情况，注意再次重启，才能看到。
3. 以上结论对租户级配置项同样适用。

适用版本

OceanBase 数据库 V2.x 和 V3.x 版本。