标签: google-cloud-sql

语境

我正在 Cloud Run 上运行 SpringBoot 应用程序，该应用程序使用 Hikari 连接池连接到 postgres11 CloudSQL 数据库。我使用的是最小的 PSQL 实例（1vcpu/614mb/25 连接限制）。对于设置，我遵循了以下资源：

从 Cloud Run 连接到 Cloud SQL

管理数据库连接

问题

部署第三个修订版后，出现以下错误：

FATAL: remaining connection slots are reserved for non-replication superuser connections

我发现了什么

• 默认连接池大小为 10，这就是为什么它在第三次部署时失败 (30 > 25)。

• 删除旧版本时，Cloud SQL 管理面板中显示的活动连接数会减少 10，并且下一次部署会成功。

问题

看来，旧的 Cloud Run 修订版一直处于“冷”状态，以维护其连接池。有没有办法关闭这些连接而不删除修订？

在最佳实践部分，它说：

...我们建议您使用支持连接池的客户端库，该连接池可以自动重新连接断开的客户端连接。”

鉴于旧版本似乎以某种方式设法维护其连接，在 Cloud Run 中管理连接池的推荐方法是什么？

谢谢！

我正在尝试运行以下命令

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 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 …

使用 Python 连接到 Cloud SQL 并不总是那么简单。

根据上下文，有时您必须连接到 Unix 域套接字、将 TCP 连接的 IP 地址列入允许列表、在本地运行 Cloud SQL Auth 代理。确保这些连接安全是另一个挑战：您可能必须管理 SSL 证书、防火墙规则、IP 地址等。

是否有推荐的方法使用 Python以安全且简单的方式连接到 Cloud SQL ？

我刚刚开始尝试从 CloudSQL (PostgreSQL) 到 Bigquery 的新数据流，在启动流时遇到很多错误。主要是BIGQUERY_UNSUPPORTED_TYPE_FOR_PRIMARY_KEY和BIGQUERY_TOO_MANY_PRIMARY_KEYS. 有些表刚刚创建，而其他表则没有创建，即使它们具有相同的主键类型（由 bigserial PRIMARY KEY 创建）