Question

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

没有任何安装'知道'任何其他安装。

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

我们现在要求能够采用更加无缝的策略来共享全局数据，但仍允许进行本地修改。

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

由于HA要求，一个数据库中的所有配置都不是一个选项。

有没有其他人遇到过这个问题，你有没有找到一个好的程序化解决方案呢？知道任何可能描述部分或完整解决方案的优秀论文吗？

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

Answer 1

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

例如，如果您尝试使用v $参数表中的值执行此操作，则可以使用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 $参数值。

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

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

上面的配置说，对于所有组件，使用30的超时，但对于任何类型的Comp Engines，使用5的超时，但对于Comp Engines A＆amp; B，使用15＆amp;分别为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）＆amp; chr（2），它将使它们按降序排序的字母数字字符排序。通过这种方式，明确定义的“Comp Engine A”将出现在“Comp Engine％”之前，而“Comp Engine％”将在“％”之前出现。在上下文定义相同的情况下，本地配置优先于中心配置;如果你希望本地总是胜过中央，即使在中央范围更紧密的情况下，你只需要反转两个排序术语的位置。

Answer 2

我们这样做的方式与史蒂夫的相似。首先，您需要中央配置服务来保存要应用于分布式环境的所有配置。每次要修改配置时，请在中央配置服务中对其进行修改。在每个生产主机中，您可以编写循环脚本来更新配置。对于更复杂的解决方案，您需要设置一些策略以避免错误的配置批处理到所有服务器，这将是一场灾难。也许您需要一个简单的锁定或灰色释放过程。

Where \如何存储分布式配置数据

2 个答案: