OmniDBは、PostgreSQLテクノロジーとサービスの世界的リーダーである2ndQuadrantによって開発されたオープンソースのグラフィカルデータベース管理ツールです。 OmniDBは、PostgreSQL、MariaDB、MySQL、Oracleなどの主要なデータベースエンジンを管理できるブラウザベースのユニバーサルクライアントツールです。間もなくサポートされるその他のエンジンには、SQLite、Firebird、MS SQL Server、およびIBMDB2が含まれます。
他の優れたデータベースクライアントソフトウェアと同様に、OmniDBもいくつかの優れた機能をユーザーに提供します。これには、データベースパフォーマンス監視ダッシュボードを作成およびカスタマイズする機能が含まれます。この2部構成の記事シリーズでは、OmniDBの組み込みの監視ユニット（ダッシュボード用語では「ウィジェット」と呼ばれる）を使用して、PostgreSQL12レプリケーションクラスターのパフォーマンスヘルスチェックダッシュボードを構築する方法を学習します。
テスト環境
テスト環境は、us-east-1リージョンのAWSVPCで実行されている2ノードのPostgreSQL12クラスターです。 VPCは3つのアベイラビリティーゾーンにまたがり、3つのサブネットを持っています。各サブネットは、個別のアベイラビリティーゾーン（AZ）にあります。プライマリノードとスタンバイノードは、これらのサブネットの2つにあります。ノードは両方ともt2.largeEC2インスタンスタイプであり、オープンソースのPostgreSQL12を実行します。プライマリノードはスタンバイノードにレプリケートされます。
2ndQuadrantのOmniDBデータベース管理ツールの最新バージョンを実行する「監視ノード」もあります。このノードはPostgreSQLクラスターの一部ではありませんが、別のAZのVPCの3番目のサブネットでホストされます。 OmniDBは、マスターノードとスタンバイノードの両方に接続して、それらのパフォーマンスを確認できます。 OmniDBノードはt2.mediumEC2インスタンスになります。
3つのノードすべてでRedHatEnterprise Linux（RHEL）8が実行されます。次の画像は、簡略化されたアーキテクチャを示しています。
テストシナリオ
クラスタとOmniDBを設定したら、両方のPostgreSQLノードをOmniDBに登録します。次に、OmniDBの標準的な監視ユニットのいくつかに精通し、両方のクラスターノードからのパフォーマンスメトリックを表示します。次に、pgbenchを使用してプライマリノードで負荷テストを実行します。理想的には、負荷テストは別のマシンから開始する必要がありますが、この場合はローカルで実行します。次に、OmniDBの監視ダッシュボードが、負荷の変化に応じてさまざまなパフォーマンスカウンターの変化をどのように表示するかを確認します。
環境の設定
ステップ1：PostgreSQL12レプリケーションクラスターのインストール
2ノードのPostgreSQLクラスターを作成するには、以前に公開された2ndQuadrantブログで説明されている手順に従います。読者はこの記事をチェックして、 repmgr と呼ばれる別の2ndQuadrant製品を使用して、監視ノードを備えた3ノードクラスタをインストールした方法を確認できます。 。現在のセットアップでは、repmgrを使用して同じ手順に従って、3ノードクラスターではなく2ノードクラスターを作成しています。また、レプリケーションクラスターには監視ノードがありません。簡単にするために、この記事では詳細なインストールと構成の手順を示していません。
クラスタが設定されたら、プライマリノードからpg_stat_replicationビューにクエリを実行して、クラスタが機能していることを確認できます。
SELECT usename, client_addr, application_name, state, sent_lsn, write_lsn,replay_lsn FROM pg_stat_replication;
ステップ2：OmniDBサーバーのインストールと構成
OmniDBは、URLを使用してアクセスされます。つまり、バックグラウンドで、独自のWebサーバーを実行します。 OmniDBには2つのフレーバーがあります：
- OmniDBアプリケーション ：これは通常、ワークステーションから実行され、通常のデスクトップアプリケーションのように動作します。 OmniDBはランダムポートでWebサーバーを実行し、追加のセットアップは必要ありません。
- OmniDBサーバー ：これは、マルチユーザーモードのネットワークサーバーにOmniDBをインストールするためのものです。サーバーモードでは、URLにアクセスするためのポート番号、URLのSSL暗号化、負荷分散とリバースプロキシ、データベースノードへのSSHパススルーアクセス、アクセス用のユーザーアカウントの作成を指定できます。
テストシナリオでは、OmniDBEC2ノードにOmniDBサーバーをインストールします。まず、OmniDBサイトから最新のパッケージをダウンロードしています：
# wget https://www.omnidb.org/dist/2.17.0/omnidb-server_2.17.0-centos7-amd64.rpm
次に、インストールを開始します。ここでは、rootユーザーとしてOmniDBをインストールしていますが、正しい権限があれば、他のユーザーを使用できます。
# rpm -ivh omnidb-server_2.17.0-centos7-amd64.rpm Verifying... ################################# [100%] Preparing... ################################# [100%] Updating / installing... 1:omnidb-server-2.17.0-0 ################################# [100%]
パッケージがインストールされると、コマンドプロンプトからOmniDBを起動できます：
# omnidb-server
これはサーバーの起動を示しています：
Starting OmniDB websocket... Checking port availability... Starting websocket server at port 25482. Starting OmniDB server... Checking port availability... Starting server OmniDB 2.17.0 at 127.0.0.1:8000. Starting migration of user database from version 0.0.0 to version 2.17.0... OmniDB successfully migrated user database from version 0.0.0 to version 2.17.0 Open OmniDB in your favorite browser Press Ctrl+C to exit
OmniDBがデフォルトのWebサーバーポート8000を選択し、デフォルトのWebSocketサーバーをポート25482で選択していることがわかります。
Ctrl + Cを押してサーバープロセスを停止し、rootユーザーのホームディレクトリを参照します。 .omnidbという名前の隠しフォルダがあることがわかります 。このフォルダの下に、 omnidb-serverというサブディレクトリがあります。 。 omnidb-serverサブディレクトリ内には、いくつかのファイルがあります：
# ls -la ~ … drwxr-xr-x. 3 root root 27 Jun 13 02:49 .omnidb … … # ls -la ~/.omnidb … drwxr-xr-x. 2 root root 106 Jun 13 02:49 omnidb-server # ls -la ~/.omnidb/omnidb-server/ … -rw-r--r--. 1 root root 131072 Jun 13 02:49 db.sqlite3 -rw-r--r--. 1 root root 1209 Jun 13 02:49 omnidb.conf -rw-r--r--. 1 root root 116736 Jun 13 02:49 omnidb.db -rw-r--r--. 1 root root 0 Jun 13 02:49 omnidb.db.bak_2.17.0 -rw-r--r--. 1 root root 579 Jun 13 02:49 omnidb.log
サーバープロセスが開始すると、OmniDBはこれらのファイルを初期化します。 OmniDBメタデータデータベースはomnidb.dbと呼ばれます 。これはSQLiteデータベースであり、データベース接続、OmniDBユーザーなどに関する情報が含まれています。 omnidb.conf ファイルには、OmniDBサーバーの構成オプションが含まれています。このファイルをエディターで開くと、次のようになります。
# OmniDB Server configuration file [webserver] # What address the webserver listens to, 0.0.0.0 listens to all addresses bound to the machine listening_address = 127.0.0.1 # Webserver port, if port is in use another random port will be selected listening_port = 8000 # Websocket port, if port is in use another random port will be selected websocket_port = 25482 # External Websocket port, use this parameter if OmniDB isn't directly visible by the client # external_websocket_port = 25482 # Security parameters # is_ssl = True requires ssl_certificate_file and ssl_key_file parameters # This is highly recommended to protect information is_ssl = False ssl_certificate_file = /path/to/cert_file ssl_key_file = /path/to/key_file # Trusted origins, use this parameter if OmniDB is configured with SSL and is being accessed by another domain csrf_trusted_origins = origin1,origin2,origin3 # Url path to access OmniDB, default is empty path = [queryserver] # Max number of threads that can used by each advanced object search request thread_pool_max_workers = 2 # Number of seconds between each prompt password request. Default: 30 minutes pwd_timeout_total = 1800
OmniDBは2つのサーバープロセスを実行します。 1つはユーザーインターフェイスを表示するWebサーバーで、もう1つはWebSocketサーバーです。 WebSocketサーバーは、クエリ、コンソール、デバッグなど、アプリケーションのいくつかの機能で使用されます。
構成ファイルから、デフォルトでOmniDBサーバーがWebサーバーポート8000でローカルトラフィック（127.0.0.1）を受け入れることがわかります。これをすべてのIPアドレスに変更します。マシンがリバースプロキシの背後にある場合を除き、サーバーへのHTTP接続にSSL暗号化を使用することを強くお勧めします。ただし、この例では、 is_sslを残します テストが完了したらこのマシンを破棄するため、パラメータを「False」に設定します。また、Webサーバーのポートを8080に変更し、WebSocketサーバーのポートをデフォルト値の25482に維持します。
変更が加えられると、構成ファイルは次のようになります。
[webserver] listening_address = 0.0.0.0 listening_port = 8080 websocket_port = 25482 is_ssl = False ssl_certificate_file = /path/to/cert_file ssl_key_file = /path/to/key_file csrf_trusted_origins = origin1,origin2,origin3 path = [queryserver] thread_pool_max_workers = 2 pwd_timeout_total = 1800>
変更を加えて保存したら、 omnidb-config-serverという別のアプリケーションを実行します。 。このツールを使用して、次のような追加の構成を実行できます。
- SQLiteデータベースOmniDBデータベースのバキューム
- 古いデータベースをリセットして新しいデータベースを作成します
- 一時ファイルを削除する
- データベースと構成ファイル用の新しいホームディレクトリを作成します
デフォルトで作成された管理者ユーザーアカウントを使用してOmniDBにログインしますが、ここで別のスーパーユーザーを作成します。これは、OmniDBで個別のDBAアカウントを作成する場合に役立ちます。以下のスニペットはこれを示しています：
# omnidb-config-server --createsuperuser=dba [email protected]$$w0rd123 Creating superuser... Superuser created.
スーパーユーザーを作成したら、omnidb-serverプロセスを再開します。
# omnidb-server Starting OmniDB websocket... Checking port availability... Starting websocket server at port 25482. Starting OmniDB server... Checking port availability... Starting server OmniDB 2.17.0 at 0.0.0.0:8080. User database version 2.17.0 is already matching server version. Open OmniDB in your favorite browser Press Ctrl+C to exit
OmniDBインターフェースにアクセスする前に、ポート8080とポート25482をEC2インスタンスのセキュリティグループに追加します。
ステップ3：OmniDBインターフェイスへのアクセス
パブリックアドレスとOmniDBノードを参照すると、ログイン画面が表示されます。
デフォルトのユーザー名「admin」とそのパスワード「admin」を指定します。これにより、メインのOmniDBインターフェースにログインできます。最初の画面を以下に示します：
次に、画面の右上隅にある[ユーザーの管理]アイコンをクリックします。
そして、管理者ユーザーのデフォルトのパスワードを変更します：
完了したら、「データの保存」ボタンをクリックしてパスワードを更新します。ご覧のとおり、この画面から新しいユーザーを作成することもできます。
画面の左上隅にある[接続]リンクをクリックし、表示されるダイアログボックスから[新しい接続]ボタンをクリックします。
次に、プライマリPostgreSQLノードの接続の詳細を指定し、[データの保存]ボタンをクリックします。
接続が保存されたら、[アクション]列の接続アイコン（緑色のチェックマーク）をクリックします。
これにより、データベース接続を示す新しいタブが開きます。ここに示すように、ここでプライマリPostgreSQLノードに接続しています：
同じプロセスに従って、スタンバイノードを登録します。
ステップ4：サンプルデータベースの復元
現在、プライマリPostgreSQLインスタンスでサンプルデータベースを復元しています。このデータベースは「DVDRental」と呼ばれ、PostgreSQLチュートリアルサイトから無料でダウンロードできます。ダウンロードしたファイルを解凍し、ソースファイルをプライマリノードの/tmpフォルダーの下のサブディレクトリに抽出しました。
[[email protected] dvdrental] # ls -la total 2796 drwxr-xr-x. 2 root root 280 Jun 16 11:32 . drwxrwxrwt. 9 root root 257 Jun 16 11:31 .. -rw-------. 1 postgres postgres 57147 May 12 2019 3055.dat -rw-------. 1 postgres postgres 8004 May 12 2019 3057.dat -rw-------. 1 postgres postgres 483 May 12 2019 3059.dat -rw-------. 1 postgres postgres 333094 May 12 2019 3061.dat -rw-------. 1 postgres postgres 149469 May 12 2019 3062.dat -rw-------. 1 postgres postgres 26321 May 12 2019 3063.dat -rw-------. 1 postgres postgres 46786 May 12 2019 3065.dat -rw-------. 1 postgres postgres 21762 May 12 2019 3067.dat -rw-------. 1 postgres postgres 3596 May 12 2019 3069.dat -rw-------. 1 postgres postgres 140422 May 12 2019 3071.dat -rw-------. 1 postgres postgres 263 May 12 2019 3073.dat -rw-------. 1 postgres postgres 718644 May 12 2019 3075.dat -rw-------. 1 postgres postgres 1214420 May 12 2019 3077.dat -rw-------. 1 postgres postgres 271 May 12 2019 3079.dat -rw-------. 1 postgres postgres 57 May 12 2019 3081.dat -rw-------. 1 postgres postgres 45872 May 12 2019 restore.sql -rw-------. 1 postgres postgres 55111 May 12 2019 toc.dat
次に、プライマリPostgreSQLインスタンス（PG-Node1）で次のシェルコマンドを実行します。これらのコマンドは、restore.sqlファイルにいくつかの変更を加えます。
- 「$$ PATH$$/」の出現箇所をすべて削除します。これにより、スクリプトが同じディレクトリ内のすべてのデータファイルを確実に見つけることができます
- 「English_UnitedStates.1252」のすべての出現箇所を「en_US.UTF-8」に変更します。これにより、スクリプトの実行時にロケールが欠落しているためにエラーが発生することはありません。
- 「DROPDATBASEdvdrental」コマンドを「DROPDATBASE IF EXISTS dvdrental」に変更して、無効なデータベースエラーが表示されないようにします。
# sed -i 's/$$PATH$$\//\/tmp\/dvdrental\//g' /tmp/dvdrental/restore.sql # sed -i 's/English_United States.1252/en_US.UTF-8/g' /tmp/dvdrental/restore.sql # sed -i 's/DROP DATABASE dvdrental;/DROP DATABASE IF EXISTS dvdrental;/g' /tmp/dvdrental/restore.sql
次に、postgresユーザーに切り替えて、シェルプロンプトから次のコマンドを実行します。
$ psql -U postgres -d postgres -f /tmp/dvdrental/restore.sql
これにより、プライマリノードのサンプルデータベースが復元されます。 OmniDBから確認すると、データベースが作成されていることがわかります。
結論
これで、完全に機能するPostgreSQLクラスターとOmniDBインスタンスがAWSで実行されます。 OmniDBは、クラスターの両方のノードに接続できます。また、スタンバイに複製されているプライマリノードのデータベースを復元しました。
これで環境のセットアップは完了です。この記事の第2部では、プライマリインスタンスのパフォーマンス監視ダッシュボードの作成を開始します。