1

製品を 1 回インストールすると、その構成が一連のデータベース テーブルに保存されます。

どのインストールも、他のインストールについて「認識」していません。

お客様が地理的に離れた異なるデータセンターに製品の複数のコピーをインストールすることは常に一般的です。これは、構成情報を一度作成してから、他のシステムにエクスポートする必要があることを意味します。構成の一部は、ローカルの条件に合わせて変更されます。たとえば、IP アドレスの変更などです。これは扱いにくく、エラーが発生しやすいアプローチです。

現在、グローバル データを共有するためのよりシームレスな戦略を持ちながら、ローカルでの変更を許可する機能についてのリクエストが寄せられています。

ローカル変更ビットがなければ、Oracle のデータ レプリケーション機能を使用できます。

HA 要件のため、1 つのデータベースにすべての構成を含めることはできません。

他の誰かがこの問題に遭遇したことがありますか?また、これに対する適切なプログラムによる解決策を見つけたことがありますか? 部分的または完全な解決策を説明している優れた論文を知っていますか?

私たちは *nix ベースで、Oracle を使用しています。変更はすべてのノードにかなり迅速に (1 秒か 2 秒で) レプリケートされるはずです。

4

2 に答える 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 の値よりも優先されるようにするためのものです。

私たちのシステムでは、実際にはこれよりもはるかに洗練されています。検索しているパラメーターの「名前」に加えて、探しているコンテキストを説明する「コンテキスト」列もあります。たとえば、一元的に設定されたパラメーター「タイムアウト」があるかもしれませんが、ローカルであっても、この値を使用する複数のコンポーネントがあります。それらはすべて同じかもしれませんが、それらを別の方法で構成したい場合もあります。そのため、ツールが「タイムアウト」値を検索すると、スコープによっても制約されます。構成自体では、次のように、スコープに必要なものを定義するときにワイルドカードを使用できます。

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

上記の構成では、すべてのコンポーネントに対してタイムアウト 30 を使用しますが、任意のタイプのコンプ エンジンではタイムアウト 5 を使用しますが、コンプ エンジン A と B ではそれぞれ 15 と 10 を使用します。最後の 2 つの構成は CentralConfig で維持される可能性がありますが、他の 2 つは 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 がより厳密にスコープされている場合でも、2 つのソート条件の位置を逆にするだけです。

于 2009-08-07T14:51:26.650 に答える
0

これを行う方法は、Steve のものと似ています。最初に、分散環境に適用するすべての構成を保存するための中央構成サービスが必要です。構成を変更するたびに、Central Configure Service で変更します。各本番ホストでは、ループ スクリプトを記述して構成を更新できます。より洗練されたソリューションの場合、すべてのサーバーへの誤った構成バッチを回避するための戦略を設定する必要があります。これは災害になる可能性があります。単純なロックまたはグレーのリリース プロセスが必要な場合があります。

于 2014-02-26T07:17:43.757 に答える