レプリケーションプロセス¶

このセクションでは、サーバーでカタログの変更 (ユーザーによるビューの作成など) がいつどのように行われるか、同じデータベースを共有する他のサーバーがこの変更をいつどのように認識するかについて説明します。

Virtual DataPort のカタログには、オブジェクトが一時的に保存されるメモリ内キャッシュ (データソースから取得したビューのデータを保存する キャッシュモジュール では ない) があります。このメモリ内キャッシュの目的は、毎回オブジェクト (データソース、ビューなど) をデータベースから読み込むよりも迅速にオブジェクトにアクセスできるようにすることです。Virtual DataPort が開始されるとき、このキャッシュは空であり、オブジェクトが初めてアクセスされたときに (つまり、クエリで使用されたり、Administration Tool から開かれたりしたときなど)、カタログがこのオブジェクトをメモリ内キャッシュに保存します。後からオブジェクトが変更されると (データソースの構成が変更されるなど)、カタログがこのキャッシュを更新します。

カタログは、デフォルトで、ローカルデータベース Apache Derby (デフォルトオプション) を使用します。この場合、メモリ内キャッシュを変更できるのはローカルサーバーだけであるため、メモリ内キャッシュは必ず更新されます。

カタログは外部データベースを使用する場合、このメモリ内キャッシュも使用します。ただしカタログは、このキャッシュから取得されたオブジェクトが最新であることを確認する必要があります。これは、カタログがオブジェクトをデータベースから読み取りキャッシュに保存してから、別のサーバーがそのオブジェクトを変更していた可能性があるためです。カタログは、オブジェクトが最新であることを確認するために、別のコンポーネントがオブジェクトを読み取るときに以下の手順を実行します。

1. メモリ内キャッシュにオブジェクトが 含まれていない 場合、カタログは外部データベースからそのオブジェクトを読み取り、メモリ内キャッシュに保存します。

2. メモリ内キャッシュにすでにオブジェクトが含まれている場合、カタログは外部データベースでクエリを実行し、このオブジェクトが、読み取られてからデータベース内で変更されていないかどうかを検証します。オブジェクトの期限が切れている場合は、カタログは再度オブジェクトを読み取り、キャッシュを更新します。

Web サービスについては、その Web サービスがデプロイされているかどうかに関わらず、Web サービスの構成とステータスが外部データベースに保存されます。Virtual DataPort は、外部データベースを使用するように構成されている場合、各 Web サービスがデータベースでデプロイ済み/アンデプロイのいずれにマークされているかを毎分確認します。サーバー内で Web サービスのステータスが異なる場合、サーバーは Web サービスを、それぞれデプロイまたはアンデプロイします。たとえば、サーバー #1 が Web サービス「customer」をデプロイする場合、サーバーは Web サービスのステータスがデプロイ済みであるデータベースに Web サービスを保存します。サーバー #2 が Web サービスのステータスをチェックしたときに、その Web サービスがまだデプロイされていないと、サーバーは「customer」をデプロイします。

同じことが JMS リスナーにも適用されます。1 つのサーバー上で JMS リスナーを 1 分間で開始または停止すると、他の Virtual DataPort サーバーがその JMS リスナーをそれぞれ開始または停止します。

サポート対象のデータベース¶

Virtual DataPort では、以下のデータベースにカタログを保存できます。

• Amazon Aurora MySQL

• Amazon Aurora PostgreSQL

• IBM DB2 10 および 11

• Microsoft SQL Server 2012、2014、2016、2017、および Azure SQL

• MySQL 5

• Oracle 11g、Oracle 12c、Oracle 18c、Oracle 19c

• PostgreSQL 9、10、11、12

MySQL を使用するには、パラメータ --max-allowed-packet=500M を指定して MySQL サーバーを起動し、Virtual DataPort に保存されたリソースを MySQL が受信して転送できることを確認します。このパラメータの設定方法については、「 documentation of MySQL 」を参照してください。

この機能に関する考慮事項¶

この機能を有効にする前に、次のことを考慮してください。

• この機能を使用するには、カタログのデータベースを Virtual DataPort サーバーの「可能な限り近くに」配置する必要があります。つまりデータベースが同じネットワーク内に配置されているか、少なくとも、サーバーと同じデータセンターに配置されている必要があります。この条件が満たされていると、カタログの外部データベースを使用する際のオーバーヘッドが最小限に抑えられます。それ以外の場合は、クエリの実行に多少の遅延が発生する可能性があります。

• 同じ外部データベースを共有する Virtual DataPort サーバーには、Denodo Platform の同じ更新がインストールされている必要があります。これは、ある Virtual DataPort サーバーで保存したメタデータを、それよりも古い更新がインストールされている Virtual DataPort で読み取れない場合があるためです。そのため、異なる更新がインストールされている Virtual DataPort サーバー間で同じデータベースを共有している場合、その構成はサポートされません。

• Virtual DataPort から外部データベースへの通信は安定している必要があります。ネットワークの問題などが原因で外部データベースとの通信が不可能になることがあった場合、外部エンジンは通信が再確立されるまでクエリの処理を開始できません。

• 制御された方法で変更を行わなければならない環境 (つまりステージング環境と本番環境) では、この機能を有効にすることはお勧めしません。代わりに Solution Manager を使用して、変更を開発環境からステージングおよび本番環境に昇格することをお勧めします。

• Virtual DataPort が開始され、カタログの構成が変更されたことが検出された場合 (管理者がカタログを保存するためにデータベースを変更したなど)、ファイル <DENODO_HOME>/conf/vdp/VDBConfiguration.properties が <DENODO_HOME>/setup/vdp/templates/conf/VDBConfiguration.template に置き換えられます。このファイルは、Virtual DataPort が再起動するたびにではなく、この構成の変更後に Virtual DataPort が開始されたときにのみ置き換えられます。

• 外部データベースを使用するようにカタログを構成する場合、このデータベースに接続するために必要な JDBC ドライバーを除き、メタデータは転送されません。このドライバーが Denodo に含まれて いない 場合、[Metadata database configuration] ダイアログで [OK] をクリックすると、Virtual DataPort では以下を実行します。

  • ドライバーがすでに新しいデータベースに保存されている場合、ドライバーは現在のデータベース (ローカルの Derby など) に保存されているドライバーと新しいデータベースに保存されているドライバーの MD5 ハッシュ値を計算します。MD5 値が異なる場合、Virtual DataPort は、新しいデータベース内のドライバーを現在のデータベース内のドライバーに置き換えます。

  • 新しいデータベースにドライバーが保存されていない場合は、ドライバーを保存します。

• 外部データベースを使用する場合、構成プロパティを変更するために、ファイル <DENODO_HOME>/conf/vdp/VDBConfiguration.properties を変更 しない でください。代わりにコマンド SET を使用してプロパティを変更してください。これにより、コマンドを実行するサーバーの構成プロパティが変更され、同じデータベースを共有する他のサーバーに変更が伝播されます。

• Denodo サーバーのクラスタが存在する状況で、アプリケーションが ENTER SINGLE USER MODE コマンドを実行すると、このコマンドを受信した Denodo サーバーだけがシングルユーザーモードに切り替わります。それ以外のサーバーはそのまま稼働を続けます。この動作は、Virtual DataPort が外部データベースにメタデータを保存しているかどうかに関係なく発生します。

• 外部データベースを使用する場合、Denodo Platform に組み込んだ Apache Derby データベースを、キャッシュデータベースとして使用することはできません。

外部データベースにメタデータを保存するように Virtual DataPort を構成する方法¶

ここでは、外部データベースを使用するように Virtual DataPort のカタログを構成する方法について説明します。

構成を変更する前に、以下について検討してください。

• Virtual DataPort はデータベース間で (組み込みの Apache Derby からも) メタデータを転送しません。したがって、このプロセスを実行するときは、構成も含め、メタデータを再作成する必要があります。

• SSL を再度有効にする必要があります。

• データベースの管理者は、以下の権限を持つ、この外部データベースのユーザーアカウントを作成する必要があります。

  • CREATE/DROP/ALTER TABLE、およびそれらのテーブルの INDEXES を作成する権限

  • 自身のテーブルに対する INSERT/DELETE/UPDATE 権限

  • LOCK TABLE (DB2 および Oracle の場合のみ)

  • CREATE/DROP SEQUENCE (Oracle の場合のみ)

  • CREATE/DROP/REPLACE TRIGGER (Oracle の場合のみ)

その後、以下の手順に従って実施してください。

1. メタデータを保存する外部データベースにカタログ/スキーマを作成します。

2. すでにオブジェクト (ユーザー、データソース、ビューなど) を作成している場合は、すべてのメタデータをエクスポートします。つまり [File] メニュー > [Export] をクリックします。このダイアログで [Replace existing elements] を選択し、このオプションの下のすべてのチェックボックスをチェックします。

3. [Administration] メニュー > [Metadata database configuration] をクリックします。

外部データベースの構成¶

4. [Database adapter] で、使用するデータベースを選択します。[Driver class] は、デフォルト値が適切です。

   [Driver class] が空の場合、ドライバーが Virtual DataPort に含まれておらず、このサーバーにアップロードされていないことが原因です。ドライバーをこのサーバーにアップロードするには、このウィンドウを閉じて、以下の手順に従います。

   1. [File] メニュー > [Extension management] をクリックします。

   2. このダイアログで、[Libraries]、[Import] の順にクリックします。

   3. 新しいダイアログの [Resource type] で、[jdbc] を選択します。

   4. [Version] で、アップロードするドライバーを選択します。たとえば、IBM DB2 11 のドライバーをアップロードする場合は [db2-11] を選択します。

   5. [Add] をクリックして、ファイルを 1 つまたは複数選択します。複数のファイルを選択するには、Ctrl キーを押しながら各ファイルを選択します。

   6. [OK] をクリックして、ファイルを Virtual DataPort にアップロードします。

   7. [Metadata database configuration] ダイアログに戻ります。

5. [Database URI]、[Login]、[Password] を入力します。

6. [Specify custom catalog and schema] を選択します。

7. 重要: [Test configuration] をクリックして、接続の詳細、ユーザーの名前とパスワードが正しいこと、このアカウントがこのデータベースにテーブルを作成する権限を持っていることを確認します。

8. [OK] をクリックして保存します。

   [OK] をクリックするとすぐに、Virtual DataPort は、カタログを保存する外部データベースにテーブルを作成しますが、再起動されるまで、これらのテーブルを使用しません。

   テーブルがすでに存在している場合、テーブルは再作成 されません 。これは外部データベースを使用するように複数の Virtual DataPort を構成する場合は、この変更を加える最初のサーバーのみがそのテーブルを作成する必要があるからです。

9. Virtual DataPort を再起動します。

   この時点で、Virtual DataPort は新しいデータベースからのすべてのメタデータの読み取りを開始します。

10. デフォルトのユーザーアカウントを使用して Virtual DataPort にログインします。つまりユーザー名は admin 、パスワードは admin です。これは、カタログのデータベースを切り替えたときに、メタデータは新しいデータベースに転送されず、ユーザーが作成されないためです。

11. 手順 2 でメタデータをエクスポートした場合、VQL ファイルをインポートします。

12. これまでにユーザー「admin」を削除したことがある場合は、「admin」も削除します。ユーザー「admin」を削除したかどうかを確認するには、VQL ファイルに「CREATE OR REPLACE USER admin」ステートメントがあるかどうかを確認します。

13. サーバーで TLS を有効にした場合は、プロセスを繰り返します。つまり、スクリプト <DENODO_HOME>/bin/denodo_tls_configurator を実行します。詳細については、『インストールガイド』の「 Denodo SSL/TLS Configurator Script 」のセクションを参照してください。

14. 同じデータベースを共有する Virtual DataPort サーバーのクラスタを構築する場合は、次の手順に沿って操作します。

    1. 最初のインストールの場合、[Administration] メニュー > [Metadata database configuration] をクリックします。

    2. このダイアログで、[Export settings] をクリックして、「metadata_database_configuration.properties」と入力します。これにより、このダイアログの設定が入ったファイルが生成されます。

    3. クラスタを構成するすべてのコンピュータに、このファイルをコピーします。

    4. これらのコンピュータのすべてで、Virtual DataPort サーバーを停止します。

    5. クラスタの各コンピュータで、コマンドラインを開いて、次のコマンドを実行します。

       Linux の場合¶

       cd <DENODO_HOME>
       ./bin/regenerateMetadata.sh "metadata_database_configuration.properties"
       

       Windows の場合¶

       cd <DENODO_HOME>
       .\bin\regenerateMetadata.bat "metadata_database_configuration.properties"
       

regenerateMetadata -f <input-file> [--externalDriver <path-to-external-driver>] [-reset] [-y]

regenerateMetadata --adapter <adapter-name>
                   --version <adapter-version>
                   --driver <driver-classname>
                   [--driverProperties <driver-properties>]
                   --classPath <driver-classpath>
                   [--externalDriver <path-to-external-driver>]
                   --databaseUri <uri>
                   --user <user>
                   --password <password>
                   [--catalog <catalog>]
                   [--schema <schema>]
                   [--initialSize <pool-initial-size>]
                   [--maxActive <pool-max-active>]
                   [--testConnections]
                   [--pingQuery <pool-validation-query>]
                   [--reset]
                   [--yes]

regenerateMetadata --file configuration-file.properties

regenerateMetadata --file configuration-file.properties --reset

regenerateMetadata --adapter postgresql
                   --version 12
                   --classPath "postgresql-12"
                   --databaseUri "jdbc:postgresql://psql-db:5432/vdpcatalog"
                   --driver "org.postgresql.Driver"
                   --user "denodo_user"
                   --password "encrypted:passwordEncrypted"
                   --schema "denodo_metadata"
                   --testConnections
                   --pingQuery "SELECT 1"
                   --driverProperties "{\"prop1\":\"value1\", \"prop2\":\"value2\"}"

regenerateMetadata --adapter mysql
                   --version 5
                   --classPath "mysql-5"
                   --externalDriver "/my-drivers/mysql5"
                   --databaseUri "jdbc:mysql://mysql-db:3306/vdpcatalog"
                   --driver "com.mysql.jdbc.Driver"
                   --user "denodo_user"
                   --password "encrypted:passwordEncrypted"
                   --schema "denodo_metadata"
                   --testConnections
                   --pingQuery "SELECT 1"
                   --driverProperties "{\"prop1\":\"value1\", \"prop2\":\"value2\"}"

regenerateMetadata --password "encrypted:aqlgsesdkloqwepiouimzzkd=="