哪里如何存储分布式配置数据

StackOverflow https://stackoverflow.com/questions/1244455

题

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

对于任何其他安装，都没有安装“知道”。

对于客户，在不同的数据中心将我们的产品的多个副本安装在地理上很远的地方一直很常见。这意味着需要创建一次配置信息，然后导出到其他系统。然后对某些配置进行修改以适合当地条件。例如，更改IP地址等。这是一种笨拙的错误方法。

现在，我们已经获得了具有更无缝的策略来共享全球数据的要求，但仍允许局部修改。

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

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

还有其他人遇到这个问题，您是否曾经为此找到了一个很好的程序化解决方案？知道有任何可能描述部分或完整解决方案的好论文吗？

我们 *基于NIX，并使用Oracle。更改应很快复制到所有节点（第二或2个节点）。

有帮助吗？

解决方案

我不确定您如何改变处理配置的方式有多大的可能性，但是我们通过使用本地覆盖的想法实现了与此相似的内容。具体来说，您有两个相同的配置表（称为CentralConfig和localconfig）。 CentralConfig位于中央位置，并将其复制到您的卫星位置，仅阅读它。可以在本地站点设置LocalConfig。查询配置数据的过程首先查找LocalConfig表中的数据，如果找不到的话，请从CentralConfig表中检索它。

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

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

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

上面的配置显示，对于所有组件，使用30个超时，但是对于任何类型的Comp引擎，使用5个超时，但是对于Comp引擎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之前的表达式，并且我正在限制上下文。它正在做的是将％和_字符转换为chr（1）和chr（2），这将使它们在降序中的字母数字字符之后排序。通过这种方式，明确定义的“ Comp Engine A”将在“ Comp Engine％”之前出现，而“ Comp Engine％”将在“％”之前出现。如果上下文的定义相同，则本地配置优先于中心。如果您希望本地人始终胜过中央，即使在中央更紧密地进行范围的情况下，您也只会扭转两种术语的位置。

其他提示

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

许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top