ApsaraDB for ClickHouse:FAQ

安定性を確保するために、ApsaraDB for ClickHouse ではオープンソースの ClickHouse の複数のバグが修正されています。 ApsaraDB for ClickHouse は、ユーザーにバインドされているリソースキューに優先順位を割り当てるためのリソースキュー機能を提供します。

この問題を解決するには、次の操作を実行します。

• ネットワーク接続が確立されているかどうかを確認します。ping コマンドを実行して、ネットワーク接続の状態を確認できます。telnet コマンドを実行して、ApsaraDB for ClickHouse クラスターのポート 3306 とポート 8123 が有効になっているかどうかを確認することもできます。

• 接続先の ApsaraDB for ClickHouse クラスターにホワイトリストが構成されているかどうかを確認します。 ApsaraDB for ClickHouse クラスターのホワイトリストを構成する方法の詳細については、ホワイトリストを構成するを参照してください。

• クライアントの実際の IP アドレスが使用されているかどうかを確認します。企業の内部ネットワークに接続されているマシンの IP アドレスは頻繁に変更されます。そのため、取得したクライアント IP アドレスは、クライアントの実際の IP アドレスではない場合があります。 WhatsMyIP などの IP アドレス確認ツールを使用して、クライアントの実際の IP アドレスを取得できます。詳細については、WhatsMyIP を参照してください。

V20.3 または V20.8 の ApsaraDB for ClickHouse クラスターに外部テーブルを作成すると、システムは ApsaraDB for ClickHouse クラスターと外部プラットフォーム間のネットワーク接続を自動的に検証します。外部テーブルが作成されると、ネットワーク接続が確立されます。次のいずれかの原因により、外部テーブルの作成に失敗する可能性があります。

• 接続先のテーブルが、ApsaraDB for ClickHouse クラスターと同じ VPC にないクラスターにデプロイされています。この場合、ネットワーク接続の確立に失敗します。

• 接続先の MySQL インスタンスにホワイトリストが構成されています。 ApsaraDB for ClickHouse クラスターが接続されている VPC の CIDR ブロックがホワイトリストに含まれていません。この場合、CIDR ブロックをホワイトリストに追加します。

この問題については、以下のセクションで一般的な原因と解決策を示します。

• 原因 1：VPC 設定またはインターネットアクセス設定が不適切です。アプリケーションとクラスターが同じ VPC にデプロイされている場合は、内部ネットワーク経由でアプリケーションをクラスターに接続できます。アプリケーションとクラスターが異なる VPC にデプロイされている場合は、クラスターのパブリックエンドポイントを申請します。

  解決策：アプリケーションとクラスターが異なる VPC にデプロイされている場合は、クラスターのパブリックエンドポイントを申請します。詳細については、パブリックエンドポイントの申請とリリースを参照してください。

• 原因 2：アプリケーションの IP アドレスがクラスターのホワイトリストに追加されていません。

  解決策：アプリケーションの IP アドレスをクラスターのホワイトリストに追加します。詳細については、ホワイトリストの構成を参照してください。

• 原因 3：クラスターが実行されている Elastic Compute Service (ECS) インスタンスのセキュリティグループがアクセストラフィックを拒否しています。

  解決策：クラスターが実行されている Elastic Compute Service (ECS) インスタンスのセキュリティグループを有効にして、アクセストラフィックを許可します。詳細については、セキュリティグループの操作を参照してください。

• 原因 4：企業がネットワークファイアウォールを使用しています。

  解決策：ファイアウォールルールを変更します。

• 原因 5：接続文字列のアカウントパスワードに、次の特殊文字のいずれかが含まれています：!@#$%^&*()_+=。これらの特殊文字は接続中に認識できません。その結果、アプリケーションは ApsaraDB for ClickHouse クラスターに接続できません。

  解決策：次のエスケープルールを使用して、接続文字列の特殊文字をエスケープします。

  !  : %21
  @ : %40
  # : %23
  $ : %24
  % : %25
  ^ : %5e
  & : %26
  * : %2a
  ( : %28
  ) : %29
  _ : %5f
  + : %2b
  = : %3d

  たとえば、パスワードが ab@#c の場合、パスワードのエスケープされた文字は、接続文字列では ab%40%23c になります。

• 原因 6：ApsaraDB for ClickHouse クラスターは、デフォルトで Classic Load Balancer (CLB) インスタンスに接続されています。 CLB インスタンスは、従量課金制で課金されます。 Alibaba Cloud アカウントに延滞料金がある場合、ApsaraDB for ClickHouse クラスターにアクセスできない可能性があります。

  解決策：Alibaba Cloud アカウントに延滞料金があるかどうかを確認します。延滞料金がある場合は、できるだけ早く延滞料金をお支払いください。

この問題を解決するには、次の操作を実行します。

• OSS オブジェクトを複数のオブジェクトに分割します。次に、これらのオブジェクトから ApsaraDB for ClickHouse クラスターの外部テーブルにデータをインポートします。

• ApsaraDB for ClickHouse クラスターのメモリ容量をスケールアップします。詳細については、ApsaraDB for ClickHouse コミュニティ互換版クラスターの構成を変更するを参照してください。

この問題については、以下のセクションで一般的な原因と解決策を示します。

• 原因 1：指定されたパラメータ値がシナリオに適していません。 ApsaraDB for ClickHouse では、複数のバッチでデータを書き込むことをお勧めします。各バッチに大量のデータが含まれており、少数の同時データ書き込みタスクが同時に実行されていることを確認してください。ほとんどの場合、データのバッチには数万行、あるいは数十万行が含まれる可能性があります。これは、単一行のサイズによって異なります。ほとんどの場合、行の推定サイズは 100 バイトです。行サイズを見積もり、行サイズに基づいて行数を計算する必要があります。

  解決策：同時書き込み要求の最大数を 10 に設定します。パラメータの設定を変更して、再試行できます。

• 原因 2：DataWorks で作成された排他的リソースグループでは、ECS インスタンスの仕様が低くなっています。排他的リソースグループでは、CPU コアまたはメモリの仕様が低いと、要求の同時実行性またはアウトバウンド帯域幅に制限が課される可能性があります。大きなバッチサイズを指定したがメモリ容量が不足している場合、DataWorks Java プロセスでガベージコレクションが発生する可能性があります。

  解決策：DataWorks の出力ログに基づいて ECS インスタンスの仕様を確認します。

• 原因 3：データソースで読み取り操作を実行するのに長い時間がかかります。

  解決策：DataWorks の出力ログで totalWaitReaderTime と totalWaitWriterTime を検索します。 totalWaitReaderTime の値が totalWaitWriterTime の値よりもはるかに大きい場合、書き込み操作に必要な時間よりも読み取り操作に必要な時間が長くなります。

• 原因 4：パブリックエンドポイントが使用されています。パブリックエンドポイントは限られた帯域幅を提供し、高パフォーマンスのデータのインポートまたはエクスポートを保証できません。

  解決策：パブリックエンドポイントを VPC エンドポイントに置き換えます。

• 原因 5：データソースにダーティデータが含まれています。通常の場合、データはバッチで書き込まれます。データソースからダーティデータが読み取られると、書き込まれているデータのバッチが失敗し、データの行が毎回書き込まれます。さらに、多数のデータパートが生成されます。これにより、書き込み操作が遅くなります。

  次の方法を使用して、ダーティデータが書き込まれているかどうかを確認できます。

  • データをクエリし、返されたエラーメッセージを確認します。メッセージに "Cannot parse" が含まれている場合は、ダーティデータが書き込まれています。

    次のサンプルコードを実行できます。

    SELECT written_rows, written_bytes, query_duration_ms, event_time, exception
    FROM system.query_log
    WHERE event_time BETWEEN '2021-11-22 22:00:00' AND '2021-11-22 23:00:00' AND lowerUTF8(query) LIKE '%insert into <table_name>%' and type != 'QueryStart' and exception_code != 0
    ORDER BY event_time DESC LIMIT 30;

  • データのバッチが書き込まれた後に行数を確認します。行数が 1 の場合は、ダーティデータが書き込まれています。

    次のサンプルコードを実行できます。

    SELECT written_rows, written_bytes, query_duration_ms, event_time
    FROM system.query_log
    WHERE event_time BETWEEN '2021-11-22 22:00:00' AND '2021-11-22 23:00:00' AND lowerUTF8(query) LIKE '%insert into <table_name>%' and type != 'QueryStart'
    ORDER BY event_time DESC LIMIT 30;

  解決策：データソースのダーティデータを削除または変更します。

テーブル間で行数が一致しない原因を特定するには、次の手順を実行します。

1. query_log という名前のシステムテーブルに基づいて、データ同期中にエラーが報告されているかどうかを確認します。エラーが報告された場合、データ損失が発生する可能性があります。

2. 使用しているテーブルエンジンで重複を削除できるかどうかを確認します。 ReplacingMergeTree を使用している場合、ApsaraDB for ClickHouse クラスターの外部テーブルの行数は、Hive インスタンスのテーブルよりも少ない場合があります。

3. Hive インスタンスに保存されているテーブルの行数が正しいかどうかを確認します。

テーブル間で行数が一致しない原因を特定するには、次の手順を実行します。

1. query_log という名前のシステムテーブルに基づいて、データ同期中にエラーが報告されているかどうかを確認します。エラーが報告された場合、データ損失が発生する可能性があります。

2. 使用しているテーブルエンジンで重複を削除できるかどうかを確認します。 ReplacingMergeTree を使用している場合、ApsaraDB for ClickHouse クラスターの外部テーブルの行数は、Kafka インスタンスのテーブルよりも少ない場合があります。

3. 外部テーブルに kafka_skip_broken_messages パラメータが設定されているかどうかを確認します。このパラメータが設定されている場合、ApsaraDB for ClickHouse は解析に失敗した Kafka メッセージをスキップする可能性があります。その結果、ApsaraDB for ClickHouse クラスターの外部テーブルの行数は、Kafka インスタンスのテーブルよりも少ない場合があります。

この問題を解決するには、次の操作を実行します。

• clickhouse-client を使用して、ファイルをエクスポートすることによりデータを移行します。詳細については、セルフマネージド ClickHouse クラスターから ApsaraDB for ClickHouse クラスターにデータを移行するを参照してください。

• 次の文を実行して、remote 関数を使用してデータを移行します。

  INSERT INTO <宛先テーブル> SELECT * FROM remote('<接続文字列>', '<データベース>', '<テーブル>', '<ユーザー名>', '<パスワード>');

解決策：次の手順を実行して、MySQL データの別の同期を実行します。

1. データ同期が停止したテーブルを削除します。

   DROP TABLE <テーブル名> ON cluster default;

   説明

   table_name パラメータは、データ同期が停止したテーブルの名前を指定します。データ同期が停止したテーブルが分散テーブルの場合、ローカルテーブルと分散テーブルを削除する必要があります。

2. データ同期を再起動します。

   ALTER database <データベース名> ON cluster default MODIFY SETTING skip_unsupported_tables = 1;

   説明

   <database_name> パラメータは、ApsaraDB for ClickHouse で MaterializeMySQL エンジンを使用するデータベースの名前を指定します。

この問題については、以下のセクションで一般的な原因と解決策を示します。

• 原因 1：メモリ使用量が多い。

  解決策：max_insert_threads パラメータの設定を変更して、メモリ使用量を削減します。

• 原因 2：INSERT INTO SELECT 文を実行して、ある ApsaraDB for ClickHouse クラスターから別のクラスターにデータをインポートしました。

  解決策：ファイルを宛先クラスターにインポートすることにより、データを移行します。詳細については、セルフマネージド ClickHouse クラスターから ApsaraDB for ClickHouse クラスターにデータを移行するを参照してください。

ApsaraDB for ClickHouse サーバーは、各クエリ スレッドにメモリ トラッカーを提供します。各クエリのすべてのスレッドのメモリ トラッカーは、メモリ使用量を「クエリ用のメモリ トラッカー」という名前のメモリ トラッカーに報告します。次に、「クエリ用のメモリ トラッカー」は、取得した情報を上位層のメモリ トラッカー（「合計用のメモリ トラッカー」という名前）に報告します。問題を解決するには、シナリオに基づいて次の操作を実行します。

• "Memory limit (for query)" メッセージが返された場合、クラスターメモリの 70% 以上がクエリによって消費されています。メモリ仕様をスケールアップすることをお勧めします。

• "Memory limit (for total)" メッセージが返された場合、クラスターメモリの 90% 以上が消費されています。同時クエリの数を減らすことをお勧めします。この操作を実行した後も問題が解決しない場合は、バックグラウンドでの非同期タスクによって大量のメモリが消費されている可能性があります。ほとんどの場合、データの書き込み後に同じプライマリキー値を含むレコードを重複排除すると、大量のメモリが消費されます。メモリ仕様をスケールアップすることをお勧めします。

デフォルトでは、ApsaraDB for ClickHouse サーバーでの同時クエリの最大数は 100 です。ApsaraDB for ClickHouse コンソールで値を変更できます。同時クエリの最大数を変更するには、次の手順を実行します。

1. ApsaraDB for ClickHouse コンソール にログインします。

2. [クラスター] ページで、[コミュニティ互換版のクラスター] タブをクリックし、管理するクラスターの ID をクリックします。

3. 左側のナビゲーションウィンドウで、[パラメータ管理] をクリックします。

4. [設定] タブで、max_concurrent_queries パラメータを見つけ、[パラメータ値] 列の編集アイコンをクリックします。

5. 表示されるダイアログボックスで、値を入力し、[OK] をクリックします。

6. [パラメータを送信] をクリックします。

7. [OK] をクリックします。

この問題を解決するには、次の操作を実行します。

• ApsaraDB for ClickHouse クラスターがマルチノードクラスターかどうかを確認します。 ApsaraDB for ClickHouse クラスターに複数のノードがある場合は、ノードに分散テーブルを作成する必要があります。次に、分散テーブルにデータを書き込み、分散テーブルからデータをクエリできます。このようにして、分散テーブルからデータをクエリする文を実行するたびに、同じクエリ結果が返されます。分散テーブルを使用しない場合、文を実行するたびに異なるシャードのデータがクエリされる可能性があります。その結果、同じ文に対して異なるクエリ結果が返されます。分散テーブルを作成する方法の詳細については、テーブルを作成するを参照してください。

• ApsaraDB for ClickHouse クラスターがダブルレプリカ版かどうかを確認します。ダブルレプリカ版の ApsaraDB for ClickHouse クラスターを使用する場合は、ノードにレプリケートされたテーブルを作成します。これにより、データがノードのレプリカ間で一貫していることが保証されます。レプリケートされたテーブルを作成しない場合、クエリ結果は、クエリされたレプリカに基づいて異なる場合があります。レプリケートされたテーブルを作成する方法の詳細については、テーブルエンジンを参照してください。

この問題については、以下のセクションで一般的な原因と解決策を示します。

• 原因 1：無効な DDL 文を使用して、ApsaraDB for ClickHouse クラスターにテーブルを作成しています。分散 ApsaraDB for ClickHouse クラスターにテーブルを作成するには、CREATE TABLE 文に ON CLUSTER default 句を含める必要があります。CREATE TABLE 文のみを実行すると、クライアントが接続されているサーバーにのみテーブルが作成されます。この場合、このテーブルからのみデータをクエリできます。クライアントを別のサーバーに接続すると、テーブルが見つかりません。

  解決策：

  1. テーブルを作成するときは、CREATE TABLE <テーブル名> ON CLUSTER default 文を実行します。ON CLUSTER default 句により、文はデフォルトクラスターのすべてのノードで実行されます。次のサンプル文は例を示しています。

     CREATE TABLE test ON cluster default (a UInt64) Engine = MergeTree() ORDER BY tuple();

  2. test という名前のテーブルに分散テーブルエンジンを作成します。次の文を実行して、test_dis という名前の分散テーブルを作成できます。

     CREATE TABLE test_dis ON cluster default AS test Engine = Distributed(default, default, test, cityHash64(a));

• 原因 2：ReplicatedMergeTree テーブルが正しく構成されていません。 ReplicatedMergeTree テーブルエンジンは、MergeTree テーブルエンジンに基づいて開発されており、レプリケートされたテーブル間でデータを同期するために使用できます。シングルレプリカ版の ApsaraDB for ClickHouse クラスターでは、MergeTree テーブルエンジンのみを作成できます。ダブルレプリカ版の ApsaraDB for ClickHouse クラスターでは、ReplicatedMergeTree テーブルエンジンのみを作成できます。

  解決策：ダブルレプリカ版の ApsaraDB for ClickHouse クラスターにテーブルを作成するときは、ReplicatedMergeTree('/clickhouse/tables/{database}/{table}/{shard}', '{replica}') または ReplicatedMergeTree() を使用して、ReplicatedMergeTree テーブルエンジンを構成します。ReplicatedMergeTree('/clickhouse/tables/{database}/{table}/{shard}', '{replica}') は固定構成であり、変更する必要はありません。

OPTIMIZE 文を実行する前に、次の条件が満たされていることを確認してください。これにより、同じプライマリキー値を含むレコードを重複排除するために使用されるロジックが有効であることが保証されます。

• データを格納するテーブルを定義するときは、PARTITION BY 句で指定されたフィールドを order by 句で指定されたフィールドに含める必要があります。異なるパーティションの 2 つのレコードに同じプライマリキー値が含まれている場合、レコードは重複排除されません。

• 分散テーブルを定義するときは、ハッシュするフィールドを order by 句で指定されたフィールドに含める必要があります。異なるノードの 2 つのレコードに同じプライマリキー値が含まれている場合、レコードは重複排除されません。

次の表に、一般的な OPTIMIZE 文を示します。

この問題については、以下のセクションで一般的な原因と解決策を示します。

• 原因 1：同じプライマリキー値を含むレコードが重複排除されているときに、指定された TTL 値に基づくエビクションが発生します。データパート内の同じプライマリキー値を含むレコードが長時間重複排除されない場合、期限切れのレコードを削除できません。

  解決策:

  • FINAL 句または PARTITION 句を使用して OPTIMIZE TABLE 文を実行することにより、同じプライマリキー値を含むレコードを重複排除するタスクをトリガーできます。

  • テーブルを作成するときに、merge_with_ttl_timeout パラメーターと ttl_only_drop_parts パラメーターを設定して、期限切れのデータを含むデータパーツ内の同じプライマリキー値を含むレコードの重複排除の頻度を高めることができます。

• 原因 2：テーブルの TTL が指定または変更されています。その結果、既存のデータパートの TTL 情報が不完全または不正確になり、期限切れのデータが削除されない場合があります。

  解決策：

  • ALTER TABLE materialize ttl 文を実行して、TTL を再構成できます。

  • OPTIMIZE TABLE test PARTITION tuple(); 文を実行して、TTL を更新できます。

ローカルテーブルの場合、DDL 文を実行して列を作成、削除、または変更できます。分散テーブルの場合、次のいずれかの方法を使用して、さまざまなシナリオで列を作成、削除、または変更できます。

• 分散テーブルにデータが書き込まれていない場合は、ローカルテーブルで列を作成、削除、または変更してから、分散テーブルで列を作成、削除、または変更できます。

• 分散テーブルにデータが書き込まれている場合は、次のいずれかの手順を使用してさまざまな操作を実行できます。

  タイプ	操作
  NULL 値が許可された列を作成します。	ローカルテーブルで列を作成または変更します。 分散テーブルで列を作成または変更します。
  データ型の変換がサポートされている場合は、列のデータ型を変更します。
  NULL 値が許可された列を削除します。	分散テーブルで列を作成または変更します。 ローカルテーブルで列を作成または変更します。
  NULL 値が許可されない列を作成します。	データの書き込みを停止します。 SYSTEM FLUSH DISTRIBUTED 文を実行します。 ローカルテーブルで列を作成または変更します。 分散テーブルで列を作成または変更します。 分散テーブルへのデータの書き込みを再開します。
  NULL 値が許可されない列を削除します。
  列の名前を変更します。

この問題を解決するには、次の操作を実行します。

• すべての DDL 文が実行されるまで待ちます。

• ApsaraDB for ClickHouse コンソールでの DDL 文の実行を停止します。

この問題については、以下のセクションで一般的な原因と解決策を示します。

• 原因 1：ApsaraDB for ClickHouse クライアントは文の構文を解析します。ただし、SET GLOBAL ON CLUSTER default 文は ApsaraDB for ClickHouse サーバーでのみ有効です。クライアントバージョンがサーバーバージョンと一致しない場合、SET GLOBAL ON CLUSTER default 文を実行すると、クライアントは構文エラーを報告します。

  解決策：

  • クライアントで文の構文を解析しないツールを使用します。たとえば、JDBC ドライバーで DataGrip または DBeaver を使用できます。

  • JDBC プログラムを作成して、SET GLOBAL ON CLUSTER default 文を実行することもできます。

• 原因 2：SET GLOBAL ON CLUSTER default 文に、単一引用符 (') で囲まれていない文字列値を指定しました。

  解決策：SET GLOBAL ON CLUSTER default 文の文字列値を単一引用符 (') で囲みます。

各テーブルで使用されているディスク容量を確認するには、次のサンプル文を実行できます。

SELECT table, formatReadableSize(sum(bytes)) as size, min(min_date) as min_date, max(max_date) as max_date FROM system.parts WHERE active GROUP BY table; 

コールドデータのサイズをクエリするには、次のサンプル文を実行できます。

SELECT * FROM system.disks;

コールドストレージにあるデータを確認するには、次のサンプル文を実行できます。

SELECT * FROM system.parts WHERE disk_name = 'cold_disk';

パーティション内のデータをコールドストレージにダンプするには、次のサンプル文を実行できます。

ALTER TABLE table_name MOVE PARTITION partition_expr TO DISK 'cold_disk';

この問題は、次のいずれかの原因で発生します。

• データをクエリすると、OOM エラーが報告されます。

• クラスタの構成が変更されています。これにより、クラスタが再起動します。

• クラスタの仕様がスケールアップまたはスケールダウンされています。これにより、クラスタが再起動します。

次の表に、一般的なシステムテーブルを示します。

users.xml ファイルには、ユーザー設定に関する情報が含まれています。このファイルでユーザーパラメータの設定を変更できます。ユーザーパラメータの設定を変更するには、次のサンプル文を実行します。

SET global ON cluster default ${key}=${value};

SETTINGS 文を使用して、リソースクォータを変更できます。リソースクォータを変更するには、次のサンプル文を実行します。

settings max_memory_usage = XXX;

複数ノードのデュアルレプリカ版クラスターまたはシングルレプリカ版クラスターを使用している場合、大量の書き込み操作が実行されるノードの CPU 使用率とメモリ使用量は、他のノードよりも高くなります。 データが他のノードに同期されると、CPU 使用率とメモリ使用量は、すべてのノードで徐々にバランスの取れた状態になります。

• 問題の説明:

  ユーザーは、エラーのトラブルシューティングや潜在的な問題の特定のために、システムの詳細ログを表示したいと考えています。

• 解決策:

  1. クラスタの text_log.level パラメーターの値を表示します。値を表示するには、次の操作を実行します。

     1. text_log.level パラメーターが空のままの場合、text_log は無効になっています。 text_log を有効にするには、text_log.level パラメーターを設定する必要があります。

     2. text_log.level パラメーターが指定されている場合は、text_log レベルがビジネス要件を満たしているかどうかを確認します。 text_log レベルがビジネス要件を満たしていない場合は、text_log.level パラメーターを変更します。

     text_log.level パラメーターの表示および変更方法の詳細については、「config.xml ファイルのパラメーターを設定する」をご参照ください。

  2. ターゲットデータベースにログオンします。詳細については、「データベース接続」をご参照ください。

  3. 次の文を実行して、分析結果を表示します。

     SELECT * FROM system.text_log;

宛先クラスターとデータソースが同じリージョンにデプロイされ、同じ VPC を使用している場合は、宛先クラスターの IP アドレスがデータソースのホワイトリストに追加されているかどうか、およびデータソースの IP アドレスが宛先クラスターのホワイトリストに追加されているかどうかを確認します。 IP アドレスがホワイトリストに追加されていない場合は、ホワイトリストを設定します。

• ApsaraDB for ClickHouse クラスターのホワイトリストを設定する方法の詳細については、「ホワイトリストを設定する」をご参照ください。

• データソースのホワイトリストを設定する方法の詳細については、対応するサービスドキュメントをご参照ください。

それ以外の場合は、適切なネットワークソリューションを選択してネットワーク接続の問題を解決し、ホワイトリストに IP アドレスを追加します。

ApsaraDB for ClickHouse は、Community 互換エディション クラスターから Enterprise Edition クラスターへのデータ移行をサポートしています。

リモート関数またはデータのインポートとエクスポートを使用して、2 つのエディション間でデータを移行できます。詳細については、「セルフマネージド ClickHouse クラスターから ApsaraDB for ClickHouse クラスターにデータを移行する」をご参照ください。

デフォルトでは、Enterprise Edition V24.5 以降を実行する新しい ApsaraDB for ClickHouse クラスターのクエリエンジンは、新しいアナライザを使用します。新しいアナライザはクエリのパフォーマンスを向上させましたが、以前のバージョンの Enterprise Edition で使用されていた特定の SQL 文と互換性がない場合があります。これにより、解析エラーが発生する可能性があります。このエラーが発生した場合は、次の文を実行して、新しいアナライザを古いアナライザにロールバックできます。詳細については、「Analyzer enabled by default」をご参照ください。

SET allow_experimental_analyzer = 0;

ApsaraDB for ClickHouse クラスターのうち、Community 互換 Edition を実行しているクラスターは一時停止できません。 Enterprise Edition クラスターは一時停止できます。 Enterprise Edition クラスターを一時停止するには、[クラスター] ページの [Enterprise Edition クラスター] タブに移動します。[クラスター] ページの左上隅で、クラスターを一時停止するリージョンを選択します。一時停止するクラスターを見つけ、>[アクション] 列で [一時停止] を選択します。