Можно ли указать существующий экземпляр CloudSQL в качестве места назначения для службы миграции базы данных в GCP?

Согласно руководствам GCP, настройка миграции базы данных включает создание задания миграции в консоли с помощью мастера [1]. Мастер создает новый экземпляр CloudSQL, но я хотел бы указать существующий экземпляр, чтобы мы могли управлять целевым экземпляром с помощью контроля версий (например, Terraform)

Можно ли указать существующий экземпляр CloudSQL в качестве места назначения для службы миграции базы данных в GCP? Если да, то как?

Если нет, другим решением для управления версиями является создание задания миграции (и, возможно, целевого экземпляра) с помощью сценария, выполняющего команды gcloud CLI/API.

Из руководств по API для миграции баз данных [2] кажется, что нам нужно указать пункт назначения профиль подключения.

идентификатор профиля-назначения-соединения: идентификатор профиля соединения-назначения.

Это отражено в документах gcloud CLI [3].

--destination=ЦЕЛЬ
Идентификатор профиля_соединения или полный идентификатор для профиля_соединения. Чтобы установить атрибут connection_profile:
укажите аргумент --destination в командной строке.

Означает ли это, что для создания задания миграции через интерфейс командной строки мне нужно будет вручную создать целевой экземпляр CloudSQL И профиль подключения для этого экземпляра? Если да, то какие привилегии нужны пользователю подключения? Или команда «gcloud database-migration migration-jobs create» автоматически создает целевой экземпляр?

В противном случае, открыты для предложений относительно того, что может означать флаг --destination.

[1] https://cloud.google.com/database-migration/docs/mysql/create-migration-job

[2] https://cloud.google.com/database-migration/docs/mysql/api-migration-jobs#create_a_continuous_migration_job_with_reverse_ssh_connectivity

[3] https://cloud.google.com/sdk/gcloud/reference/database-migration/migration-jobs/создать

Вы задали следующие вопросы:

• Можно ли указать существующий экземпляр CloudSQL в качестве пункт назначения для службы миграции базы данных в GCP?

• Создает ли команда «gcloud database-migration migration-jobs» автоматически создать экземпляр назначения?

• Означает ли это, что для создания задания миграции через интерфейс командной строки я потребуется вручную создать целевой экземпляр CloudSQL И профиль подключения для этого экземпляра?

• Ответ на 1-й вопрос: Нет, это невозможно. мой взгляд на это что служба миграции базы данных всегда будет создавать новый экземпляр. При использовании мастера/консоли для выполнения службы миграции, когда вы нажимаете на создание пункта назначения, он автоматически создает новый Целевой экземпляр Cloud SQL для вас. При использовании API вы ожидается создание целевого профиля. Посмотри это соединять где это упомянул «Создайте профиль подключения для Cloud SQL для MySQL назначение... Служба миграции баз данных для MySQL использует информация в этом запросе для создания нового Cloud SQL для MySQL пример."

  Я думаю, что было бы довольно сложно заставить сервис работать надежно если бы мы не создавали новый экземпляр каждый раз. Тем не менее, я думаю, услуга в том виде, в каком она существует сейчас, предназначена для поддержки большего количества вариантов в будущем, так что это может произойти, но я не вижу доказательство того, что это можно сделать сейчас.

• Ответ на 2-й вопрос: нет, не создает. Когда вы бежите команду «gcloud database-migration migration-jobs create», вы должны быть созданы профили исходного и целевого соединения и задаются в качестве параметров этой команды в соответствии с документация.

• Ответ на 3-й вопрос: Нет. Чтобы сделать это с помощью gcloud (или API) вам необходимо создать профили исходного и целевого подключения, затем будет создано задание миграции и целевой экземпляр. для вас согласно предоставленной информации здесь.

Ваша озабоченность тем, как управлять этим с помощью terraform, вероятно, обоснована и, возможно, интересна, но terraform — это сторонний продукт, и Google не создает API с учетом своей модели. Возможно, вы могли бы создать проблему с этим, и кто-то с этой стороны может изучить ее.

К сожалению, Google решил реализовать это решение таким образом. Сначала я подумал, что это больше похоже на подход AWS, где DMS настраивает промежуточный экземпляр базы данных для переноса/манипулирования данными перед репликацией в целевой экземпляр/механизм БД.

Надеюсь, что со временем они изменятся, но на данный момент это не похоже на полностью законченный продукт.