![]() |
1
2
我不确定您如何改变处理配置的方式,但是我们通过使用本地重写的思想实现了类似的功能。具体来说,您有两个相同的配置表(称为centralconfig和localconfig)。centralconfig保存在中心位置,并复制到卫星位置,在那里它是只读的。可以在本地站点上设置localconfig。查询配置数据的过程首先在localconfig表中查找数据,如果找不到,则从centralconfig表中检索数据。 例如,如果您试图使用v$参数表中的值执行此操作,则可以使用SQL分析中的第一个“值”函数查询配置:
联合中的localsort列只是为了确保本地_参数值优先于v$参数值。 在我们的系统中,它实际上比这个复杂得多。除了要查找的参数的“名称”之外,我们还有一个“上下文”列,描述我们要查找的上下文。例如,我们可能有一个中央设置的参数“timeout”,但即使在本地,我们也有多个使用该值的组件。它们可能都是相同的,但我们也可能希望对它们进行不同的配置。因此,当工具查找“超时”值时,它还受范围的约束。在配置本身中,我们可以在定义范围所需的内容时使用通配符,例如:
上面的配置说明,对于所有组件,使用30的超时,但是对于任何类型的comp引擎,使用5的超时,但是对于comp引擎A&B,分别使用15&10。最后两个配置可以在centralconfig中维护,但另外两个配置可以在localconfig中维护,您可以通过以下方式解析设置:
它基本上是相同的查询,只是我在本地排序之前插入了转换表达式,并且限制了上下文。它所做的是将%和u字符转换为chr(1)&chr(2),这将使它们按字母数字字符降序排序。这样,明确定义的“comp engine a”将出现在“comp engine%”之前,而“comp engine%”又将出现在“%”之前。在上下文定义相同的情况下,本地配置优先于中心配置;如果您希望本地配置总是胜过中心配置,即使在中心配置范围更紧的情况下,您也只需反转这两个排序项的位置。 |
![]() |
2
0
我们这样做的方式和史蒂夫的相似。 首先,您需要一个中心配置服务来保存所有要应用于分布式环境的配置。每次您想要修改配置时,都要在中央配置服务中对其进行修改。在每个生产主机中,您可以编写一个循环脚本来更新配置。 对于更复杂的解决方案,您需要设置一些策略,以避免在所有服务器中错误地配置批处理,这将是一个灾难。也许你需要一个简单的锁或者灰色释放过程。 |
![]() |
thanuja · 没有Namenode的HBase高可用性高可用性 7 年前 |