このページでは、AlloyDB Omni バージョン 15.5.4 のドキュメントについて説明します。
最新の AlloyDB Omni ドキュメントをご覧ください。

このページは Cloud Translation API によって翻訳されました。

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

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

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

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

AlloyDB Omni には、alloydbadmin という名前のスーパーユーザーロールと、alloydbmetadata という名前の非スーパーユーザーロールが含まれています。
デフォルトの postgres ユーザーにはスーパーユーザーのロールがあります。
他の事前定義されたユーザーロールには権限がありません。将来の使用のために予約されています。

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

postgres ユーザーロールを使用してデータベースを定義またはインポートします。新規インストールでは、このロールにはスーパーユーザー権限があり、パスワードは必要ありません。
postgres ユーザーロールを使用して、アプリケーションのテーブルへの適切なアクセス権を持つ新しいユーザーロールを作成します。
これらの新しい限定アクセスロールを使用してデータベースに接続するようにアプリケーションを構成します。

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

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

AlloyDB Omni をモニタリングする

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

Kubernetes で実行される AlloyDB Omni には、Prometheus エンドポイントとして使用できる一連の基本指標もあります。使用可能な指標のリストについては、AlloyDB Omni の指標をご覧ください。

単一サーバー

デフォルトでは、AlloyDB Omni ログを取得するには、次のコマンドを実行します。

 docker logs CONTAINER_NAME

CONTAINER_NAME は、AlloyDB Omni コンテナの名前に置き換えます。

AlloyDB Omni のロギング動作を構成するには、AlloyDB Omni のインストールをカスタマイズするをご覧ください。

Kubernetes

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

postgresql.audit ファイルと postgresql.log ファイルは、データベース 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 は、データベースクラスタの名前に置き換えます。これは、作成時に宣言したデータベースクラスタ名と同じです。
データベース Pod でルートとしてシェルを実行します。
```
kubectl exec ${DB_POD} -it -- /bin/bash
```
/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 はデータベースクラスタと同じ名前空間に次のモニタリングサービスを作成します。

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 です。

ローカル環境からモニタリングサービスへのポート転送を設定します。
```
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
```
上記のコマンドが実行されている間、指定したポートの 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 サービスをモニタリングして収集します。

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.4 以降からアップグレードするには:

新しいイメージバージョンを使用して AlloyDB Omni を再起動します。
データディレクトリは、以前のバージョンの AlloyDB Omni で使用されているパスと同じになるように指定してください。

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

単一サーバー

AlloyDB Omni をアンインストールするには、次のコマンドを使用して AlloyDB Omni コンテナを停止して削除します。

 docker container stop CONTAINER_NAME
 docker container rm CONTAINER_NAME

CONTAINER_NAME は、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 オペレーターをアンインストールする手順は次のとおりです。

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

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

AlloyDB Omni Kubernetes オペレーターがすべてのデータベースクラスタを削除するまで待ちます。次のコマンドを使用して、データベースリソースが残っているかどうかを確認します。
```
kubectl get dbclusters.alloydbomni.dbadmin.goog --all-namespaces
```

AlloyDB Omni Kubernetes オペレーターによって作成された他のリソースを削除します。

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

AlloyDB Omni Kubernetes オペレーターをアンインストールします。
```
helm uninstall alloydbomni-operator --namespace alloydb-omni-system
```

AlloyDB Omni Kubernetes オペレーターに関連する 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 オペレーターは、新しい仕様をデータベース Pod にすぐに適用します。

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

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

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

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

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

AlloyDB Omni をモニタリングする

単一サーバー

Kubernetes

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

モニタリング サービスを一覧表示する

v1.0

バージョン 1.0 未満

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

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

v1.0

バージョン 1.0 未満

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

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

単一サーバー

Kubernetes

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

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

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

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

モニタリングサービスを一覧表示する

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

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