AlloyDB Omni の管理とモニタリング

ドキュメントのバージョンを選択してください。 15.5.4

• 最新（16.8.0）
• 16.8.0
• 16.3.0
• 15.12.0
• 15.7.1
• 15.7.0
• 15.5.5
• 15.5.4
• 15.5.2

このページでは、AlloyDB Omni ユーザーロールの管理、AlloyDB Omni サーバーのアクティビティのモニタリング、AlloyDB Omni インストールの更新または削除の方法について説明します。

ユーザーロールを管理する

AlloyDB Omni は、AlloyDB に含まれる事前定義された PostgreSQL ユーザーロールの同じセットを使用しますが、次の点が異なります。

• AlloyDB Omni には、alloydbadmin という名前のスーパーユーザー ロールと、alloydbmetadata という名前の非スーパーユーザー ロールが含まれています。

• デフォルトの postgres ユーザーにはスーパーユーザー ロールがあります。

• 他の事前定義されたユーザーロールには権限がありません。将来の使用のために予約されています。

AlloyDB と同様に、データベースを設定する際は次の手順に沿うことをおすすめします。

1. postgres ユーザーロールを使用してデータベースを定義またはインポートします。新規インストールでは、このロールにはスーパーユーザー権限があり、パスワードは必要ありません。

2. 再度、postgres ユーザーロールを使用して、アプリケーションのテーブルへの適切なアクセス権を持つ新しいユーザーロールを作成します。

3. これらの新しいアクセス制限付きロールを使用して、データベースに接続するようにアプリケーションを構成します。

新しいユーザーロールは、必要な数だけ作成して定義できます。AlloyDB Omni に付属するユーザーロールは変更または削除しないでください。

詳細については、AlloyDB ユーザーロールを管理するをご覧ください。

AlloyDB Omni をモニタリングする

AlloyDB Omni のインストールをモニタリングするには、ログファイルを読み取り、分析を行います。

使用可能な指標のリストについては、AlloyDB Omni の指標をご覧ください。

Kubernetes で実行される AlloyDB Omni には、Prometheus エンドポイントとして使用できる一連の基本指標もあります。

Kubernetes

データベース クラスタのログファイルを探す

postgresql.audit ファイルと postgresql.log ファイルは、データベース Pod のファイル システムにあります。これらのファイルにアクセスする手順は次のとおりです。

1. データベース Pod の名前を含む環境変数を定義します。

   export DB_POD=`kubectl get pod -l alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME,alloydbomni.internal.dbadmin.goog/task-type=database -o jsonpath='{.items[0].metadata.name}'`

   DB_CLUSTER_NAME は、実際のデータベースの名前に置き換えます。これは、作成時に宣言したデータベース クラスタ名と同じです。

2. データベース Pod でルートとしてシェルを実行します。

   kubectl exec ${DB_POD} -it -- /bin/bash

3. /obs/diagnostic/ ディレクトリでログファイルを探します。

   • /obs/diagnostic/postgresql.audit
   • /obs/diagnostic/postgresql.log

モニタリング サービスの一覧を取得する

v1.0

データベース クラスタを作成すると、AlloyDB Omni は同じ Namespace 内のデータベース クラスタのインスタンス CR ごとに次のモニタリング サービスを作成します。

al-INSTANCE_NAME-monitoring-system

モニタリング サービスの一覧を取得するには、次のコマンドを実行します。

kubectl get svc -n NAMESPACE | grep monitoring

NAMESPACE は、クラスタが属する Namespace に置き換えます。

次のレスポンスの例は、al-1060-dbc-monitoring-system、al-3de6-dbc-monitoring-system、al-4bc0-dbc-monitoring-system サービスを示しています。各サービスは 1 つのインスタンスに対応します。

al-1060-dbc-monitoring-system   ClusterIP   10.0.15.227   <none>        9187/TCP   7d20h
al-3de6-dbc-monitoring-system   ClusterIP   10.0.5.205    <none>        9187/TCP   7d19h
al-4bc0-dbc-monitoring-system   ClusterIP   10.0.15.92    <none>        9187/TCP   7d19h

バージョン 1.0 未満

データベース クラスタを作成すると、AlloyDB Omni はデータベース クラスタと同じ Namespace に次のモニタリング サービスを作成します。

• DB_CLUSTER-monitoring-db

• DB_CLUSTER-monitoring-system

モニタリング サービスの一覧を取得するには、次のコマンドを実行します。

kubectl get svc -n NAMESPACE | grep monitoring

NAMESPACE は、クラスタが属する Namespace に置き換えます。

次のレスポンス例は、al-2953-dbcluster-foo7-monitoring-system サービスと al-2953-dbcluster-foo7-monitoring-db サービスを示しています。

al-2953-dbcluster-foo7-monitoring-db           ClusterIP   10.36.3.243    <none>        9187/TCP   44m
al-2953-dbcluster-foo7-monitoring-system       ClusterIP   10.36.7.72     <none>        9187/TCP   44m

コマンドラインから Prometheus 指標を表示する

すべてのモニタリング サービスで、ポート 9187 の名前は metricsalloydbomni です。

1. ローカル環境からモニタリング サービスへのポート転送を設定します。

   kubectl port-forward service/MONITORING_SERVICE -n NAMESPACE MONITORING_METRICS_PORT:metricsalloydbomni
   

   次のように置き換えます。

   • MONITORING_SERVICE: 転送するモニタリング サービスの名前。例: al-1060-dbc-monitoring-system

   • NAMESPACE: クラスタが属する Namespace。

   • MONITORING_METRICS_PORT: ローカルで使用可能な TCP ポート。

   次のレスポンスは、サービスが転送されていることを示しています。

   Forwarding from 127.0.0.1:9187 -> 9187
   Forwarding from [::1]:9187 -> 9187
   

2. 上記のコマンドが実行されている間、指定したポートの HTTP 経由でモニタリング指標にアクセスできます。たとえば、curl を使用すると、すべての指標を書式なしテキストとして表示できます。

   curl http://localhost:MONITORING_METRICS_PORT/metrics
   

Prometheus API を使用して指標を表示する

alloydbomni.internal.dbadmin.goog/task-type ラベルキーと metricsalloydbomni ポートは、AlloyDB Omni のすべてのモニタリング サービスでデフォルトとして使用できます。これらを 1 つの serviceMonitor カスタム リソースとともに使用すると、データベース クラスタ内のすべての Namespace のすべてのサービスを選択できます。

Prometheus API の使用方法については、Prometheus Operator のドキュメントをご覧ください。

alloydbomni.internal.dbadmin.gdc.goog/task-type ラベルキーと metricsalloydbomni ポートを含む serviceMonitor カスタム リソースの spec フィールドの例を次に示します。serviceMonitor カスタム リソースは、すべての Namespace 内のすべての Kubernetes Service をモニタリングして収集します。

ServiceMonitor の完全な定義については、ServiceMonitor カスタム リソース定義をご覧ください。

v1.0

    spec:
      selector:
        matchLabels:
          alloydbomni.internal.dbadmin.goog/task-type: monitoring
      namespaceSelector:
        any: true
      endpoints:
        - port: metricsalloydbomni

バージョン 1.0 未満

    spec:
      selector:
        matchExpressions:
        - key: alloydbomni.internal.dbadmin.gdc.goog/task-type
          operator: Exists
          values: []
      namespaceSelector:
        any: true
      endpoints:
      - port: metricsalloydbomni

AlloyDB Omni をアップグレードする

AlloyDB Omni 15.5.2 以前から 15.5.4 にアップグレードするには、以前のバージョンの AlloyDB Omni から最新バージョンに移行するの手順に沿って操作します。

注: バージョン 15.5.3 は AlloyDB Omni のプレビュー バージョンです。

15.5.4 以降からアップグレードするには:

1. 新しいイメージ バージョンを使用して AlloyDB Omni を再起動します。

2. データ ディレクトリは、以前のバージョンの AlloyDB Omni で使用されているパスと同じになるように指定してください。

AlloyDB Omni をアンインストールする

Kubernetes

データベース クラスタを削除する

データベース クラスタを削除するには、マニフェストで isDeleted を true に設定します。この操作を行うには、次のコマンドを実行します。

注意: 次のコマンドを実行すると、名前付きデータベース クラスタに保存されているすべてのデータが完全に消去されます。

kubectl patch dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME -p '{"spec":{"isDeleted":true}}' --type=merge

DB_CLUSTER_NAME は、実際のデータベースの名前に置き換えます。これは、作成時に宣言したデータベース クラスタ名と同じです。

AlloyDB Omni Operator をアンインストールする

注意: この操作を行うと、Kubernetes クラスタからすべての AlloyDB Omni データベースが完全に削除されます。

Kubernetes クラスタから AlloyDB Omni Kubernetes Operator をアンインストールする手順は次のとおりです。

1. すべてのデータベース クラスタを削除します。

   for ns in $(kubectl get dbclusters.alloydbomni.dbadmin.goog --all-namespaces -o=jsonpath='{range .items[*]}{.metadata.namespace}{"\n"}{end}'); do
   for cr in $(kubectl get dbclusters.alloydbomni.dbadmin.goog -n $ns -o=jsonpath='{range .items[*]}{.metadata.name}{"\n"}{end}'); do
   kubectl patch dbclusters.alloydbomni.dbadmin.goog $cr -n $ns --type=merge -p '{"spec":{"isDeleted":true}}'
   done
   done

2. AlloyDB Omni Kubernetes Operator がすべてのデータベース クラスタを削除するまで待機します。データベース リソースが残っているかどうかを確認するには、次のコマンドを使用します。

   kubectl get dbclusters.alloydbomni.dbadmin.goog --all-namespaces

3. AlloyDB Omni Kubernetes Operator が作成した他のリソースを削除します。

   kubectl delete failovers.alloydbomni.dbadmin.goog --all --all-namespaces
   kubectl delete restores.alloydbomni.dbadmin.goog --all --all-namespaces
   kubectl delete switchovers.alloydbomni.dbadmin.goog --all --all-namespaces

4. AlloyDB Omni Kubernetes Operator をアンインストールします。

   helm uninstall alloydbomni-operator --namespace alloydb-omni-system

5. AlloyDB Omni Kubernetes Operator に関連する Secret、カスタム リソースの説明、Namespace をクリーンアップします。

   kubectl delete certificate -n alloydb-omni-system --all
   kubectl get secrets --all-namespaces -o custom-columns=NAMESPACE:.metadata.namespace,NAME:.metadata.name,ANNOTATION:.metadata.annotations.cert-manager\.io/issuer-name | grep -E 'alloydbomni|dbs-al' | awk '{print $1 " " $2}' | xargs -n 2 kubectl delete secret -n
   kubectl delete crd -l alloydb-omni=true
   kubectl delete ns alloydb-omni-system

Kubernetes ベースのデータベース クラスタのサイズを変更する

Kubernetes ベースのデータベース クラスタの CPU、メモリ、ストレージのサイズを変更するには、Pod を定義するマニフェストの resources フィールドを更新します。AlloyDB Omni Operator は、新しい仕様をデータベース Pod にすぐに適用します。

AlloyDB Omni Operator マニフェストの構文の詳細については、データベース クラスタを作成するをご覧ください。

実行中のデータベース クラスタのリソースの変更には、次の制限が適用されます。

• ディスクのサイズを増やすことができるのは、指定された storageClass がボリュームの拡張をサポートしている場合のみです。
• ディスクサイズの縮小はできません。