标签: google-cloud-sql

我正在尝试运行以下命令

gcloud beta sql instances create my_replica \
--master-instance-name=db-master01 \
--master-username=replication_user \
--master-password='replication_password' \
--master-dump-file-path=gs://path/to/dump.sql.gz \
--database-flags default_time_zone='-05:00' \
                 sql_mode='STRICT_TRANS_TABLES, NO_ZERO_IN_DATE, NO_ZERO_DATE, ERROR_FOR_DIVISION_BY_ZERO, NO_AUTO_CREATE_USER, NO_ENGINE_SUBSTITUTION' \
--region=us-central \
--tier=db-g1-small

但我收到以下错误：

ERROR: (gcloud.beta.sql.instances.create) unrecognized arguments: sql_mode=STRICT_TRANS_TABLES, NO_ZERO_IN_DATE, NO_ZERO_DATE, ERROR_FOR_DIVISION_BY_ZERO, NO_AUTO_CREATE_USER, NO_ENGINE_SUBSTITUTION

To search the help text of gcloud commands, run:
  gcloud help -- SEARCH_TERMS

我输入的内容有误吗？这是不支持的吗？

更新： 根据 Stefan 的回复，我更新了命令以修复语法。我得到的新错误如下：

这是我的命令：

gcloud beta sql instances create $replica_name \
--master-instance-name=db-master01 \
--master-username=replication_user \
--master-password='replication_password' \
--master-dump-file-path=gs://path/to/dump.sql.gz \
--database-flags default_time_zone='-05:00',sql_mode='STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION' \
--region=us-central \
--tier=db-g1-small …

我正在调查一些缓慢的查询，我需要一些帮助来读取我得到的数据。

我们有一个特定的查询，它使用索引并且大多数时候运行得相当快，但是有时它运行得很慢（700 毫秒以上），不知道为什么。

Limit  (cost=8.59..8.60 rows=1 width=619) (actual time=5.653..5.654 rows=1 loops=1)
   ->  Sort  (cost=8.59..8.60 rows=1 width=619) (actual time=5.652..5.652 rows=1 loops=1)
         Sort Key: is_main DESC, id
         Sort Method: quicksort  Memory: 25kB
         ->  Index Scan using index_pictures_on_imageable_id_and_imageable_type on pictures  (cost=0.56..8.58
rows=1 width=619) (actual time=3.644..5.587 rows=1 loops=1)
               Index Cond: ((imageable_id = 12345) AND ((imageable_type)::text = 'Product'::text))
               Filter: (tag = 30)
               Rows Removed by Filter: 2
 Planning Time: 1.699 ms
 Execution Time: 5.764 ms

如果我理解正确的话，我会说查询的几乎全部成本都在索引扫描上，对吗？这对我来说听起来不错，那么为什么同一个查询有时运行得相当慢呢？

我开始认为我们的实例可能无法将整个索引保留在内存中，因此它时不时地使用磁盘。这可以解释缓慢的查询。然而，这超出了我的想象。那有意义吗？

该表有大约 1500 万行，5156 MB大小也大约是 1500 万行。索引为 …

默认情况下，Cloud Dataproc运行 Dataproc 集群本地的 Hive Metastore。这意味着：

1. 元存储与集群一起是短暂的

2. 使用单个元存储拥有多个集群可能会很痛苦

是否可以将 Dataproc 集群指向单个 Hive 元存储？是否也可以让元存储位于集群外部，这样就不需要为元存储运行集群？

我正在尝试创建 GCP postgreSQL 实例，并使其可以在一个项目中从多个 VPC 网络进行访问。

我们在 4 个 GCP 区域拥有虚拟机。每个区域都有自己的 VPC 网络，并且所有网络都是对等的。但是当我创建 SQL 实例时，我只能将其私有 IP 映射到一个 VPC，其他人无权访问它。

是否需要遵循任何步骤才能允许从多个 VPC 访问一个 SQL 实例？

我想为 postgresql 设置 AWS RDS 和 GCP 之间的复制。我找到了 MYSQL 的文档，但无法获取 postgres 的文档。

是否有任何选项可以在没有任何外部工具的情况下设置复制？

我有一个 Cloud Run 服务，可以通过SQLAlchemy. 但是，在 Cloud Run 的日志中，我看到CloudSQL connection failed. Please see https://cloud.google.com/sql/docs/mysql/connect-run for additional details: ensure that the account has access to "<connection_string>". 转到该链接，它说：

“默认情况下，您的应用将使用 Cloud Run（完全托管）服务帐户授权您的连接。服务帐户的格式为 PROJECT_NUMBER-compute@developer.gserviceaccount.com。”

但是，以下内容（https://cloud.google.com/run/docs/securing/service-identity）表示：

“默认情况下，Cloud Run 修订版使用 Compute Engine 默认服务帐户 (PROJECT_NUMBER-compute@developer.gserviceaccount.com)，该帐户具有项目 > 编辑器 IAM 角色。这意味着默认情况下，您的 Cloud Run 修订版具有读取和写入功能访问您的 Google Cloud 项目中的所有资源。”

那么这是否意味着 Cloud Run 已经可以访问 SQL 了？我已在 Cloud Run 部署页面中设置了 Cloud SQL 连接。您建议我做什么才能允许从 Cloud Run 访问 Cloud SQL？

编辑：我必须启用 Cloud SQL API。

我是 Google Cloud SQL 和 Pub/Sub 的新手。我在任何地方都找不到关于此的文档。但另一个问题的接受和赞成的答案似乎是说，只要数据库发生插入，就可以发布发布/订阅消息。摘录自该答案：

2 - 理想的解决方案是创建 Pub/Sub 主题并在将新数据插入数据库时​​发布到该主题。

但由于我的问题是不同的，因此我在这里提出了一个新问题。

背景：我的应用程序结合使用了 Google Cloud SQL、Firestore 和实时数据库，以发挥其独特的优势。

我想要做的是一旦在 Google Cloud SQL 中插入成功，就能够写入 Firestore 和 Realtime 数据库。根据上面的答案，这是我应该做的步骤：

1. 该应用程序调用 Cloud Function 将数据插入 Google Cloud SQL 数据库 (PostgreSQL)。注意：Postgres 表有一些重要的约束和触发器 Postgres 函数，这就是我们要从这里开始的原因。
2. 插入成功后，我希望 Google Cloud SQL 向 Pub/Sub 发布一条消息。
3. 然后还有另一个订阅 Pub/Sub 主题的 Cloud Function。该函数将相应地写入Firestore /实时数据库。

我已经弄清楚了步骤 #1 和 #3。我正在寻找的解决方案是步骤#2。

Failed to update metadata for Cloud SQL instance.
at com.google.cloud.sql.core.CloudSqlInstance.addExceptionContext (CloudSqlInstance.java:455)
at com.google.cloud.sql.core.CloudSqlInstance.fetchMetadata (CloudSqlInstance.java:322)
at com.google.common.util.concurrent.TrustedListenableFutureTask$TrustedFutureInterruptibleTask.runInterruptibly (TrustedListenableFutureTask.java:125)
at com.google.common.util.concurrent.InterruptibleTask.run (InterruptibleTask.java:69)
at com.google.common.util.concurrent.TrustedListenableFutureTask.run (TrustedListenableFutureTask.java:78)
at java.util.concurrent.Executors$RunnableAdapter.call (Executors.java:515)
at java.util.concurrent.FutureTask.run (FutureTask.java:264)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run (ScheduledThreadPoolExecutor.java:304)
at java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1128)
at java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:628)
at java.lang.Thread.run (Thread.java:834)
Caused by: javax.net.ssl.SSLException: readHandshakeRecord
at sun.security.ssl.SSLSocketImpl.readHandshakeRecord (SSLSocketImpl.java:1320)
at sun.security.ssl.SSLSocketImpl.startHandshake (SSLSocketImpl.java:440)
at sun.security.ssl.SSLSocketImpl.startHandshake (SSLSocketImpl.java:411)
at sun.net.www.protocol.https.HttpsClient.afterConnect (HttpsClient.java:567)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect (AbstractDelegateHttpsURLConnection.java:185)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.connect (HttpsURLConnectionImpl.java:168)
at com.google.api.client.http.javanet.NetHttpRequest.execute (NetHttpRequest.java:148)
at com.google.api.client.http.javanet.NetHttpRequest.execute (NetHttpRequest.java:84)
at com.google.api.client.http.HttpRequest.execute (HttpRequest.java:1012)
at com.google.api.client.googleapis.services.AbstractGoogleClientRequest.executeUnparsed (AbstractGoogleClientRequest.java:549)

另一个

Failed to create ephemeral …

我想从 BigQuery 迁移到 CloudSQL 以节省成本。我的问题是，与 BigQuery 相比，带有 PostgreSQL 的 CloudSQL 非常慢。在 BigQuery 中需要 1.5 秒的查询在带有 PostgreSQL 的 CloudSQL 上需要近 4.5 分钟（！）。

我有 CloudSQL 和 PostgreSQL 服务器，配置如下：

我的数据库有一个包含 16M 行的主表（RAM 约为 14GB）。

查询示例：

EXPLAIN ANALYZE 
  SELECT 
    "title"
  FROM 
    public.videos
  WHERE 
      EXISTS (SELECT 
                * 
              FROM (
                    SELECT 
                      COUNT(DISTINCT CASE WHEN LOWER(param) LIKE '%thriller%' THEN '0'
                                          WHEN LOWER(param) LIKE '%crime%' THEN '1' END) AS count
                    FROM
                      UNNEST(categories) AS param
                    ) alias
                        WHERE count = 2)

  ORDER BY views DESC 

  LIMIT 12 OFFSET 0 …

在我的Composer Airflow DAG 中，我一直在使用 CloudSqlProxyRunner连接到我的 Cloud SQL 实例。

然而，在将 Google Cloud Composer 从 v1.18.4 更新到 1.18.6 后，我的 DAG 开始遇到一个奇怪的错误：

[2022-04-22, 23:20:18 UTC] {cloud_sql.py:462} INFO - Downloading cloud_sql_proxy from https://dl.google.com/cloudsql/cloud_sql_proxy.linux.x86_64 to /home/airflow/dXhOYoU_cloud_sql_proxy.tmp
[2022-04-22, 23:20:18 UTC] {taskinstance.py:1702} ERROR - Task failed with exception
Traceback (most recent call last):
  File "/opt/python3.8/lib/python3.8/site-packages/airflow/models/taskinstance.py", line 1330, in _run_raw_task
    self._execute_task_with_callbacks(context)
  File "/opt/python3.8/lib/python3.8/site-packages/airflow/models/taskinstance.py", line 1457, in _execute_task_with_callbacks
    result = self._execute_task(context, self.task)
  File "/opt/python3.8/lib/python3.8/site-packages/airflow/models/taskinstance.py", line 1513, in _execute_task
    result = execute_callable(context=context)
  File "/opt/python3.8/lib/python3.8/site-packages/airflow/decorators/base.py", line 134, in …