인스턴스가 SSL을 사용하도록 구성된 경우 Google Cloud 콘솔의 Cloud SQL 인스턴스 페이지로 이동하여 인스턴스를 엽니다. 인스턴스의 연결 페이지를 열고 보안 탭을 선택한 후 서버 인증서가 유효한지 확인합니다. 만료된 경우 새 인증서를 추가하고 새 인증서로 순환시켜야 합니다.
해당 프로젝트에 존재하지 않는 인스턴스에 연결하려고 할 경우 해당 인스턴스에 액세스할 수 있는 권한이 없다는 오류 메시지만 표시됩니다.
Cloud SQL 인스턴스를 만들 수 없음
Failed to create subnetwork. Router status is temporarily
unavailable. Please try again later. Help Token: [token-ID] 오류 메시지가 표시되면 Cloud SQL 인스턴스를 다시 만들어 보세요.
다음이 기본 사용자('postgres')에서만 작동함.
gcloud sql connect --user
이 명령어를 다른 사용자와 연결하려는 경우 FATAL: database 'user' does not exist라는 오류 메시지가 표시됩니다. 해결 방법은 기본 사용자('postgres')를 사용하여 연결한 다음 "\c" psql 명령어를 사용하여 다른 사용자로 다시 연결하는 것입니다.
IAM db 프록시 인증이 사용 설정되면 PostgreSQL 연결이 중단됨.
Cloud SQL Auth 프록시가 TCP 소켓을 사용하여 시작되고 -enable_iam_login 플래그가 포함된 경우 TCP 연결이 진행되는 동안 PostgreSQL 클라이언트가 중단됩니다.
한 가지 해결 방법은 PostgreSQL 연결 문자열에 sslmode=disable을 사용하는 것입니다. 예를 들면 다음과 같습니다.
인스턴스에서 한 번에 하나의 장기 실행 Cloud SQL 가져오기 또는 내보내기 작업만 실행할 수 있습니다. 작업을 시작할 때 인스턴스에서 다른 작업을 수행할 필요가 없는지 확인하세요. 또한 작업을 시작할 때 취소할 수 있습니다.
PostgreSQL은 단일 트랜잭션으로 데이터를 가져옵니다. 따라서 가져오기 작업을 취소하면 Cloud SQL에서 가져오기의 데이터가 유지되지 않습니다.
데이터 가져오기 및 내보내기 문제
Cloud SQL 인스턴스에서 PostgreSQL 17을 사용하지만 데이터베이스에서 PostgreSQL 16 이하를 사용하는 경우 Cloud SQL을 사용하여 이러한 데이터베이스를 인스턴스로 가져올 수 없습니다. 이를 위해서는 Database Migration Service를 사용하세요.
Database Migration Service를 사용하여 PostgreSQL 17 데이터베이스를 Cloud SQL로 가져오는 경우 PostgreSQL 16 데이터베이스로 가져옵니다.
PostgreSQL 버전 15 이상에서는 대상 데이터베이스가 template0에서 생성되면 데이터를 가져올 수 없고 permission denied for schema public 오류 메시지가 표시될 수 있습니다. 이 문제를 해결하려면 GRANT ALL ON SCHEMA public TO cloudsqlsuperuser SQL 명령어를 실행하여 cloudsqlsuperuser 사용자에게 공개 스키마 권한을 제공합니다.
많은 대형 객체를 내보내면 인스턴스가 응답하지 않음
데이터베이스에 대형 객체(blob)가 많이 포함되어 있을 때 데이터베이스를 내보내면 너무 많은 메모리가 소비되어 인스턴스가 응답하지 않습니다. 이러한 문제는 blob이 비어 있어도 발생합니다.
Cloud SQL은 맞춤설정된 테이블스페이스를 지원하지 않지만 대상 인스턴스에서 맞춤설정된 테이블 스페이스에서 기본 테이블스페이스인 pg_default로의 데이터 마이그레이션을 지원합니다. 예를 들어 /home/data에 dbspace라는 테이블스페이스가 있는 경우 마이그레이션 후에 dbspace 내의 모든 데이터는 pg_default로 마이그레이션됩니다. 하지만 Cloud SQL은 디스크에 'dbspace'라는 테이블스페이스를 만들지 않습니다.
대규모 데이터베이스(예: 데이터가 500GB 이상인 데이터베이스)에서 데이터를 가져오고 내보내려는 경우 가져오기 및 내보내기 작업을 완료하는 데 시간이 오래 걸릴 수 있습니다. 또한 가져오기 또는 내보내기가 진행되는 동안 다른 작업(예: 백업 작업)을 수행할 수 없습니다. 가져오기 및 내보내기 프로세스의 성능을 향상시킬 수 있는 옵션은 gcloud 또는 API를 사용하여 이전 백업을 복원하는 것입니다.
Cloud Storage는 최대 단일 객체 크기를 5TB까지 지원합니다.
데이터베이스가 5TB보다 크면 Cloud Storage로 내보내기 작업이 실패합니다. 이 경우 내보내기 파일을 보다 작은 세그먼트로 분할해야 합니다.
트랜잭션 로그 및 디스크 증가
로그는 매일 한 번씩 영구 삭제되며, 지속적으로 진행되지 않습니다. 로그 보관 일수가 백업 수와 동일하게 구성된 경우 백업 발생 시점에 따라 1일 치의 로깅이 손실될 수 있습니다. 예를 들어 로그 보관을 7일로 설정하고 백업 보관을 7개로 설정하면 6~7일 동안의 로그가 유지됩니다.
백업 수는 로그 보관 일수보다 최소 1일 이상으로 설정해야 로그 보관 기간을 지정된 최소 일수 이상으로 유지할 수 있습니다.
Cloud Monitoring 또는 Cloud Logging 관련 문제
다음 리전 이름의 인스턴스는 특정 컨텍스트에서 다음과 같이 잘못 표시됩니다.
us-central1은 us-central로 표시됩니다.
europe-west1은 europe으로 표시됩니다.
asia-east1은 asia로 표시됩니다.
이 문제는 다음 상황에서 발생합니다.
Cloud Monitoring의 알림
측정항목 탐색기
Cloud Logging
리소스 메타데이터 라벨을 사용하여 Cloud Monitoring의 알림과 측정항목 탐색기의 문제를 완화할 수 있습니다.
cloudsql_database 모니터링 리소스 라벨 region 대신 시스템 메타데이터 라벨 region을 사용합니다.
PostgreSQL 데이터베이스 삭제와 관련된 문제
psql 클라이언트를 사용하여 Google Cloud 콘솔에서 생성된 데이터베이스를 삭제하면 다음 오류가 발생할 수 있습니다.
ERROR: must be owner of database [DATABASE_NAME]
psql 클라이언트를 사용하여 생성된 데이터베이스의 소유자에게 Cloud SQL superuser 속성이 없으므로 권한 오류입니다.
Google Cloud 콘솔을 사용하여 만든 데이터베이스는 cloudsqlsuperuser가 소유하고 psql 클라이언트를 사용하여 만든 데이터베이스는 해당 데이터베이스에 연결된 사용자가 소유합니다. Cloud SQL은 관리형 서비스이므로 고객은 superuser 속성이 있는 사용자를 만들거나 이 사용자로 액세스할 수 없습니다.
자세한 내용은 슈퍼유저 제한사항 및 권한을 참조하세요.
이 제한으로 인해 Google Cloud 콘솔을 사용하여 만든 데이터베이스는 Google Cloud 콘솔을 사용해서만 삭제할 수 있으며 psql 클라이언트를 사용하여 만든 데이터베이스는 데이터베이스 소유자로 연결해야만 삭제할 수 있습니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-08-19(UTC)"],[],[],null,["# Known issues\n\n\u003cbr /\u003e\n\n[MySQL](/sql/docs/mysql/known-issues \"View this page for the MySQL database engine\") \\| PostgreSQL \\| [SQL Server](/sql/docs/sqlserver/known-issues \"View this page for the SQL Server database engine\")\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nThis page lists known issues with Cloud SQL for PostgreSQL, along with\nways you can avoid or recover from these issues.\nIf you are experiencing issues with your instance, make sure you also review the information in [Diagnosing Issues](/sql/docs/postgres/diagnose-issues).\n\n### Instance connection issues\n\n- Expired SSL/TLS certificates\n\n\n If your instance is configured to use SSL, go to the\n [Cloud SQL Instances page](https://console.cloud.google.com/sql/instances)\n in the Google Cloud console and open the instance. Open its **Connections** page, select the\n **Security** tab and make sure that your server certificate is valid. If it has expired, you must\n add a new certificate and rotate to it.\n\n \u003cbr /\u003e\n\n- Cloud SQL Auth Proxy version\n\n If you are connecting using the Cloud SQL Auth Proxy, make sure you are using the\n most recent version. For more information, see\n [Keeping the Cloud SQL Auth Proxy up to date](/sql/docs/postgres/sql-proxy#keep-current).\n- Not authorized to connect\n\n If you try to connect to an instance that does not exist in that project,\n the error message only says that you are not authorized to access that\n instance.\n- Can't create a Cloud SQL instance\n\n If you see the `Failed to create subnetwork. Router status is temporarily\n unavailable. Please try again later. Help Token: [token-ID]` error\n message, try to create the Cloud SQL instance again.\n\n\u003c!-- --\u003e\n\n- The following only works with the default user ('postgres'):\n `gcloud sql connect --user`\n\n If you try to connect using this command with any other user, the error\n message says \u003cvar translate=\"no\"\u003eFATAL: database 'user' does not exist\u003c/var\u003e. The\n workaround is to connect using the default user ('postgres'), then use\n the `\"\\c\"` psql command to reconnect as the different user.\n\n\u003c!-- --\u003e\n\n- PostgreSQL connections hang when IAM db proxy authentication is enabled.\n\n When the [Cloud SQL Auth Proxy is started using TCP sockets](/sql/docs/postgres/connect-auth-proxy#start-proxy) and with the `-enable_iam_login` flag,\n then a PostgreSQL client hangs during TCP connection. One workaround\n is to use `sslmode=disable` in the PostgreSQL connection\n string. For example: \n\n ```bash\n psql \"host=127.0.0.1 dbname=postgres user=me@google.com sslmode=disable\"\n ```\n\n Another workaround is to [start the Cloud SQL Auth Proxy using Unix sockets](/sql/docs/postgres/connect-auth-proxy#start-proxy).\n This turns off PostgreSQL SSL encryption and lets the Cloud SQL Auth Proxy do the SSL\n encryption instead.\n\n### Administrative issues\n\n- Only one long-running Cloud SQL import or export operation can run at a time on an instance. When you start an operation, make sure you don't need to perform other operations on the instance. Also, when you start the operation, you can [cancel it](/sql/docs/postgres/import-export/cancel-import-export).\n\n PostgreSQL imports data in a single transaction. Therefore, if you cancel the import operation, then Cloud SQL doesn't persist data from the import.\n\n### Issues with importing and exporting data\n\n- If your Cloud SQL instance uses PostgreSQL 17, but your databases use PostgreSQL 16 and earlier, then you can't use Cloud SQL to import these databases into your instance. To do this, use [Database Migration Service](/database-migration/docs).\n\n- If you use Database Migration Service to import a PostgreSQL 17 database into Cloud SQL, then it's imported as a PostgreSQL 16 database.\n\n- For PostgreSQL versions 15 and later, if the target database is created from `template0`, then importing data might fail and you might see a `permission denied for schema public` error message. To resolve this issue, provide public schema privileges to the `cloudsqlsuperuser` user by running the `GRANT ALL ON SCHEMA public TO cloudsqlsuperuser` SQL command.\n\n- Exporting many large objects cause instance to become unresponsive\n\n If your database contains many large objects (blobs), exporting the database\n can consume so much memory that the instance becomes unresponsive. This can\n happen even if the blobs are empty.\n\n \u003cbr /\u003e\n\n- Cloud SQL doesn't support customized tablespaces but it does support data migration from customized tablespaces to the default tablespace, `pg_default`, in destination instance. For example, if you own a tablespace named `dbspace` is located at `/home/data`, after migration, all the data inside `dbspace` is migrated to the `pg_default`. But Cloud SQL will not create a tablespace named \"dbspace\" on its disk.\n\n- If you're trying to import and export data from a large database (for example,\n a database that has 500 GB of data or greater), then the import and export\n operations might take a long time to complete. In addition, other operations\n (for example, the backup operation) aren't available for you to perform\n while the import or export is occurring. A potential option to improve the\n performance of the import and export process is to [restore a previous backup](/sql/docs/postgres/backup-recovery/restoring#projectid) using `gcloud`\n or the API.\n\n\u003c!-- --\u003e\n\n- Cloud Storage supports a [maximum single-object size up five terabytes](/storage-transfer/docs/known-limitations-transfer#object-limit). If you have databases larger than 5TB, the export operation to Cloud Storage fails. In this case, you need to break down your export files into smaller segments.\n\n### Transaction logs and disk growth\n\nLogs are purged once daily, not continuously. When the number of days of log\nretention is configured to be the same as the number of backups, a day of\nlogging might be lost, depending on when the backup occurs. For example, setting\nlog retention to seven days and backup retention to seven backups means that\nbetween six and seven days of logs will be retained.\n\nWe recommend setting the number of backups to at least one more than the days of\nlog retention to guarantee a minimum of specified days of log retention.\n| **Note:** Replica instances see a storage increase when replication is suspended and then resumed later. The increase is caused when the primary instance sends the replica the transaction logs for the period of time when replication was suspended. The transaction logs updates the replica to the current state of the primary instance.\n\n\u003cbr /\u003e\n\n### Issues related to Cloud Monitoring or Cloud Logging\n\nInstances with the following region names are displayed incorrectly in certain\ncontexts, as follows:\n\n- `us-central1` is displayed as `us-central`\n- `europe-west1` is displayed as `europe`\n- `asia-east1` is displayed as `asia`\n\nThis issue occurs in the following contexts:\n\n- Alerting in Cloud Monitoring\n- Metrics Explorer\n- Cloud Logging\n\nYou can mitigate the issue for Alerting in Cloud Monitoring, and for Metrics\nExplorer, by using\n[Resource metadata labels](https://cloud.google.com/monitoring/api/v3/metric-model#meta-labels).\nUse the system metadata label `region` instead of the\n[cloudsql_database](https://cloud.google.com/monitoring/api/resources#tag_cloudsql_database)\nmonitored resource label `region`.\n\n### Issue related to deleting a PostgreSQL database\n\nWhen you delete a database created in Google Cloud console using your\n`psql` client, you may encounter the following error: \n\n ERROR: must be owner of database [DATABASE_NAME]\n\nThis is a permission error since the owner of a database created using a\n`psql` client doesn't have Cloud SQL `superuser` attributes.\nDatabases created using the Google Cloud console are owned by\n`cloudsqlsuperuser` and databases created using a `psql` client are owned\nby users connected to that database. Since Cloud SQL is a managed service,\ncustomers cannot create or have access to users with `superuser` attributes.\nFor more information, see\n[Superuser restrictions and privileges](/sql/docs/postgres/users#superuser-restrictions-and-privileges).\n\nDue to this limitation, databases created using the Google Cloud console can\nonly be deleted using the Google Cloud console, and databases created using\na `psql` client can only be deleted by connecting as the owner of the\ndatabase.\n\nTo find the owner of a database, use the following command: \n\n SELECT d.datname as Name,\n pg_catalog.pg_get_userbyid(d.datdba) as Owner\n FROM pg_catalog.pg_database d\n WHERE d.datname = '\u003cvar translate=\"no\"\u003eDATABASE_NAME\u003c/var\u003e';\n\nReplace the following:\n\n- \u003cvar translate=\"no\"\u003eDATABASE_NAME\u003c/var\u003e: the name of the database that you want to find owner information for.\n\nIf the owner of your database is `cloudsqlsuperuser`, then use\nGoogle Cloud console to delete your database. If the owner of the database\nis a `psql` client database user, then connect as the database owner and\nrun the `DROP DATABASE` command."]]
