ClickHouse

ClickHouseは、オープンソースのカラム指向データベース管理システムです。大規模なデータセットに対して、効率的にフィルタリング、集計、クエリを実行できます。

GitLabは、ClickHouseをセカンダリデータストアとして使用し、GitLab Duo、SDLCトレンド、およびCI分析といった高度な分析機能を実現しています。ClickHouseでは、GitLabはこれらの機能をサポートするために必要なデータのみが保存されます。

ClickHouseをGitLabに接続するには、ClickHouse Cloudを使用する必要があります。

または、独自のClickHouse環境を使用することもできます。詳細については、GitLab Self-Managed用ClickHouseの推奨事項を参照してください。

ClickHouseで利用可能な分析

ClickHouseを設定すると、次の分析機能を使用できます:

サポートされているClickHouseのバージョン

サポートされているClickHouseのバージョンは、GitLabのバージョンによって異なります:

• GitLab 17.7以降は、ClickHouse 23.xをサポートしています。ClickHouse 24.xまたは25.xのいずれかを使用するには、回避策を使用してください。
• GitLab 18.1以降は、ClickHouse 23.x、24.x、および25.xをサポートしています。
• GitLab 18.8以降は、ClickHouse 23.x、24.x、25.x、およびレプリケートされたデータベースエンジンをサポートしています。
  • 古いクラスターでは、追加の権限（dictGet）が必要になります。スニペットを参照してください。

ClickHouse Cloudは、常に最新の安定したGitLabリリースと互換性があります。

ClickHouseの設定

運用要件に基づいて、デプロイタイプを選択します:

• ClickHouse Cloud（推奨）: 自動アップグレード、バックアップ、およびスケールを備えたフルマネージドサービス。
• GitLab Self-Managed用ClickHouse（BYOC）: インフラストラクチャと設定を完全に制御できます。

ClickHouseインスタンスを設定した後、次を行います:

1. GitLabデータベースとユーザーを作成します。
2. GitLab接続を構成します。
3. 接続を検証します。
4. ClickHouseの移行を実行します。
5. ClickHouse for Analyticsを有効にします。

ClickHouse Cloudの設定

前提条件:

• ClickHouse Cloudアカウントを持っている。
• GitLabインスタンスからClickHouse Cloudへのネットワーク接続が有効である。
• GitLabインスタンスの管理者である。

ClickHouse Cloudを設定するには、以下を実行します:

1. ClickHouse Cloudにサインインします。
2. New Serviceを選択します。
3. サービス階層を選択します:
   • Development: テストおよび開発環境向け。
   • Production: 高可用性を備えた本番環境のワークロード向け。
4. クラウドプロバイダーとリージョンを選択します。最適なパフォーマンスを得るには、GitLabインスタンスに近いリージョンを選択してください。
5. サービス名と設定を設定します。
6. Create Serviceを選択します。
7. プロビジョニングされたら、サービスダッシュボードから接続の詳細をメモしておきます:
   • ホスト
   • ポート（通常、安全な接続の場合は9440）
   • ユーザー名
   • パスワード

ClickHouse Cloudサービスを作成したら、GitLabデータベースとユーザーを作成します。

GitLab Self-Managed用ClickHouse（BYOC）を設定する

前提条件:

• ClickHouseインスタンスがインストールされ、実行されていることを確認する。ClickHouseがインストールされていない場合は、以下を参照してください:
  • ClickHouseの公式インストールガイド。
  • GitLab Self-Managed用ClickHouseに関する推奨事項。
• サポートされているClickHouseのバージョンがある。
• GitLabインスタンスからClickHouseへのネットワーク接続を有効である。
• ClickHouseとGitLabインスタンスの両方の管理者である。

高可用性の設定

マルチノードの高可用性（HA）の設定の場合、GitLabはClickHouseのレプリケートされたテーブルエンジンをサポートします。

前提条件:

• マルチノードを持つClickHouseクラスターがある。最小3つのノードをお勧めします。
• remote_servers設定セクションでクラスターを定義している。
• ClickHouse設定で次のマクロを設定している:
  • cluster
  • shard
  • replica

HA用にデータベースを設定するときは、ON CLUSTER句を使用してステートメントを実行する必要があります。

詳細については、ClickHouseのレプリケートされたデータベースエンジンのドキュメントを参照してください。

ロードバランサーの設定

GitLabアプリケーションは、HTTP / HTTPSインターフェースを介してClickHouseクラスターと通信します。HAデプロイの場合は、HTTPプロキシまたはロードバランサーを使用して、ClickHouseクラスターノード全体にリクエストを分散させます。

推奨されるロードバランサーのオプションは以下のとおりです:

• chproxy - 組み込みのキャッシュとルーティングを備えたClickHouse固有のHTTPプロキシ。
• HAProxy - 汎用TCP / HTTPロードバランサー。
• NGINX - ロードバランシング機能を備えたWebサーバー。
• クラウドプロバイダーロードバランサー（AWS Application Load Balancer、GCP Load Balancer、Azure Load Balancer）。

基本的なchproxy設定例は次のとおりです:

server:
  http:
    listen_addr: ":8080"

clusters:
  - name: "clickhouse_cluster"
    nodes: [
      "http://ch-node1:8123",
      "http://ch-node2:8123",
      "http://ch-node3:8123"
    ]

users:
  - name: "gitlab"
    password: "your_secure_password"
    to_cluster: "clickhouse_cluster"
    to_user: "gitlab"

ロードバランサーを使用する場合は、個々のClickHouseノードの代わりに、ロードバランサーURLに接続するようにGitLabを設定します。

詳細については、chproxyのドキュメントを参照してください。

GitLab Self-Managedインスタンス用ClickHouseを設定したら、GitLabデータベースとユーザーを作成します。

ClickHouseインストールの検証

データベースを設定する前に、ClickHouseがインストールされ、アクセス可能であることを確認します:

1. ClickHouseが実行されていることを確認します:

   clickhouse-client --query "SELECT version()"

   ClickHouseが実行されている場合は、バージョン番号が表示されます（たとえば、24.3.1.12）。

2. 認証情報で接続できることを確認します:

   clickhouse-client --host your-clickhouse-host --port 9440 --secure --user default --password 'your-password'

   TLSをまだ設定していない場合は、初期テスト用に--secureフラグなしでポート9000を使用します。

データベースとユーザーを作成

必要なユーザーとデータベースオブジェクトを作成するには以下の手順に従います:

1. 安全なパスワードを生成して保存します。
2. サインインします:
   • ClickHouse Cloudの場合は、ClickHouse SQLコンソールにサインインします。
   • GitLab Self-Managed用ClickHouseの場合は、clickhouse-clientにサインインします。
3. 次のコマンドを実行し、PASSWORD_HEREを生成されたパスワードに置き換えます。

CREATE DATABASE gitlab_clickhouse_main_production;
CREATE USER gitlab IDENTIFIED WITH sha256_password BY 'PASSWORD_HERE';
CREATE ROLE gitlab_app;
GRANT SELECT, INSERT, ALTER, CREATE, UPDATE, DROP, TRUNCATE, OPTIMIZE, dictGet ON gitlab_clickhouse_main_production.* TO gitlab_app;
GRANT SELECT ON information_schema.* TO gitlab_app;
GRANT gitlab_app TO gitlab;

CREATE DATABASE gitlab_clickhouse_main_production ON CLUSTER CLUSTER_NAME_HERE ENGINE = Replicated('/clickhouse/databases/{cluster}/gitlab_clickhouse_main_production', '{shard}', '{replica}');
CREATE USER gitlab IDENTIFIED WITH sha256_password BY 'PASSWORD_HERE' ON CLUSTER CLUSTER_NAME_HERE;
CREATE ROLE gitlab_app ON CLUSTER CLUSTER_NAME_HERE;
GRANT SELECT, INSERT, ALTER, CREATE, UPDATE, DROP, TRUNCATE, OPTIMIZE, dictGet ON gitlab_clickhouse_main_production.* TO gitlab_app ON CLUSTER CLUSTER_NAME_HERE;
GRANT SELECT ON information_schema.* TO gitlab_app ON CLUSTER CLUSTER_NAME_HERE;
GRANT gitlab_app TO gitlab ON CLUSTER CLUSTER_NAME_HERE;

GitLab接続を設定する

接続の確認

接続が正常に設定されたことを確認するには、以下を実行します:

1. Railsコンソールにサインインします。

2. 次のコマンドを実行します:

   ClickHouse::Client.select('SELECT 1', :main)

   成功した場合、コマンドは[{"1"=>1}]を返します。

接続に失敗した場合は、以下を確認してください:

• ClickHouseサービスが実行中でアクセス可能であること。
• GitLabからClickHouseへのネットワーク接続があること。ファイアウォールとセキュリティグループが接続を許可していることを確認してください。
• 接続URLが正しい（ホスト、ポート、プロトコル）。
• 認証情報が正しい。
• HAクラスターデプロイの場合: ロードバランサーが正しく設定され、リクエストをルーティングしていること。

ClickHouse移行の実行

sudo gitlab-rake gitlab:clickhouse:migrate

gitlab-rake gitlab:clickhouse:migrate

分析用ClickHouseの有効化

GitLabインスタンスがClickHouseに接続されたら、ClickHouseを使用する機能を有効にできます:

前提条件:

• インスタンスへの管理者アクセス権が必要です。
• ClickHouse接続が設定され、検証されている。
• 移行が正常に完了している。

分析用ClickHouseを有効にするには、以下の手順に従います:

1. 左側のサイドバーの下部で、管理者を選択します。
2. 設定 > 一般を選択します。
3. ClickHouseを展開します。
4. 分析用ClickHouseの有効化を選択します。
5. 変更を保存を選択します。

分析用ClickHouseの無効化

分析用ClickHouseを無効にするには、以下の手順に従います:

前提条件:

• インスタンスへの管理者アクセス権が必要です。

無効にするには、以下の手順に従います:

1. 左側のサイドバーの下部で、管理者を選択します。
2. 設定 > 一般を選択します。
3. ClickHouseを展開します。
4. 分析用ClickHouseの有効化チェックボックスをオフにします。
5. 変更を保存を選択します。

ClickHouseのアップグレード

ClickHouse Cloud

ClickHouse Cloudは、バージョンのアップグレードとセキュリティパッチを自動的に処理します。手動による操作は不要です。

アップグレードスケジュールとメンテナンスウィンドウについては、ClickHouse Cloudアップグレードを参照してください。

GitLab Self-Managed用ClickHouse（BYOC）

GitLab Self-Managed用ClickHouseの場合、バージョンアップグレードの計画と実行はお客様の責任となります。

前提条件:

• ClickHouseインスタンスへの管理者アクセス権が必要です。
• アップグレードする前に、データをバックアップしてください。ディザスターリカバリーを参照してください。

アップグレードする前に下記をご確認ください:

1. 破壊的な変更については、ClickHouseのリリースノートをご確認ください。
2. GitLabのバージョンとの互換性を確認してください。
3. 非本番環境でアップグレードをテストしてください。
4. 想定されるダウンタイムに備えるか、HAクラスターではローリングアップグレード戦略を採用してください。

ClickHouseをアップグレードするには、以下の手順に従います:

1. 単一ノードデプロイの場合は、ClickHouseのアップグレードドキュメントに従ってください。
2. HAクラスター環境でデプロイを行う場合は、ダウンタイムを最小限に抑えるためにローリングアップグレードを実施してください:
   • ノードを1台ずつ順にアップグレードします。
   • ノードがクラスターに再結合するまで待ちます。
   • 次のノードに進む前に、クラスターのヘルスを検証します。

詳細なアップグレード手順については、アップデートに関するClickHouseのドキュメントを参照してください。

操作

移行ステータスの確認

前提条件:

• インスタンスへの管理者アクセス権が必要です。

ClickHouseの移行ステータスを確認するには、以下の手順に従います:

1. 左側のサイドバーの下部で、管理者を選択します。
2. 設定 > 一般を選択します。
3. ClickHouseを展開します。
4. 利用可能な場合は、移行ステータスセクションを確認します。

または、Railsコンソールを使用して、保留中の移行を確認します:

# Sign in to Rails console
# Run this to check migrations
ClickHouse::MigrationSupport::Migrator.new(:main).pending_migrations

失敗した移行の再試行

ClickHouseの移行が失敗した場合、次の手順に従います:

1. エラーの詳細についてログを確認します。ClickHouse関連のエラーは、GitLabアプリケーションログに記録されます。

2. 根本的な問題（例: メモリ不足、接続の問題など）に対処します。

3. 移行を再試行します:

   # For installations that use the Linux package
   sudo gitlab-rake gitlab:clickhouse:migrate
   
   # For self-compiled installations
   bundle exec rake gitlab:clickhouse:migrate RAILS_ENV=production

ClickHouse Rakeタスク

GitLabには、ClickHouseデータベースを管理するためのいくつかのRakeタスクが用意されています。

次のRakeタスクが利用可能です:

一般的なタスクの例

ClickHouseの接続とスキーマの検証

ClickHouseの接続が動作していることを検証するには、以下を実行します:

# For installations that use the Linux package
sudo gitlab-rake gitlab:clickhouse:info

# For self-compiled installations
bundle exec rake gitlab:clickhouse:info RAILS_ENV=production

このタスクは、ClickHouseの接続と設定に関するデバッグ情報を出力します。

すべての移行を再実行

保留中のすべての移行を実行するには、以下を実行します:

# For installations that use the Linux package
sudo gitlab-rake gitlab:clickhouse:migrate

# For self-compiled installations
bundle exec rake gitlab:clickhouse:migrate RAILS_ENV=production

データベースのリセット

データベースをドロップして再作成するには、以下を実行します:

# For installations that use the Linux package
sudo gitlab-rake gitlab:clickhouse:drop
sudo gitlab-rake gitlab:clickhouse:setup

# For self-compiled installations
bundle exec rake gitlab:clickhouse:drop RAILS_ENV=production
bundle exec rake gitlab:clickhouse:setup RAILS_ENV=production

環境変数

環境変数を使用して、Rakeタスクの動作を制御できます:

パフォーマンスチューニング

ClickHouseのアーキテクチャとパフォーマンスチューニングについては、アーキテクチャに関するClickHouseのドキュメントを参照してください。

ディザスターリカバリー

バックアップと復元

GitLabアプリケーションをアップグレードする前に、完全なバックアップを実行する必要があります。ClickHouseのデータは、GitLabのバックアップツールには含まれていません。

バックアップと復元の戦略は、デプロイの選択によって異なります。

ClickHouse Cloud

ClickHouse Cloudは自動的に以下を行います:

• バックアップと復元を管理します。
• 毎日のバックアップを作成して保持します。

追加の設定を行う必要はありません。

詳細については、ClickHouse Cloudのバックアップを参照してください。

GitLab Self-Managed用ClickHouse

独自のClickHouseインスタンスを運用している場合は、データの安全性を確保するために定期的にバックアップを取得することを推奨します:

• オブジェクトストレージバケット（例: AWS S3）に、（metricsやlogsのようなシステムテーブルを除く）テーブルの最初の完全バックアップを実行します。
• この最初の完全バックアップの後に、増分バックアップを実行します。

この方法では完全バックアップのたびにデータが重複してしまいますが、最も簡単にデータを復元できます。

または、clickhouse-backupを使用することもできます。これはサードパーティ製のツールで、同様の機能に加えてスケジューリングやリモートストレージ管理などの追加機能を提供します。

モニタリング

GitLabインテグレーションの安定性を確保するには、ClickHouseクラスターのヘルスとパフォーマンスを監視する必要があります。

ClickHouse Cloud

ClickHouse Cloudには、セキュアなAPIエンドポイントを介してメトリクスを公開するネイティブのPrometheusインテグレーションが用意されています。

APIの認証情報を生成したら、コレクターを設定して、ClickHouse Cloudからメトリクスをスクレイプできます。たとえば、Prometheusデプロイなどです。

GitLab Self-Managed用ClickHouse

ClickHouseは、Prometheus形式でメトリクスを公開できます。これを有効にするには、以下を実行します:

1. config.xmlのprometheusセクションを設定して、専用ポート（デフォルトは9363）でメトリクスを公開します。

   <prometheus>
       <endpoint>/metrics</endpoint>
       <port>9363</port>
       <metrics>true</metrics>
       <events>true</events>
       <asynchronous_metrics>true</asynchronous_metrics>
   </prometheus>

2. Prometheusまたは同等の互換サーバーを構成し、http://<clickhouse-host>:9363/metricsからメトリクスをスクレイプするように設定してください。

監視するメトリクス

GitLabの機能に影響を与える可能性のある問題を検出するために、次のメトリクスのアラートを設定する必要があります:

稼働状況チェック

ClickHouseがロードバランサーの背後で稼働している場合、HTTPの/pingエンドポイントを使用して稼働状況を確認できます。期待されるレスポンスはHTTPコード200のOkです。

セキュリティと監査ログ

データのセキュリティを確保し、監査証跡機能を確保するには、次のセキュリティ対策を実施します。

ネットワークセキュリティ

• TLS暗号化: ClickHouseサーバーを構成し、TLS暗号化を使用して接続を検証するように設定してください。

  GitLabで接続URLを設定する場合は、これを指定するためにhttps://プロトコル（たとえば、https://clickhouse.example.com:8443）を使用する必要があります。

• IP許可リスト: ClickHouseポート（デフォルト8443または9440）へのアクセスを、GitLabアプリケーションノードおよびその他の承認されたネットワークのみに制限します。

監査ログ

GitLabアプリケーションは、個々のClickHouseクエリに関する個別の監査ログを保持しません。データアクセス（誰がいつ何をクエリしたか）に関する特定の要件を満たすために、ClickHouse側でログ記録を有効にすることができます。

ClickHouse Cloud

ClickHouse Cloudでは、クエリのログ記録はデフォルトで有効になっています。system.query_logテーブルにクエリを実行して、これらのログにアクセスできます。

GitLab Self-Managed用ClickHouse

Self-Managedインスタンスの場合、サーバー設定でquery_log設定パラメータが有効になっていることを確認してください:

1. query_logセクションがconfig.xmlまたはusers.xmlに存在することを確認します:

   <query_log>
       <database>system</database>
       <table>query_log</table>
       <partition_by>toYYYYMM(event_date)</partition_by>
       <flush_interval_milliseconds>7500</flush_interval_milliseconds>
       <ttl>event_date + INTERVAL 30 DAY</ttl>  <!-- Keep only 30 days -->
   </query_log>

2. 有効にすると、実行されたすべてのクエリがsystem.query_logテーブルに記録され、監査証跡が可能になります。

システム要件

推奨されるシステム要件は、ユーザー数によって異なります。

デプロイの意思決定マトリックスのクイックリファレンス

1,000ユーザー

推奨: ClickHouse Cloud Basicは、運用の複雑さがなく、コスト効率にも優れています。

2,000ユーザー

推奨: ClickHouse Cloud Basicは、運用の複雑さがなく、コスト効率が最も優れています。

GitLab Self-Managed用ClickHouseのデプロイの代替となる推奨構成は次のとおりです:

• AWS: m8g.xlarge（4 vCPU、16 GB）
• GCP: c4a-standard-4またはn4-standard-4（4 vCPU、16 GB）
• Azure: Standard_D4ps_v6（4 vCPU、16 GB）
• ストレージ: 低～中程度のパフォーマンス層で20 GB

3,000ユーザー

推奨: ClickHouse Cloud Scale

GitLab Self-Managed用ClickHouseのデプロイの代替となる推奨構成は次のとおりです:

• AWS: m8g.2xlarge（8 vCPU、32 GB)
• GCP: c4a-standard-8またはn4-standard-8（8 vCPU、32 GB）
• Azure: Standard_D8ps_v6（8 vCPU、32 GB）
• ストレージ: 中程度のパフォーマンス層で100 GB

5,000ユーザー

推奨: ClickHouse Cloud Scale

GitLab Self-Managed用ClickHouseのデプロイの代替となる推奨構成は次のとおりです:

• AWS: m8g.4xlarge（16 vCPU、64 GB）
• GCP: c4a-standard-16またはn4-standard-16（16 vCPU、64 GB）
• Azure: Standard_D16ps_v6（16 vCPU、64 GB）
• ストレージ: 高パフォーマンス層で100 GB
• デプロイ: 単一ノードを推奨

10,000ユーザー

推奨: ClickHouse Cloud Scale

GitLab Self-Managed用ClickHouseのデプロイの代替となる推奨構成は次のとおりです:

• AWS: m8g.4xlarge（16 vCPU、64 GB）
• GCP: c4a-standard-16またはn4-standard-16（16 vCPU、64 GB）
• Azure: Standard_D16ps_v6（16 vCPU、64 GB）
• ストレージ: 高パフォーマンス層で200 GB
• HAオプション: 3ノードクラスターは、重要なワークロードに対して実行可能になります

25,000ユーザー

推奨: GitLab Self-Managed用ClickHouseまたはClickHouse Cloud Scale。いずれの選択肢も、この規模では経済的に実現可能です。

GitLab Self-Managed用ClickHouseのデプロイに関する推奨事項は次のとおりです:

• 単一ノード:

  • AWS: m8g.8xlarge（32 vCPU、128 GB）
  • GCP: c4a-standard-32またはn4-standard-32（32 vCPU、128 GB）
  • Azure: Standard_D32ps_v6（32 vCPU、128 GB）

• HAデプロイ:

  • AWS: 3 × m8g.4xlarge（各16 vCPU、64 GB）
  • GCP: 3 × c4a-standard-16または3 × n4-standard-16（各16 vCPU、64 GB）
  • Azure: 3 x Standard_D16ps_v6（16 vCPU、64 GB）

• ストレージ: 高パフォーマンス層でノードあたり400 GB。

50,000ユーザー

推奨: GitLab Self-Managed HA用ClickHouseまたはClickHouse Cloud Scale。この規模では、セルフマネージド構成の方がわずかにコスト効率に優れています。

GitLab Self-Managed用ClickHouseのデプロイに関する推奨事項は次のとおりです:

• 単一ノード:

  • AWS: m8g.8xlarge（32 vCPU、128 GB）
  • GCP: c4a-standard-32またはn4-standard-32（32 vCPU、128 GB）
  • Azure: Standard_D32ps_v6（32 vCPU、128 GB）

• HAデプロイ（推奨）:

  • AWS: 3 × m8g.4xlarge（各16 vCPU、64 GB）
  • GCP: 3 × c4a-standard-16または3 × n4-standard-16（各16 vCPU、64 GB）
  • Azure: 3 x Standard_D16ps_v6（16 vCPU、64 GB）

• ストレージ: 高パフォーマンス層でノードあたり1000 GB。

GitLab Self-Managed用ClickHouseのデプロイに関するHAの考慮事項

HAセットアップは、10,000ユーザー以上でのみ費用対効果が高くなります。

• 最小: クォーラム用の3つのClickHouseノード。
• ClickHouse Keeper: 連携用の3つのノード（同じ場所に配置することも、別々に配置することも可能）。
• ロードバランサー: クエリを分散させるために使用することを推奨します。
• ネットワーク: ノード間の低レイテンシー接続は極めて重要です。

用語集

• クラスター: データを保存および処理するために連携するノード（サーバー）の集合。
• MergeTree: MergeTreeは、ClickHouseにおいて、高速なデータのインジェストと大規模データ処理のために設計されたテーブルエンジンです。これはClickHouseの中核的なストレージエンジンであり、カラム型ストレージ、カスタムパーティション、まばらなプライマリインデックス、バックグラウンドでのデータマージ機能などを提供します。
• パーツ: テーブルのデータの一部を格納するディスク上の物理ファイル。パーツは、パーティションキーを使用して作成されるテーブルのデータの論理的な区分であるパーティションとは異なります。
• レプリカ: ClickHouseデータベースに保存されているデータのコピー。冗長性と信頼性を高めるために、同じデータのレプリカをいくつでも持つことができます。レプリカは、ClickHouseが異なるサーバー間でデータの複数のコピーを同期させることができるReplicatedMergeTreeテーブルエンジンと組み合わせて使用されます。
• シャード: データのサブセット。ClickHouseには、常にデータのシャードが少なくとも1つあります。複数のサーバー間でデータを分割しない場合、データは1つのシャードに保存されます。複数のサーバー間でシャーディングデータを使用すると、単一サーバーの容量を超える場合に、ロードを分散できます。
• TTL（Time To Live）: Time To Live（TTL）は、特定の期間が経過すると、カラム/行を自動的に移動、削除、またはロールアップするClickHouseの機能です。これにより、アクセス頻度が低いデータを削除、移動、またはアーカイブできるため、ストレージをより効率的に管理できます。

トラブルシューティング

GitLab 18.0.0以前のデータベーススキーマの移行

Code: 344. DB::Exception: Projection is fully supported in ReplacingMergeTree with deduplicate_merge_projection_mode = throw. Use 'drop' or 'rebuild' option of deduplicate_merge_projection_mode

この問題を回避して移行を実行するには、以下の手順に従います:

1. Railsコンソールにサインインします。

2. 次のコマンドを実行します:

   ClickHouse::Client.execute("INSERT INTO schema_migrations (version) VALUES ('20231114142100'), ('20240115162101')", :main)

3. データベースを再度移行します:

   sudo gitlab-rake gitlab:clickhouse:migrate

今回は、データベースの移行が正常に終了するはずです。

データベースディクショナリの読み取りサポート

GitLab 18.8以降、GitLabはデータ非正規化のためにClickHouse Dictionaryの使用を開始しました。18.8より前のGRANTステートメントは、ディクショナリをクエリするためのgitlabユーザーへの許可を与えなかったため、手動による変更手順が必要です:

1. サインインします:
   • ClickHouse Cloudの場合は、ClickHouse SQLコンソールにサインインします。
   • GitLab Self-Managed用ClickHouseの場合は、clickhouse-clientにサインインします。
2. 次のコマンドを実行し、PASSWORD_HEREを生成されたパスワードに置き換えます。

GRANT dictGet ON gitlab_clickhouse_main_production.* TO gitlab_app;

GRANT dictGet ON gitlab_clickhouse_main_production.* TO gitlab_app ON CLUSTER CLUSTER_NAME_HERE;

権限を付与しないと、ClickHouse移行（CreateNamespaceTraversalPathsDict）は次のエラーで失敗します:

DB::Exception: gitlab: Not enough privileges.

権限を付与した後は、移行を安全に再試行できます（1〜2時間待って分散マイグレーションロックが解除されるのを確認してから実行するのが理想です）。

ClickHouse CIジョブデータマテリアライズドビューのデータの不整合

GitLab 18.5以前のバージョンでは、ネットワークタイムアウト発生後にSidekiqワーカーが再試行を行った際、ClickHouseテーブル（ci_finished_pipelinesやci_finished_buildsなど）に重複データが挿入される可能性がありました。この問題により、マテリアライズドビューに基づく集計結果が不正確となり、Runnerフリートダッシュボードを含む分析ダッシュボード上で誤った集計指標が表示される事象が発生していました。

この問題はGitLab 18.9で修正され、18.6、18.7、および18.8にバックポートされました。この問題を解決するには、GitLab 18.6以降にアップグレードしてください。

既存の重複データがある場合、影響を受けるマテリアライズドビューをリビルドするための修正は、イシュー586319でGitLab 18.10で計画されています。支援が必要な場合は、GitLabサポートにお問い合わせください。