1

我们产品的单个安装将其配置存储在一组数据库表中。

没有任何安装“知道”任何其他安装。

客户在地理位置相距遥远的不同数据中心安装我们产品的多个副本一直很常见。这意味着配置信息需要创建一次，然后导出到其他系统。然后修改一些配置以适应当地条件。例如更改 IP 地址等。这是一种笨重且容易出错的方法。

我们现在收到要求能够制定更无缝的全球数据共享策略，但仍允许本地修改。

如果不是本地修改位，那么我们可以使用 Oracle 的数据复制功能。

由于 HA 要求，在一个数据库中拥有所有配置不是一种选择。

有没有其他人遇到过这个问题，你有没有为此找到一个好的编程解决方案？知道任何可以描述部分或完整解决方案的好论文吗？

我们是基于 *nix 的，并且使用 Oracle。更改应该很快（一秒或两秒）复制到所有节点。

4

2 回答 2

2

我不确定你有多大可能改变你处理配置的方式，但我们通过使用本地覆盖的想法实现了类似的东西。具体来说，您有两个相同的配置表（称为 CentralConfig 和 LocalConfig）。CentralConfig 维护在中央位置，并复制到您的卫星位置，在那里它是只读的。LocalConfig 可以在本地站点设置。查询配置数据的过程首先在 LocalConfig 表中查找数据，如果未找到，则从 CentralConfig 表中检索它。

例如，如果您尝试使用 v$parameter 表中的值执行此操作，则可以使用 SQL 分析中的 FIRST_VALUE 函数查询您的配置：

  SELECT DISTINCT
         NAME
       , FIRST_VALUE(VALUE) OVER(PARTITION BY NAME 
                                     ORDER BY localsort
                                ) VALUE
    FROM (SELECT t.*
               , 0 localsort
            FROM local_parameter t
           UNION
          SELECT t.*
               , 1 localsort
            FROM v$parameter t
         )
ORDER BY NAME;

联合中的 localsort 列只是为了确保 local_parameter 值优先于 v$parameter 值。

在我们的系统中，它实际上比这要复杂得多。除了您要查找的参数的“名称”之外，我们还有一个“上下文”列来描述我们正在查找的上下文。例如，我们可能有一个集中设置的参数“timeout”，但即使在本地，我们也有多个使用该值的组件。它们可能都相同，但我们也可能希望对它们进行不同的配置。因此，当工具查找“超时”值时，它也会受到范围的限制。在配置本身中，当我们定义我们想要的范围时，我们可能会使用通配符，例如：

CONTEXT       NAME    VALUE
------------- ------- -----
Comp Engine A timeout    15
Comp Engine B timeout    10
Comp Engine % timeout     5
%             timeout    30

上面的配置说，对于所有组件，使用 30 的超时，但对于任何类型的 Comp Engine，使用 5 的超时，但是对于 Comp Engines A 和 B，分别使用 15 和 10。最后两个配置可以在 CentralConfig 中维护，但其他两个可以在 LocalConfig 中维护，您可以通过以下方式解析设置：

  SELECT DISTINCT
         NAME
       , FIRST_VALUE(VALUE) OVER(PARTITION BY NAME 
                                     ORDER BY (TRANSLATE(Context
                                                        , '%_'
                                                        , CHR(1) || CHR(2)
                                              ) DESC
                                            , localsort
                                ) VALUE
    FROM (SELECT t.*
               , 0 localsort
            FROM LocalConfig t
           WHERE 'Comp Engine A' LIKE Context
           UNION
          SELECT t.*
               , 1 localsort
            FROM CentralConfig t
           WHERE 'Comp Engine A' LIKE Context
         )
ORDER BY NAME;

它基本上是相同的查询，除了我在我的 localsort 之前插入那个 TRANSLATE 表达式并且我限制了 Context。它所做的是将 % 和 _ 字符转换为 chr(1) 和 chr(2)，这将使它们按降序排列在字母数字字符之后。这样，明确定义的“Comp Engine A”将出现在“Comp Engine %”之前，而后者又将出现在“%”之前。在上下文定义相同的情况下，本地配置优先于中央配置；如果您希望 local 始终胜过 central，即使在 central 范围更窄的情况下，您也只需颠倒两个排序术语的位置即可。

于 2009-08-07T14:51:26.650 回答
0

The way we're doing this is similar with Steve's. First you need a Central Configure Service to save all the configure you want to apply to the distributed environment. Every time you want to modify the config, modify it in the Central Configure Service. In each production host you can write a loop script to update the configure. For a more sophisticated solution, you need to set up some strategy to avoid a wrong configure batch into all servers, that would be a disaster. Maybe you need a simple lock or a grey release process.

于 2014-02-26T07:17:43.757 回答