Многорегиональное облако SQL федеративные запросы BigQuery не работают

Question

Согласно документации по федеративным запросам Cloud SQL можно выполнить задание BigQuery для нескольких регионов, чтобы запросить экземпляр Cloud SQL в регионе, охватываемом указанным мультирегионом:

A Мультирегион BigQuery может запрашивать любой регион Cloud SQL в том же месте (США, ЕС). Например:

• Мультирегион BigQuery US может запросить облако SQL us-central1, us-east4, us-west2 и т. Д.

• Мультирегион BigQuery EU может запрашивать облако SQL европа-север1, европа-запад2 и т. Д.

Но когда я пытаюсь выполнить запрос к экземпляру Cloud SQL в us-east4 с местоположением обработки US, он выдает ошибку crypti c.

SELECT id FROM EXTERNAL_QUERY("project.us-east4.external_conn_name", "SELECT id FROM users")

Доступ запрещен: URI: проекты / проект / местоположения / us-east4 / connections / external_conn_name: APPLICATION_ERROR; google.cloud.bigquery.connection.v1beta1 / ConnectionService.GetPrivateConnectionInfo; RP C ошибка; AppErrorCode = 7 ;

Этот же запрос успешно завершается при выполнении с местом обработки us-east4.

В течение двух месяцев я успешно выполнял федеративные запросы по нескольким регионам для выполнения заданий ETL, которые загружают данные Cloud SQL в us-east4 в наборы данных BigQuery в США аналогично описанному ответу здесь . Моя облачная команда проверила изменения IAM, и, по-видимому, изменений не могло быть причиной этой проблемы Кажется, что прошлой ночью в Google Cloud Platform произошли некоторые незаметные изменения, и она нарушила около 100 заданий ETL, которые я выполняю. Я изо всех сил пытаюсь найти быстрое решение, чтобы моя компания могла продолжать использовать данные, зависящие от этих заданий ETL. Любые идеи о том, как я могу обойти эту проблему?

Answer 1

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

Вот что я делаю для исправления этой проблемы:

1. Запустите указанное выше задание извлечения с назначением набора данных в том же регионе (us-east4), что и в облаке SQL экземпляр
2. Экспорт данных выше в корзину GCS в том же регионе, что и шаг 1 (us-east4)
3. Запуск задания службы облачного хранения для копирования данных в корзину GCS в корзину GCS в том же мультирегионе, что и конечный набор данных BigQuery (US)
4. Загрузка данных из многорегиональной корзины GCS в мультирегиональный набор данных BigQuery

Это превратило быстрый и надежный ETL с одним шагом в дорогой ETL с четырьмя шагами с тоннами промежуточного хранения. Google, пожалуйста, исправьте это!