メインコンテンツまでスキップ
に最終更新

オートスケール リソースを使用するように Terraform の構成を更新します

このガイドでは、既存のTerraform構成をLakebaseオートスケールリソース（databricks_postgres_project 、 databricks_postgres_branch 、 databricks_postgres_endpoint 、 databricks_postgres_catalog 、 databricks_postgres_synced_table）を使用するように更新する手順を説明します。

適用される場合​

このガイドに従う前に、Lakebase インスタンスがオートスケールにアップグレードされていることを確認してください。2026年3月12日以降、Database instance API を通じて作成された新しい Lakebase インスタンスはオートスケール プロジェクトとして作成されます。ただし、お客様の Terraform 設定のみが、今もなお databricks_database_instanceを使用してそれらを参照しています。既存のプロビジョニング済みインスタンスも、2026年6月から自動的にオートスケールにアップグレードされます。どちらの場合も、Terraform構成の更新ステップは同じです。以下の「インスタンスがオートスケール中であることを確認する」セクションを参照して、データベースインスタンスが正常に移行されたかどうかを確認してください。

更新の仕組み​

更新はインプレースです。データは移動またはコピーされません。Terraformはプロビジョニング済みリソースの追跡を停止し、オートスケールリソースを通じて同じ基盤となるデータベースの管理を開始し、ゼロへのスケールや分岐などの機能を利用できるようになります。

この変更には、2回のterraform apply呼び出しが必要です。1回はオートスケールのリソースを採用するため、もう1回はプロビジョニングされたリソースをTerraformステートから削除するためです。

プロビジョニングとオートスケールの概念的な違いについては、デフォルトAutoscalingを参照してください。このページでは、Terraform の構成更新のみを対象としています。

前提条件​

始める前に、以下のものが必要です。

  • Terraform 1.7 以降です。「import」ブロックと「removed」ブロックには、Terraform 1.7以降が必要です。
  • プロジェクトに対するCAN MANAGE権限を持つ、OAuth マシン間（M2M）認証用に構成されたサービスプリンシパルOAuthを使用したDatabricksへのサービスプリンシパル アクセスの承認とプロジェクト権限の管理を参照してください。
  • 既存の Lakebase データベースで、現在 Terraform によって databricks_database_instance として管理されています。セットアップに子インスタンス、 databricks_database_database_catalog 、またはdatabricks_database_synced_database_tableが含まれている場合、このガイドではそれらについても説明します。以下の「インスタンスがオートスケール中であることを確認する」セクションを参照して、データベースインスタンスが正常に移行されたかどうかを確認してください。
  • 同期済みテーブルをお持ちで、オートスケール Terraform に更新する場合、このガイドでは、ソースの Delta テーブルが Unity Catalog に既に存在し、id INTEGER NOT NULL 列があるものと想定しています。このガイドでは、これをmain.default.ordersと呼んでいます。実際のソーステーブルのフルネームに置き換えてください。

databricks_database_instanceリソースからdatabricks_postgres_projectリソースへのアプリの切り替えは、まだサポートされていません。

インスタンスがオートスケールになっていることを確認してください。​

Terraform の構成を更新する前に、データベースインスタンスのオートスケールへのアップグレードが完了したことを確認してください。ステップ2 の import ブロックは、アップグレードが完了した後にのみ存在するオートスケールプロジェクト、ブランチ、エンドポイントを採用します。

確認するには：

  1. Lakebase アプリで Provisioned ページを開き、インスタンスを見つけて、インスタンスページに移動してください。
  2. インスタンスページのバナーで、アップグレードが正常に完了したかどうかを確認します。
  3. [オートスケール UI へ移動] をクリックしてください。オートスケールUIのプロジェクトページにいる場合は、「設定」をクリックします。リソース名を見つけ、リソース名入力フィールドの近くにある2つの四角をクリックして、オートスケールプロジェクトのリソース名をコピーします。これをTerraform importブロック内のリソースを参照するために使用します。

アップグレードがまだ完了していない場合は、完了するまでお待ちいただいてから続行してください。お急ぎのアップグレードをご希望の場合は、アカウントチームまたは Databricks サポートにお問い合わせください。

リソースマッピング​

プロビジョニング済み

オートスケール

親 databricks_database_instance

databricks_postgres_project および暗黙的に作成される production ブランチ

親インスタンスの読み取り/書き込みエンドポイント

databricks_postgres_endpoint productionブランチ上のendpoint_id = "primary"と

親インスタンス HA（node_count、読み取り可能なセカンダリ）

productionエンドポイントのコンピュートgroup spec

子databricks_database_instance（任意）

databricks_postgres_branch branch_id が子インスタンスのものと等しい name

子インスタンスの読み取り/書き込みエンドポイント

databricks_postgres_endpoint 子ブランチにendpoint_id = "primary"を含む

databricks_database_database_catalog (任意)

databricks_postgres_catalog 同じ catalog_id

databricks_database_synced_database_table (任意)

databricks_postgres_synced_table 同じ synced_table_id

すべてのプロビジョニングされたインスタンスは、そのオートスケール プロジェクト上でproductionという名前のブランチにマッピングされます。子インスタンスは例外です：そのbranch_idが子インスタンスのnameと等しい個別のブランチにマッピングされます。

プロジェクトIDは、**親**インスタンスのnameを小文字にしたものです。名前に大文字が含まれている場合でも、プロジェクトIDは小文字の形式となります。インポートする前に Databricks UI で確認してください。すべてのブランチインポートIDは、子ブランチに対しても、そのプロジェクトIDをプロジェクトセグメントとして使用します。

ステップ 1：開始状態（プロビジョニング済み）​

初期構成は以下のようになります。my-instance、my-child、my-catalog、my_db、およびmain.default.orders の名前はプレースホルダーです。実際のリソースに既にある名前をご使用ください。ここでのルートインスタンスは HA (プライマリと読み取り可能なセカンダリ) です。ご自身のものがそうでない場合は、node_count と enable_readable_secondaries を除外してください。カタログと同期テーブルのブロックはオプションです。設定で既に使用しているものだけを残してください。

Hcl
terraform {
  required_providers {
    databricks = {
      source = "databricks/databricks"
    }
  }
}

resource "databricks_database_instance" "root" {
  name     = "my-instance"
  capacity = "CU_2"
  node_count                  = 2
  enable_readable_secondaries = true
}

resource "databricks_database_instance" "child" {
  name     = "my-child"
  capacity = "CU_2"
  parent_instance_ref = {
    name = databricks_database_instance.root.name
  }
}

resource "databricks_database_database_catalog" "cat" {
  name                          = "my-catalog"
  database_instance_name        = databricks_database_instance.root.name
  database_name                 = "my_db"
  create_database_if_not_exists = true
}

resource "databricks_database_synced_database_table" "syt" {
  name                  = "my-catalog.default.orders_synced"
  logical_database_name = databricks_database_database_catalog.cat.database_name
  spec = {
    scheduling_policy                  = "SNAPSHOT"
    source_table_full_name             = "main.default.orders"
    primary_key_columns                = ["id"]
    create_database_objects_if_missing = true
    new_pipeline_spec = {
      storage_catalog = "main"
      storage_schema  = "default"
    }
  }
}

ステップ 2 （適用 1）：オートスケール リソースを導入する​

既存のプロビジョニング済みリソースと共に、新しいオートスケールリソースを追加します。既存の databricks_database_instance ブロックは構成内に保持してください。新しいオートスケールリソースは、それらの隣に配置されます。プロジェクトと両方のブランチはimportブロックを使用します。2つのエンドポイント（productionブランチと子ブランチ）は、エンドポイントが現在、標準のimportブロックをサポートしていないため、importブロックの代わりにreplace_existing = trueを使用します。terraform plan は、エンドポイントが「作成されます」と表示されます。これは移行目的の予期された動作です ― サーバー側で何も再作成されることはなく、リソースは安全です。

Hcl
# In Lakebase Autoscaling, the parent database instance is represented
# by a project plus an implicitly created "production" branch.
resource "databricks_postgres_project" "root" {
  project_id = "my-instance"  # use the ID from section "Confirm your instance is on Autoscaling"
  spec       = null
}

# Branch corresponding to the parent database_instance.
resource "databricks_postgres_branch" "production" {
  branch_id = "production"
  parent    = databricks_postgres_project.root.name
  spec      = null
}

# Branch corresponding to the child database_instance.
resource "databricks_postgres_branch" "child" {
  branch_id = "my-child"
  parent    = databricks_postgres_project.root.name
  spec      = null
  # spec = null is required during adoption. Setting any spec field causes
  # Terraform to write that value on apply. Fields like source_branch,
  # source_branch_lsn, and endpoint_type are immutable in Lakebase —
  # specifying them forces Terraform to replace (delete and recreate) the
  # resource instead of importing it cleanly. After adoption is complete
  # you can populate mutable fields (such as is_protected) to manage the
  # branch going forward. To look up the source branch, read it from
  # Branch.status.source_branch.
}

# The child branch's primary read-write endpoint.
# Pick one of the spec variants from the tabs below.
resource "databricks_postgres_endpoint" "child_rw_endpoint" {
  endpoint_id = "primary"
  parent      = databricks_postgres_branch.child.name
  spec = {
    endpoint_type = "ENDPOINT_TYPE_READ_WRITE"
  }
  replace_existing = true
}

# The production branch's primary read-write endpoint. Because the parent
# instance is HA, its HA carries over here as a compute `group` (see the
# "Preserving HA" note below). If your parent instance isn't HA, drop the
# `group` and `no_suspension` and keep only `endpoint_type`. If
resource "databricks_postgres_endpoint" "production_rw_endpoint" {
  endpoint_id = "primary"
  parent      = databricks_postgres_branch.production.name
  spec = {
    endpoint_type = "ENDPOINT_TYPE_READ_WRITE"
    no_suspension = true
    group = {
      min                         = 2
      max                         = 2
      enable_readable_secondaries = true
    }
  }
  replace_existing = true
}

# Import the project. Postgres resources use the canonical
# "projects/{project_id}" form as the import ID, where project_id is
# the resource name from section "Confirm your instance is on Autoscaling",
# with "projects/" prefix stripped off.
import {
  to = databricks_postgres_project.root
  id = "projects/my-instance"
}

# Import the production branch. The Provisioned parent always maps to
# a branch named "production" on the new project.
# Use the resource name from section "Confirm your instance is on Autoscaling",
# append "/branches/production" to it.
import {
  to = databricks_postgres_branch.production
  id = "projects/my-instance/branches/production"
}

# Import the child branch. Use the resource name from section
# "Confirm your instance is on Autoscaling", same as when importing
# the "production" branch above. The branch segment is the child instance's name.
import {
  to = databricks_postgres_branch.child
  id = "projects/my-instance/branches/my-child"
}

# The catalog. Pin `catalog_id` to the same name your
# databricks_database_database_catalog already uses, written as a
# literal so the new resource does not depend on the old one. `spec
# = null` is required during adoption — see the "Why spec = null on
# catalog and synced table" note below.
resource "databricks_postgres_catalog" "cat" {
  catalog_id = "my-catalog"
  spec       = null
}

import {
  to = databricks_postgres_catalog.cat
  id = "catalogs/my-catalog"
}

# The synced table. Pin `synced_table_id` to the same fully-qualified
# name your databricks_database_synced_database_table already uses,
# again as a literal.
# `depends_on` is required to build the correct Terraform dependency graph,
# for correct resource management.
resource "databricks_postgres_synced_table" "syt" {
  synced_table_id = "my-catalog.default.orders_synced"
  spec            = null
  depends_on = [
    databricks_postgres_catalog.cat
  ]
}

import {
  to = databricks_postgres_synced_table.syt
  id = "synced_tables/my-catalog.default.orders_synced"
}

エンドポイントの spec については、以下のいずれかのバリアントを選択してください。

注記

カタログと同期テーブルでspec = nullする理由 今日、terraform importの後、カタログと同期テーブルのspecがプロバイダーの読み取りから空で返されます（spec内の入力フィールドは書き込み専用として扱われます）。HCL に spec が入力されたままになっている場合、Terraform は、入力された HCL と空の状態を比較し、リソースを破棄して再作成する計画を立てます。spec = nullを設定すると、Terraformは差分を取らないため、インポートが保持されます。お客様のデータは変更されません。プロビジョニングされたリソースが作成された時点から、サーバーにはすでに正しい設定がされています。これらのリソースでは、スペックフィールドもIMMUTABLEであるため、HCLに値を入力できたとしても、後で変更することはできません。specがReadを介して正しくラウンドトリップするため、エンドポイント、プロジェクト、およびブランチにはspec = nullは必要ありません。

既存のエンドポイントをそのまま採用してください。導入時にサーバーサイドでの動作に変化はありません。

Hcl
spec = {
  endpoint_type = "ENDPOINT_TYPE_READ_WRITE"
}
注記

高可用性を保持します。 上記のproductionエンドポイントは、親インスタンスのHAをコンピュートgroupとして引き継ぎます。minとmaxはインスタンスのnode_countと等しくなり、enable_readable_secondariesはインスタンスと一致します。HA エンドポイントはno_suspension = trueを設定する必要があります。そのため、HA エンドポイントはゼロにスケールすることもできません。

いずれの選択肢も1つのterraform applyです。

terraform applyを実行します。

ステップ3（適用 2）：Terraform ステートからプロビジョニングされたリソースを削除​

オートスケールのリソースがデータベースを正しく管理していることを確認したら、Terraform のステートから元の databricks_database_instance ブロックを削除してください。lifecycle.destroy = falseと合わせてremovedブロックを使用することで、Terraformはデータを削除せずにプロビジョニング済みリソースの管理を停止します。

設定からdatabricks_database_instanceブロックとdatabricks_database_database_catalog/databricks_database_synced_database_tableブロックを削除し、それぞれにremoved {}ブロックを追加します。

Hcl
removed {
  from = databricks_database_synced_database_table.syt
  lifecycle {
    destroy = false
  }
}

removed {
  from = databricks_database_database_catalog.cat
  lifecycle {
    destroy = false
  }
}

removed {
  from = databricks_database_instance.child
  lifecycle {
    destroy = false  # it is crucial to set destroy = false. Not doing so results in your database being deleted.
  }
}

removed {
  from = databricks_database_instance.root
  lifecycle {
    destroy = false
  }
}

terraform applyを実行します。

プランの出力では、次のような行が表示されます。

# databricks_database_instance.root will no longer be managed by Terraform, but will not be destroyed
# (destroy = false is set in the configuration)
...
... and similar entry for each of the resource you have used removed block for.
...

予想通りです。データはとどまります。Terraformはプロビジョニング済みリソースの追跡を停止し、ステップ2で採用したオートスケールリソースを介してデータベースを管理します。

Postgresロールとデータベース​

オートスケールリソースが設定に組み込まれると、databricks_postgres_role および databricks_postgres_database を介して、Terraform を使用して Postgres ロールとデータベースを今後作成および更新できます。既存のデータベースに既に存在するが、Terraformで宣言されていないロールとデータベースは削除されません。Terraformが破壊するのは、ステートで追跡しているリソースのみです。構成の更新前に存在していたロールとデータベースのインポートはまだサポートされていません。「databricks_postgres_role」 および 「databricks_postgres_database」 のリファレンス ページ、または完全な例については 「Terraformを使用した典型的なLakebaseプロジェクトのセットアップ」 を参照してください。

productionブランチとprimaryエンドポイントと同様に、すべてのオートスケールプロジェクトには暗黙的に作成されるロールとデータベースも存在します。

アップグレード後、何ができるようになりましたか？​

プロジェクトがオートスケールとして管理されるようになると、プロビジョニングでは利用できなかったことが行えるようになります。ハイライト：

これらの多くを組み合わせて使用する、本番運用に対応した完全なTerraform構成については、「一般的なLakebaseプロジェクトのTerraformセットアップ」を参照してください。

その他のリソース​

このページの見出し