mz-health-check

Materialize 開発者分析

MCP 開発者エンドポイントを通じて Materialize 環境を分析し、健全性ステータス、パフォーマンスの調査結果、最適化の推奨事項を含む構造化レポートを作成します。Materialize v26.24 以降を前提としています。

開発者エンドポイントでは、読み取り専用ツールを 2 つ利用できます。

• query_system_catalog — システムカタログテーブル（mz_*、pg_catalog、information_schema）に限定された SELECT／SHOW／EXPLAIN を実行します。クラスター引数は受け取りません。渡しても拒否されず、黙って無視されます。auto_route_catalog_queries が有効な間（デフォルト）は、カタログの読み取りはカタログサーバークラスター（mz_catalog_server）に自動ルーティングされます。ルーターがそこで処理できないクエリ（特に、すべての mz_introspection リレーション）は、セッションのデフォルトクラスター（ロールの cluster デフォルトが設定されていればその値、そうでなければシステムのデフォルトである quickstart。オペレーターが変更している場合を除く）で実行されます。ほとんどのカタログ参照にはこちらを使用してください。
• query（Materialize v26.30 で追加）— 必須の cluster 引数で指定したクラスター上で、ロールがアクセスできるあらゆるオブジェクトに対して SELECT／SHOW／EXPLAIN を実行します（v26.33 以降は、任意の cluster_replica も指定できます）。EXPLAIN ANALYZE（MV／インデックスのクラスター上で実行する必要があります）と、ユーザーデータを直接読み取る場合に必須です。オペレーターが enable_mcp_developer_query_tool を無効にしている場合、表示されないことがあります。

MCP クライアントを materialize-developer に接続する

ユーザーが MCP クライアント（Claude Code、Cursor、VS Code、Zed、Continue、Windsurf、Claude Desktop）から materialize-developer サーバーに接続するための設定、接続、またはセットアップ方法を尋ねている場合（接続で使用するユーザーやロールの指定方法、または ID の切り替え方法を含む）は、mcp-client-connect.md を参照してください。Emulator、Materialize Cloud、セルフマネージドデプロイメントに対応し、クライアントごとのコード例、認証パターン、検証手順を説明しています。

この SKILL.md の以降の部分では、接続した後に環境を分析する方法を説明します。

テーブルと列の確認

列名を推測してはいけません。 システムカタログのリレーションには、テーブル、ビュー、マテリアライズドビュー、ソースが混在しているため、単一の SHOW TABLES や SHOW VIEWS ですべてを一覧表示することはできません。SHOW OBJECTS FROM <schema> を使用してください。mz_internal のオントロジービューはカタログについて説明するものです。これらを使用して、正しいテーブル、列、結合経路、ID 型を確認してください。

テーブル	説明
mz_internal.mz_ontology_entity_types	存在するカタログエンティティと、それらが対応する mz_* テーブル。
mz_internal.mz_ontology_link_types	エンティティ間の関係（外部キー、メトリクスなど）。
mz_internal.mz_ontology_properties	各エンティティの列名、型、説明。
mz_internal.mz_ontology_semantic_types	型付き ID ドメイン（CatalogItemId、ReplicaId など）。

クエリの例：

-- Find the right table for an entity
SELECT name, relation, description
FROM mz_internal.mz_ontology_entity_types
WHERE name LIKE '%source%'

-- Find join paths between entities
SELECT name, source_entity, target_entity, properties, description
FROM mz_internal.mz_ontology_link_types
WHERE source_entity = 'source' OR target_entity = 'source'

-- Find columns for a table
SELECT column_name, semantic_type, description
FROM mz_internal.mz_ontology_properties
WHERE entity_type = 'source_status'

クエリを実行する前に、SHOW COLUMNS FROM <schema>.<table> で列名を確認してください。

重要なルール

サーバー自身の initialize 指示には、カタログに関する注意事項が記載されています。たとえば、last_status_change_at などの列名、mz_cluster_replica_utilization のレプリカとクラスター間の JOIN、オントロジービュー、そして v26.40 以降の mz_introspection のルーティングと ID 型です。ほとんどのクライアントはこれらを転送します。転送されない場合は、代わりに SHOW COLUMNS を使用してください。

mz_introspection リレーションには query ツールが必要です

mz_dataflow_arrangement_sizes を含むすべての mz_introspection リレーションはクラスターのスコープに属します。また、query_system_catalog ではクラスターを指定できないため、このツールを使った読み取りはセッションのデフォルトクラスターで実行されます。そのクラスターにレプリカがちょうど 1 つあれば、その数値が返されるか、エラーなしで空の結果が返されます。レプリカが複数ある場合、読み取りは log source reads must target a replica というエラーで失敗し、レプリカがない場合は has no replicas available to service request というエラーで失敗します。cluster 引数を指定して query から読み取り、レプリカが複数あるクラスターでは cluster_replica（v26.33 以降）も指定してください（課金対象外のレプリカも数に含まれます）。これが最初のエラーに対する指定方法です。2 つ目のエラーを解決する方法はありません。 v26.40 より前のサーバーでは、initialize の指示で mz_dataflow_arrangement_sizes をクエリしないよう案内されます。このルールは query ツールより前のものなので、ここではこの案内が優先されます。クエリ、カタログへの結合経路、および注意事項については、references/queries.md の「Arrangement Sizes」を参照してください。query ツールがない場合は、以下の「Memory and Resource Consumption」に記載されているリレーションを使用してください。

ワークフローの概要

1. 接続 — MCP Developer ツールが利用可能であることを確認します
2. 検出 — オントロジーとカタログクエリを使って、デプロイ済みのすべてのオブジェクトを一覧化します
3. 分析 — パフォーマンス指標（鮮度、ハイドレーション、メモリ、使用率）を評価します
4. レポート — 調査結果と推奨事項をまとめた構造化 Markdown レポートを作成します

ステップ 1：MCP 接続を確認する

query_system_catalog ツールにアクセスできることを確認します。簡単なテストを実行します。

query_system_catalog: SELECT mz_version() FROM mz_catalog.mz_databases LIMIT 1

query_system_catalog はシステムカタログテーブルを参照しない SELECT を拒否するため、単独の SELECT mz_version() は Query must reference at least one system catalog table というエラーになります。このエラーは接続に問題があるように見えます。

クライアントが公開しているツールに query ツールが含まれているか確認します。このツールがあれば、名前付きクラスター上で EXPLAIN ANALYZE やユーザーオブジェクトに対するクエリも実行できます。ツールがない場合（オペレーターによって無効にされている場合、または v26.30 より前のビルドの場合）は、query_system_catalog で実行可能なすべての処理を行ってください。

query_system_catalog が失敗した場合は、次の点を確認してください。

• MCP サーバーがクライアントの MCP 設定に登録されていること（ファイルとキーはクライアントによって異なります。mcp-client-connect.md を参照してください）
• 環境で enable_mcp_developer フィーチャーフラグが有効になっていること
• 認証情報が有効であること

クエリの実行

どちらのツールも、呼び出しごとに読み取り専用のステートメントを1つだけ受け付けます。SET は使用できず、末尾のセミコロンも付けないでください（1つなら許容されますが、2つのステートメントは拒否されます）。

結果は、列名のない行の配列として返されます。すべての AS エイリアスは破棄されるため、列は位置で対応付け、SELECT リストは短く保ち、読み取りたい順に並べてください。数値は文字列として、ブール値は JSON の true／false として、NULL は null として返されます。timestamp と timestamptz の値は、ミリ秒単位のエポックからの経過時間を表す文字列（1787687415336.000）として返されるため、読みやすい時刻が必要な場合は text にキャストしてください。オブジェクトがセッションのデータベース（SHOW database）にない場合は、オブジェクト名をデータベース名で修飾してください。そうしないと、ステートメントは unknown schema で失敗します。レスポンスには既定で1 MBの上限があり、リクエストには既定で60秒のタイムアウトが設定されています。どちらもオペレーターが変更でき、上限に達するとエラーになります。LIMIT を指定すると、カタログの列挙が上限内に収まります。また、単一のインデックス付きリレーションを単純に読み取る場合に限り、処理量を減らせます。結合では処理量は減りません。タイムアウトすると呼び出しは解放されますが、クエリが実行されたままになることがあります。そのため、タイムアウトしたステートメントをそのまま再試行しないでください。

query_system_catalog は FROM 句のテーブル参照をたどって許可リストを確認するため、FROM 句がないステートメントはまったく確認されません。SHOW TABLES、SHOW COLUMNS、SHOW CREATE 形式のステートメント、およびオブジェクトレベルの EXPLAIN ANALYZE はここで許可され、ユーザーオブジェクトを指定できます（後者が空の結果を返す理由については、「ワーカーの偏り」を参照してください）。query を利用できない場合の代替手段として使用してください。ユーザーオブジェクトには query を使用します。

システムスキーマを除外するときは、必ず次のものを除外してください：mz_catalog、mz_internal、pg_catalog、information_schema、mz_introspection。SHOW SCHEMAS には、リレーションを含まない mz_catalog_unstable と mz_unsafe も表示されます。

Step 2: 検出 — 環境のインベントリ作成

検出クエリを実行して、デプロイされている内容を把握します。クエリ一式については、references/queries.md を参照してください。検出フェーズでは、次の項目を確認します。

環境の概要

• Materialize のバージョン
• クラスターとレプリカ — 名前、managed、レプリカ数、サイズ。mz_clusters を起点にレプリカを LEFT JOIN してください。そうしないと、レプリカのないクラスターがインベントリから除外されます。管理対象外のクラスターでは、size と replication_factor が NULL になります。課金対象外のサポート用レプリカは mz_internal.mz_internal_cluster_replicas に一覧され、ほかのレプリカと同様に数に含めます。
• 使用中のスキーマ

デプロイ済みオブジェクトのインベントリ

• ソース：タイプ（Kafka、Postgres、MySQL、Webhook など）、クラスターの割り当て、ステータス。mz_sources には、すべてのサブソースと progress コレクションの行も含まれるため、ソース数を報告する前に type NOT IN ('subsource', 'progress') で絞り込んでください。
• マテリアライズドビュー：クラスターの割り当て、インデックス、依存関係
• ビュー：（非マテリアライズド）と使用パターン
• シンク：タイプ、出力先、クラスターの割り当て
• インデックス：対象、クラスターの割り当て
• 接続：設定済みの外部システム接続

オブジェクト定義

references/queries.md を使用して、マテリアライズドビュー、ビュー、インデックス、ソースの SQL 定義を取得します。これは最適化分析に不可欠です。SQL 定義から、どのように処理されているかが分かります。

• 結合パターンと結合順序
• フィルタ述語（またはその欠如。時間フィルタの欠如はよくある問題です）
• 集約方法
• 共有できるロジックをマテリアライズドビューで重複していないか

Step 3: 分析 — パフォーマンスとリソースのメトリクス

最新性（ラグ分析）

オブジェクトごとのラグを確認するには、mz_internal.mz_materialization_lag をクエリします。local_lag 列と global_lag 列は通常の interval なので、そのまま比較や並べ替えができ、 slowest_global_input_id にはオブジェクトを遅延させている入力が示されます。 どちらのラグも実時間ではなく入力のフロンティアを基準に測定されます。そのため、 ソースが一時停止したパイプラインでは、どれだけ古くなってもラグはゼロと表示されます。 そのため、mz_frontiers.write_frontier と now() も比較してください （「Write Frontiers」クエリを参照）。

write_frontier はこのリレーションにはありません。mz_internal.mz_frontiers に mz_timestamp として格納されています。読みやすい時刻にするには timestamptz に、 生の数値にするには text（その後 bigint）にキャストします。直接 bigint に キャストすることはできません。クエリについては references/queries.md を 参照してください。

ハイドレーションの状態

すべてのデータフローがハイドレーション済みかどうかを確認するには、 mz_internal.mz_hydration_statuses をクエリします。初回起動後もハイドレーション されていないオブジェクトがある場合、リソース不足や設定上の問題が考えられます。 レプリカの列は LEFT JOIN してください。ハイドレーション先のレプリカがない場合、 replica_id は NULL になります。内部結合では、そうしたオブジェクトが表示されません。

一時停止中のクラスターによるコンパクションの停滞

レプリカのないユーザークラスター上のマテリアライズドビューは、そのビューが読み取る すべての入力のコンパクションを停滞させるため、それらのストレージは増え続けます。 Materialize はこの問題を通知しません。健全性レビューのたびに確認し、該当するものが あればエグゼクティブサマリーに記載してください。references/queries.md の 「Materialized Views on Clusters with No Replicas」クエリを実行してください。 修正するには、クラスターにレプリカを追加して入力をすぐに解放するか、不要であれば ビューを削除します。マネージドクラスターでは ALTER CLUSTER <name> SET (REPLICATION FACTOR = 1) を、アンマネージドクラスターでは CREATE CLUSTER REPLICA <name>.<replica> (SIZE = '<size>') を実行します。レプリカのないクラスター上のインデックスと、 SCHEDULE = ON REFRESH のクラスターは、入力を停滞させません。

メモリとリソースの消費

• mz_internal.mz_cluster_replica_utilization で、レプリカプロセスごとのメモリ／CPU 使用率を確認します
• mz_internal.mz_cluster_replica_metrics で、生のメモリメトリクスを確認します。これも（レプリカ、プロセス）ごとに 1 行です
• mz_internal.mz_index_advice で、最適化できる MV／インデックスを特定します

ワーカーの偏り（ワーカー間の CPU 不均衡）

WITH SKEW を使うと、特定のワーカーが不釣り合いに多くの CPU／メモリ処理を行っている オペレーターを見つけられます。

これらは query ツールで実行してください。query_system_catalog は使わないでください。 EXPLAIN ANALYZE は cluster 引数で指定したクラスター上で実行されます。 オブジェクトレベルのコマンドでは、MV／インデックスが存在するクラスターを指定する 必要があります。誤ったクラスターを指定しても、確実にエラーになるとは限りません。 別の単一レプリカクラスター上で実行した場合や、デフォルトクラスターにレプリカが 1 つある状態で query_system_catalog を使った場合、オブジェクトレベルのコマンドは 空の結果を返し、「偏りなし」と見えてしまいます。レプリカが複数ある場合は log source reads must target a replica で読み取りが失敗し、レプリカがない場合は has no replicas available to service request で失敗します。query を使わないと、 このセクションの内容は実行できません。

クラスター単位（調査対象のクラスター上で実行）：

EXPLAIN ANALYZE CLUSTER CPU WITH SKEW

オブジェクト単位（MV とそのインデックスの両方で実行）：

EXPLAIN ANALYZE CPU WITH SKEW FOR MATERIALIZED VIEW <schema>.<mv_name>

EXPLAIN ANALYZE CPU WITH SKEW FOR INDEX <schema>.<index_name>

偏りがある場合は、偏りのあるオペレーター（多くの場合、TopK／window／agg／join／distinct） を特定し、定義（SHOW CREATE ...）を調べて、具体的な SQL の変更を提案してください （ヒントの削除や調整、キー／パーティショニングの再構成、または MV の書き換え）。

インデックスのアドバイス

Materialize に組み込まれたアドバイザー、mz_internal.mz_index_advice をクエリします。 出力されるヒントは次の 6 種類のみです。keep、drop unless queried directly、 convert to a view、convert to a view with an index、convert to materialized view、 add index。一部に絞り込むと実際の推奨が黙って除外されます。 それぞれの意味については references/queries.md を参照してください。

コスト分析（任意）

references/queries.md のコスト分析クエリを使用します（レプリカごとの料金）。

推奨事項を記載する際は、必ずクレジットへの影響を数値で示してください（クレジットは Cloud の課金単位です。セルフマネージド環境では、同梱されているサイズには Cloud の数値が設定され、オペレーターが定義したサイズにはオペレーターが設定した値が使われます。デフォルトは 0 です。そのため、せいぜい相対的な重みとして示してください）。

オブジェクトの依存関係

mz_internal.mz_object_dependencies をクエリして、依存関係グラフを把握します。

ステップ 4：レポート — 分析を生成する

references/report-template.md に従って、エグゼクティブサマリー、クラスターのトポロジー、デプロイ済みオブジェクト、パフォーマンス分析（鮮度、ハイドレーション、利用率、ワーカーの偏り、ソースとシンクの健全性）、コスト分析、インデックスに関する助言、SQL レベルの分析、具体的な SQL を含む番号付きの推奨事項を盛り込んだ、構造化された Markdown レポートを作成します。

クラスターのトポロジーの表は、references/queries.md の Cluster Topology クエリと、そこにある Current Compute Cost per Cluster のクレジット列をもとに作成します。

推奨事項の記述

必ず具体的な SQL コマンドを記載してください。 例：

良い例：

推奨事項： my_schema.unused_mv を非マテリアライズ化して、メモリを節約します。

SHOW CREATE MATERIALIZED VIEW my_schema.unused_mv
DROP MATERIALIZED VIEW my_schema.unused_mv
CREATE VIEW my_schema.unused_mv AS <definition>

悪い例：

推奨事項： my_schema.unused_mv の非マテリアライズ化を検討してください。

トラブルシューティング手順書

問題を解決する具体的な SQL コマンドで必ず締めくくってください。 また、ユーザーの許可なしに実行してはいけません。スケールアップやレプリカの追加には費用がかかり、オブジェクトの削除や変更によって状態が失われるためです。以下の修正はすべて DDL であり、どちらのツールも受け付けないため、コマンドをユーザーに提示してください。

「マテリアライズドビューが古いのはなぜですか？」

診断手順：

1. まず、MV のクラスターにレプリカがあるか確認します。mz_clusters と mz_cluster_replicas の LEFT JOIN（「Clusters and Replicas」クエリ）を使い、replication_factor は使わないでください。replication_factor は管理対象外クラスターでは NULL になり、課金対象外のレプリカも認識できません。レプリカのないクラスターは何も実行せず、以下の手順も適切に機能しません。
2. mz_internal.mz_hydration_statuses を確認します。MV はハイドレーション済みですか。また、そのクラスター上のほかのすべてのオブジェクトはどうですか（「Non-Hydrated Objects」クエリを使い、対象のクラスターに絞り込みます）。
3. mz_internal.mz_cluster_replica_status_history を確認し、理由が oom-killed の最近の offline イベントを探します。これは、cgroup OOM キラー、ヒープリミッター、lgalloc のスピルディスク容量不足のいずれも対象です（「Replica Restarts」クエリを使います。エミュレーターは理由を記録しないため、その場合は offline の件数で判断します）。OOM ループは、現在のステータスが online で、利用率のサンプル値も控えめに見えることがよくあります。OOM の大半はハイドレーション中に発生するため、ステップ 2 ですべてがハイドレーション済みと示され、プロセスごとの最新の履歴行が online であれば、ループは終了しています。ハイドレーション完了後も繰り返し強制終了される場合は、定常状態でのループです。クラスターのサイズを変更するか、クラスター上の負荷を減らすことでのみ解消できます。
4. mz_internal.mz_cluster_replica_utilization を確認します。memory_percent が 100 に近い場合、RAM がいっぱいで、それ以上の増加分はスワップがある環境ではスワップに回り、ハイドレーションの遅延やラグとして現れます。memory_percent が変わらないまま heap_percent（上限に対する RAM とスワップの合計）が上昇している場合は、スワップが使用されています。100 に近づくと、次の急増でレプリカが強制終了されます。いずれの場合も、スケールアップするか、MV を移動するか、クラスターが保持するものを減らしてください（以下の修正方法とステップ 7 を参照）。
5. mz_internal.mz_source_statuses を確認します。上流ソースにエラーはありますか？
6. mz_internal.mz_materialization_lag を確認し、MV のラグを調べます（「鮮度」を参照）。
7. query ツールを利用できる場合は、MV のクラスターで EXPLAIN ANALYZE MEMORY FOR MATERIALIZED VIEW <schema>.<mv> を実行し、演算子ごとのメモリ使用量を確認して、コストの高い形状（大規模なアレンジメント、インデックスのない結合、時間フィルターの欠落）を特定します。

よくある修正方法：

MV のクラスターにレプリカがない場合：

ALTER CLUSTER <cluster_name> SET (REPLICATION FACTOR 1)

-- Unmanaged cluster: add a replica directly
CREATE CLUSTER REPLICA <cluster_name>.r1 (SIZE = '<size>')

クラスターが過負荷の場合（メモリ／CPU の使用率が高い）：

-- Option A: Scale up the cluster (unmanaged: DROP and CREATE its replicas
-- at the bigger size instead)
ALTER CLUSTER <cluster_name> SET (SIZE = '<next_size_up>')

-- Option B: Move the MV to a different cluster
SHOW CREATE MATERIALIZED VIEW <schema>.<mv_name>
DROP MATERIALIZED VIEW <schema>.<mv_name>
CREATE MATERIALIZED VIEW <schema>.<mv_name> IN CLUSTER <new_cluster> AS <definition>

上流ソースが稼働していない場合：

SELECT name, status, error, last_status_change_at
FROM mz_internal.mz_source_statuses
WHERE status != 'running'

running 以外のステータスがすべて障害を示すわけではなく、error を伴うのは stalled のみです。各ステータスの意味については、以下の「ソースは正常に稼働していますか？」を参照してください。まず上流ソースの問題を修正してください。MV の鮮度はソースの健全性に依存します。

「クラスターのメモリが不足するのはなぜですか？」

診断手順：

1. mz_internal.mz_cluster_replica_utilization でメモリ使用率を、mz_cluster_replica_status_history で oom-killed イベントを確認します（「Replica Restarts」）。
2. mz_internal.mz_index_advice で、マテリアライズを解除できる MV を確認します。
3. MV の定義を確認し、時間フィルターが欠落していないか調べます。
4. 冗長なインデックスがないか確認します。
5. query ツールを利用できる場合は、問題が疑われるオブジェクトのクラスターで EXPLAIN ANALYZE MEMORY FOR MATERIALIZED VIEW <schema>.<mv>（または FOR INDEX <name>）を実行し、どの演算子が最も多くのメモリを保持しているか確認します。どのアレンジメントが原因かを直接確認する最も簡単な方法です。

よくある修正方法：

マテリアライズが不要な MV のマテリアライズを解除します：

SELECT o.name, o.type, sc.name AS schema_name, ia.hint, ia.details
FROM mz_internal.mz_index_advice ia
JOIN mz_catalog.mz_objects o ON ia.object_id = o.id
JOIN mz_catalog.mz_schemas sc ON o.schema_id = sc.id
WHERE ia.hint = 'convert to a view'

convert to a view with an index と convert to materialized view も、それぞれ異なる対処方法を必要とするメモリに関する推奨事項です。この対処を行う前に、推奨事項一式（references/queries.md の「Index Advice」クエリ）をすべて確認してください。

-- For each candidate:
SHOW CREATE MATERIALIZED VIEW <schema>.<mv_name>
DROP MATERIALIZED VIEW <schema>.<mv_name>
CREATE VIEW <schema>.<mv_name> AS <definition>

未使用のインデックスを削除します：

SELECT o.name, o.type, sc.name AS schema_name, ia.hint, ia.details
FROM mz_internal.mz_index_advice ia
JOIN mz_catalog.mz_objects o ON ia.object_id = o.id
JOIN mz_catalog.mz_schemas sc ON o.schema_id = sc.id
WHERE ia.hint = 'drop unless queried directly'

-- Verify with the user before dropping
DROP INDEX <schema>.<index_name>

クラスターをスケールアップします（管理対象外の場合は、代わりにレプリカを DROP して、より大きなサイズで CREATE します）：

ALTER CLUSTER <cluster_name> SET (SIZE = '<next_size_up>')

「ソースは正常に稼働していますか？／ソースのスナップショット作成は完了していますか？」

診断手順：

1. ソースのエラーを確認するには、mz_internal.mz_source_statuses を確認します
2. 取り込みの進行状況を確認するには、mz_internal.mz_source_statistics を確認します
3. エンドツーエンドの遅延を確認するには、mz_internal.mz_materialization_lag を確認します

よくある解決方法：

ソースが稼働していない場合：

SELECT name, status, error
FROM mz_internal.mz_source_statuses
WHERE status != 'running'

ステータスは created（ステータスがまだ記録されていない）、starting、 running、paused、stalled、dropped のいずれかです。ドキュメントには failed も記載されていますが、コードがこれを生成することはありません。stalled にのみ error が含まれます。Webhook と progress の行は常に running と表示されます。created と starting は一時的な 通常の状態です。paused はソースのクラスターにレプリカがないことを意味し、いくら 待っても解決しません：

-- paused: give the source's cluster a replica
ALTER CLUSTER <cluster_name> SET (REPLICATION FACTOR 1)
-- unmanaged cluster: CREATE CLUSTER REPLICA <cluster_name>.r1 (SIZE = '<size>')

-- stalled/failed on bad credentials:
ALTER SECRET <secret_name> AS '<new_value>'

snapshot_committed が false の場合、ソースは初期スナップショットをまだ読み込み中です。 大規模なソースでは正常な状態です。完了するまで待ちます。また、ソースまたはレプリカの 起動後、約 2 分間はカウンターがゼロのまま false と表示されることがあります。 mz_source_statistics の行がまったくないソースは一度も実行されていないため、待つのではなく、 ステータスとクラスターにレプリカがあるかどうかを確認します。paused のソースには古い行が 残るため、まず status を確認してください。

「環境の健全性はどうなっていますか？」

次の確認を順番に実行します：

1. mz_internal.mz_cluster_replica_statuses — ユーザークラスターのすべてのレプリカが 準備完了になっており、mz_cluster_replica_status_history に最近の oom-killed がないか？
2. 一時停止中のクラスター — レプリカのないユーザークラスター上にマテリアライズドビューがあるか？ その場合、入力のコンパクションが妨げられます（一時停止中のクラスターによるコンパクションの妨げ）。
3. mz_internal.mz_source_statuses — すべてのソースが稼働しているか？
4. mz_internal.mz_sink_statuses — すべてのシンクが稼働しているか？
5. mz_internal.mz_cluster_replica_utilization — リソースに負荷がかかっているか？

「コストを節約するために最適化できることは何ですか？」

1. 最適化候補を確認するには、mz_internal.mz_index_advice を確認します
2. クラスターの使用率を確認します — クラスターが過剰にプロビジョニングされていないか？
3. mz_catalog.mz_cluster_replica_sizes からクレジットレートを確認します

メモ

• アクセスは RBAC によって制御されるため、認証情報でアクセスできる データ だけが表示されます。 カタログには同じ制限が適用されません。オブジェクトへの権限がないロールでも、オブジェクトの インベントリ全体、すべてのビューと MV の definition、および mz_index_advice の全データを 読み取れます。RBAC が有効な場合、自動ルーティングされない query とすべての読み取りには、 実行先クラスターに対する USAGE も必要です（mz_catalog_server はこれを PUBLIC に付与します）。 RBAC チェックが有効かどうかは、デプロイ環境とその設定によって異なります。 SHOW enable_rbac_checks と SHOW enable_session_rbac_checks で確認できます （いずれかが on なら有効です）。
• 最新性の数値は特定時点のスナップショットです。遅延が安定しているか増加しているか確認するには、再実行してください。