Halaman ini berisi tips untuk memecahkan masalah Cloud SQL untuk mesin database yang didukung. Beberapa tips ini hanya berlaku untuk mesin database tertentu, sementara tips lainnya berlaku untuk semua mesin.
ntuk tips pemecahan masalah mesin database tertentu, lihat halaman individualnya:
Periksa apakah pertanyaan atau masalah Anda telah ditangani di salah satu halaman berikut:
Topik dalam halaman ini meliputi:
- Backup dan pemulihan
- Cloning
- Konektivitas
- Membuat instance
- Eksternal utama
- Eksternal replika
- Flag
- Ketersediaan tinggi
- Mengimpor dan mengekspor
- Mengintegrasikan dengan Vertex AI
- Server tertaut
- Logging
- Mengelola instance
- Private Service Connect
- Replikasi
Pencadangan dan pemulihan
Masalah | Pemecahan masalah |
---|---|
Anda tidak dapat melihat status operasi saat ini. | Konsol Google Cloud hanya melaporkan keberhasilan atau kegagalan ketika operasi
sudah selesai.
dan tidak didesain untuk menampilkan peringatan atau update lainnya.
Jalankan
perintah |
Anda ingin tahu siapa yang melakukan operasi pencadangan on demand. | Antarmuka pengguna tidak menunjukkan pengguna yang memulai operasi.
Lihat di log dan filter berdasarkan teks untuk menemukan pengguna. Anda mungkin perlu menggunakan log audit untuk informasi pribadi. File log yang relevan meliputi:
|
Setelah instance dihapus, Anda tidak dapat membuat cadangan instance tersebut. | Setelah instance dihapus permanen, pemulihan data tidak dapat dilakukan. Namun, jika instance dipulihkan, cadangannya juga akan dipulihkan. Untuk informasi selengkapnya terkait pemulihan instance yang dihapus, lihat Cadangan pemulihan. Jika Anda telah melakukan operasi ekspor, buat instance baru, lalu lakukan operasi impor untuk membuat ulang database. Ekspor ditulis ke Cloud Storage dan impor dibaca dari sana. |
Pencadangan otomatis terhenti selama berjam-jam dan tidak dapat dibatalkan. | Pencadangan dapat memakan waktu lama bergantung pada ukuran database.
Jika benar-benar perlu membatalkan operasi, Anda dapat meminta
dukungan pelanggan untuk |
Operasi pemulihan bisa gagal jika satu atau beberapa pengguna yang dirujuk dalam file dump SQL tidak ada. | Sebelum memulihkan dump SQL, semua pengguna database yang memiliki objek atau
diberi izin pada objek dalam database yang diekspor harus ada dalam
database target. Jika tidak, operasi pemulihan akan gagal membuat ulang
objek dengan kepemilikan atau izin asli.
Buat pengguna database sebelum memulihkan dump SQL. |
Anda ingin meningkatkan jumlah hari untuk menyimpan pencadangan otomatis dari tujuh hari menjadi 30 hari, atau lebih. | Anda dapat
mengonfigurasi jumlah cadangan otomatis yang akan dipertahankan. Pencadangan otomatis dipangkas
secara teratur berdasarkan nilai retensi yang dikonfigurasi. Sayangnya, ini berarti
cadangan yang saat ini terlihat adalah satu-satunya cadangan otomatis yang dapat Anda pulihkan.
Untuk menyimpan cadangan tanpa batas waktu, Anda dapat membuat cadangan on demand, karena cadangan tersebut tidak dihapus dengan cara yang sama seperti cadangan otomatis. Pencadangan sesuai permintaan akan tetap ada tanpa batas waktu. Artinya, pencadangan tersebut akan tetap ada hingga dihapus atau instance tempatnya dihapus. Karena jenis cadangan tersebut tidak dihapus secara otomatis, hal ini dapat mempengaruhi penagihan. |
Pencadangan otomatis gagal dan Anda tidak menerima notifikasi email. | Agar Cloud SQL memberi tahu Anda tentang status pencadangan, konfigurasi pemberitahuan berbasis log. |
Instance berulang kali mengalami kegagalan karena terus-menerus beralih antara status kegagalan dan pemulihan cadangan. Upaya untuk terhubung dan menggunakan database setelah pemulihan gagal. |
Hal-hal yang perlu dicoba:
|
Anda mendapati bahwa data Anda hilang saat melakukan operasi pencadangan/pemulihan. | Tabel dibuat dalam keadaan tidak di-log. Contoh:
Tabel berikut tidak termasuk dalam pemulihan dari cadangan:
Solusinya adalah menghindari penggunaan tabel yang tidak dicatat jika Anda ingin memulihkan
tabel tersebut melalui cadangan. Jika melakukan pemulihan dari database yang sudah
memiliki tabel yang belum dicatat ke dalam log, Anda dapat membuang database tersebut ke sebuah file, dan memuat ulang
data tersebut setelah mengubah file dump ke |
Clone
Masalah | Pemecahan masalah |
---|---|
Cloning gagal dengan error constraints/sql.restrictAuthorizedNetworks . |
Operasi cloning diblokir oleh konfigurasi Authorized Networks .
Authorized Networks dikonfigurasi untuk alamat IP publik di bagian Konektivitas
pada konsol Google Cloud, dan cloning tidak diizinkan karena
pertimbangan keamanan.
Hapus semua entri |
Pesan error: Failed to create subnetwork. Couldn't find free
blocks in allocated IP ranges. Please allocate new ranges for this service
provider. Help Token: [help-token-id]. |
Anda mencoba menggunakan Konsol Google Cloud untuk meng-clone instance dengan alamat IP pribadi, tetapi Anda tidak menentukan rentang IP yang dialokasikan yang ingin digunakan dan instance sumber tidak dibuat dengan rentang yang ditentukan. Akibatnya, instance yang di-clone dibuat dalam rentang acak. Gunakan |
Konektivitas
Masalah | Pemecahan masalah |
---|---|
Aborted connection . |
Masalahnya mungkin:
Aplikasi harus menoleransi kegagalan jaringan dan mengikuti praktik terbaik, seperti penggabungan koneksi dan percobaan ulang. Sebagian besar penyatuan koneksi akan menangkap error ini jika memungkinkan. Jika tidak, aplikasi akan mencoba ulang atau gagal dengan sendirinya. Untuk percobaan ulang koneksi, sebaiknya gunakan metode berikut:
Menggabungkan metode ini membantu mengurangi throttling. |
FATAL: database 'user' does not exist . |
gcloud sql connect --user hanya berfungsi dengan pengguna
postgres default.
Terhubung dengan pengguna default, lalu ubah pengguna. |
Anda ingin mengetahui siapa yang terhubung. | Login ke database dan jalankan perintah berikut:
SELECT datname, usename, application_name as appname, client_addr, state, now() - backend_start as conn_age, now() - state_change as last_activity_age FROM pg_stat_activity WHERE backend_type = 'client backend' ORDER BY 6 DESC LIMIT 20 |
Membuat instance
Masalah | Pemecahan masalah |
---|---|
Pesan error: Failed to create subnetwork. Router status is
temporarily unavailable. Please try again later. Help Token:
[token-ID] . |
Coba buat instance Cloud SQL lagi. |
Pesan error: Failed to create subnetwork. Required
'compute.projects.get' permission for PROJECT_ID . |
Saat Anda membuat instance menggunakan alamat IP Pribadi, akun layanan akan dibuat tepat waktu menggunakan Service Networking API. Jika Anda baru saja mengaktifkan Service Networking API, akun layanan mungkin tidak dibuat dan pembuatan instance akan gagal. Dalam hal ini, Anda harus menunggu akun layanan diterapkan di seluruh sistem atau menambahkannya secara manual dengan izin yang diperlukan. |
Ekspor
Masalah | Pemecahan masalah |
---|---|
HTTP Error 409: Operation failed because another operation was
already in progress. |
Sudah ada operasi yang tertunda untuk instance Anda. Hanya satu operasi yang diizinkan pada satu waktu. Coba permintaan Anda setelah operasi saat ini selesai. |
HTTP Error 403: The service account does not have the required
permissions for the bucket. |
Pastikan bucket ada dan akun layanan untuk instance
Cloud SQL (yang melakukan ekspor) memiliki
peran Storage Object Creator
(roles/storage.objectCreator ) untuk memungkinkan ekspor ke bucket. Lihat
Peran IAM untuk Cloud Storage. |
Ekspor CSV berhasil, tetapi ekspor SQL gagal. | Format CSV dan SQL melakukan ekspor secara berbeda. Format SQL mengekspor
seluruh database, dan mungkin memerlukan waktu lebih lama untuk diselesaikan. Format CSV memungkinkan
Anda menentukan elemen database yang akan disertakan dalam ekspor.
Gunakan ekspor CSV untuk mengekspor hal yang Anda butuhkan saja. |
Ekspor memerlukan waktu terlalu lama. | Cloud SQL tidak mendukung operasi sinkron serentak.
Gunakan pengurangan beban ekspor. Pada level yang tinggi, dalam pengurangan beban ekspor, bukannya mengeluarkan ekspor pada instance sumber, melainkan Cloud SQL menjalankan instance pengurangan beban untuk melakukan ekspor. Pengurangan beban ekspor memiliki beberapa keunggulan, termasuk peningkatan performa pada instance sumber dan pemblokiran operasi administratif saat ekspor sedang berjalan. Dengan pengurangan beban ekspor, total latensi dapat meningkat sebesar jumlah waktu yang diperlukan untuk memunculkan instance pengurangan beban. Umumnya, untuk ekspor yang berukuran wajar, latensi tidak signifikan. Namun, jika ekspor Anda cukup kecil, Anda mungkin akan melihat peningkatan latensi. |
Error saat Membuat Ekstensi. | File dump berisi referensi ke ekstensi yang tidak didukung. |
Terjadi error saat menggunakan pg_dumpall . |
Menggunakan pg_dumpall utilitas dengan --global flag
memerlukan
peran superuser, tapi
peran ini tidak didukung di Cloud SQL untuk PostgreSQL. Untuk mencegah terjadinya error
saat melakukan operasi ekspor yang menyertakan nama pengguna, sebaiknya gunakan juga flag
--no-role-passwords .
|
Waktu operasi ekspor habis sebelum mengekspor apa pun, dan Anda melihat
pesan error Could not receive data from client: Connection reset
by peer. |
Jika Cloud Storage tidak menerima data apa pun dalam
jangka waktu tertentu, biasanya sekitar tujuh menit, maka koneksi akan direset. Ada
kemungkinan bahwa kueri ekspor awal memakan waktu terlalu lama untuk dijalankan.
Lakukan ekspor manual menggunakan
alat |
Anda ingin ekspor dilakukan secara otomatis. | Cloud SQL tidak menyediakan cara untuk mengotomatiskan ekspor.
Anda dapat mem-build sistem ekspor otomatis Anda sendiri menggunakan produk Google Cloud seperti Cloud Scheduler, Pub/Sub, dan fungsi Cloud Run, mirip dengan artikel ini tentang mengotomatiskan cadangan. |
Eksternal utama
Masalah | Pemecahan masalah |
---|---|
Lost connection to MySQL server during query when dumping table . |
Sumbernya mungkin tidak tersedia, atau file dump berisi paket
yang terlalu besar.
Pastikan kabel primer eksternal tersedia untuk terhubung. Anda juga dapat mengubah nilai tanda net_read_timeout dan net_write_timeout pada instance sumber untuk menghentikan error. Untuk informasi selengkapnya tentang nilai yang diizinkan untuk tanda ini, lihat Mengonfigurasi tanda database. Untuk mempelajari lebih lanjut cara menggunakan tanda |
Migrasi data awal berhasil, tetapi tidak ada data yang direplikasi. | Salah satu kemungkinan penyebabnya adalah database sumber Anda telah menentukan
flag replikasi yang menyebabkan beberapa atau semua perubahan database
tidak direplikasi.
Pastikan tanda replikasi seperti Jalankan perintah |
Migrasi data awal berhasil tetapi replikasi data berhenti berfungsi setelah beberapa saat. | Hal-hal yang sebaiknya dicoba:
|
mysqld check failed: data disk is full . |
Disk data instance replika penuh.
Tingkatkan ukuran disk instance replika. Anda dapat meningkatkan ukuran disk secara manual atau mengaktifkan peningkatan penyimpanan otomatis. |
Eksternal replika
Masalah | Pemecahan masalah |
---|---|
Pesan error: The slave is connecting ... master has purged
binary logs containing GTIDs that the slave requires . |
Instance Cloud SQL utama memiliki pencadangan otomatis dan log biner,
serta pemulihan point-in-time diaktifkan, sehingga harus memiliki cukup log
agar replika dapat mengejar ketertinggalan. Namun, dalam kasus ini, meskipun
log biner ada, replika tidak tahu dari baris mana harus mulai membaca.
Buat file dump baru menggunakan setelan flag yang benar, dan konfigurasi replika eksternal menggunakan file tersebut
|
Flag
Masalah | Pemecahan masalah |
---|
Ketersediaan tinggi
Masalah | Pemecahan masalah |
---|---|
Anda tidak dapat menemukan metrik untuk failover manual. | Hanya failover otomatis yang masuk ke metrik. |
Penggunaan resource instance Cloud SQL (CPU dan RAM) mendekati 100%, sehingga instance ketersediaan tinggi mengalami gangguan. | Ukuran mesin instance terlalu kecil untuk beban tersebut.
Edit instance untuk mengupgrade ke ukuran mesin yang lebih besar untuk mendapatkan lebih banyak CPU dan memori. |
Impor
Masalah | Pemecahan masalah |
---|---|
HTTP Error 409: Operation failed because another operation was already in progress . |
Sudah ada operasi yang tertunda untuk instance Anda. Hanya satu operasi yang diizinkan pada satu waktu. Coba permintaan Anda setelah operasi saat ini selesai. |
Operasi impor memakan waktu terlalu lama. | Terlalu banyak koneksi aktif dapat mengganggu operasi impor.
Tutup operasi yang tidak digunakan. Periksa penggunaan CPU dan memori instance Cloud SQL untuk memastikan ada banyak resource yang tersedia. Cara terbaik untuk memastikan resource maksimum untuk impor adalah dengan memulai ulang instance sebelum memulai operasi. Mulai ulang:
|
Operasi impor bisa gagal ketika satu atau beberapa pengguna yang dirujuk dalam file dump tidak ada. | Sebelum mengimpor file dump, semua pengguna database yang memiliki objek atau
diberi izin pada objek dalam database yang diekspor harus ada di
database target. Jika tidak, operasi impor akan gagal membuat ulang
objek dengan kepemilikan atau izin asli.
Buat pengguna database sebelum mengimpor. |
Operasi impor gagal dengan error bahwa tabel tidak ada. | Tabel dapat memiliki dependensi kunci asing di tabel lain, dan bergantung pada
urutan operasi, satu atau beberapa tabel tersebut mungkin belum ada
selama operasi impor.
Hal-hal yang sebaiknya dicoba: Tambahkan baris berikut di awal file dump: SET FOREIGN_KEY_CHECKS=0; Selain itu, tambahkan baris berikut di akhir file dump: SET FOREIGN_KEY_CHECKS=1; Setelan ini menonaktifkan pemeriksaan integritas data saat operasi impor sedang berlangsung, dan mengaktifkannya kembali setelah data dimuat. Hal ini tidak memengaruhi integritas data di database, karena data sudah divalidasi selama pembuatan file dump. |
Mengintegrasikan dengan Vertex AI
Masalah | Pemecahan masalah |
---|---|
Pesan error: Google ML integration API is supported only on Postgres version 12 or above. |
Untuk mengaktifkan integrasi Vertex AI di Cloud SQL, Anda harus memiliki database Cloud SQL untuk PostgreSQL, versi 12 atau yang lebih baru. Untuk mengupgrade database ke versi ini, lihat Mengupgrade versi utama database yang diterapkan. |
Pesan error: Google ML Integration API is not supported on shared core instance. Please upsize your machine type. |
Jika memilih core bersama untuk jenis mesin instance, Anda tidak dapat mengaktifkan integrasi Vertex AI di Cloud SQL. Upgrade jenis mesin Anda ke core khusus. Untuk mengetahui informasi selengkapnya, lihat Jenis Mesin. |
Pesan error: Google ML Integration is unsupported for this maintenance version. Please follow https://cloud.google.com/sql/docs/postgres/self-service-maintenance to update the maintenance version of the instance. |
Untuk mengaktifkan integrasi Vertex AI di Cloud SQL, versi pemeliharaan instance Anda harus R20240130 atau yang lebih baru. Untuk mengupgrade instance ke versi ini, lihat Pemeliharaan mandiri. |
Pesan error: Cannot invoke ml_predict_row if 'cloudsql.enable_google_ml_integration' is off. |
Flag database cloudsql.enable_google_ml_integration dinonaktifkan. Cloud SQL tidak dapat berintegrasi dengan Vertex AI.Untuk mengaktifkan flag ini, gunakan perintah gcloud sql instances patch :gcloud sql instances patch INSTANCE_NAME --database-flags cloudsql.enable_google_ml_integration=on Ganti INSTANCE_NAME dengan nama instance Cloud SQL utama. |
Pesan error: Failed to connect to remote host: Connection refused. |
Integrasi antara Cloud SQL dan Vertex AI tidak diaktifkan. Untuk mengaktifkan integrasi ini, gunakan perintah gcloud sql instances patch :gcloud sql instances patch INSTANCE_NAME Ganti INSTANCE_NAME dengan nama instance Cloud SQL utama. |
Pesan error: Vertex AI API has not been used in project PROJECT_ID before or it is disabled. Enable it by visiting /apis/api/aiplatform.googleapis.com/overview?project=PROJECT_ID then retry. |
Vertex AI API tidak diaktifkan. Untuk mengetahui informasi selengkapnya tentang cara mengaktifkan API ini, lihat Mengaktifkan integrasi database dengan Vertex AI. |
Pesan error: Permission 'aiplatform.endpoints.predict' denied on resource. |
Izin Vertex AI tidak ditambahkan ke akun layanan Cloud SQL untuk project tempat instance Cloud SQL berada. Untuk mengetahui informasi selengkapnya tentang cara menambahkan izin ini ke akun layanan, lihat Mengaktifkan integrasi database dengan Vertex AI. |
Pesan error: Publisher Model `projects/PROJECT_ID/locations/REGION_NAME/publishers/google/models/MODEL_NAME` not found. |
Model machine learning atau LLM tidak ada di Vertex AI. |
Pesan error: Resource exhausted: grpc: received message larger than max. |
Ukuran permintaan yang diteruskan Cloud SQL ke Vertex AI melebihi batas gRPC sebesar 4 MB per permintaan. |
Pesan error: Cloud SQL attempts to send a request to Vertex AI. However, the instance is in the %s region, but the Vertex AI endpoint is in the %s region. Make sure the instance and endpoint are in the same region. |
Cloud SQL mencoba mengirim permintaan ke Vertex AI. Namun, instance berada di satu region, tetapi endpoint Vertex AI berada di region yang berbeda. Untuk mengatasi masalah ini, instance dan endpoint harus berada di region yang sama. |
Pesan error: The Vertex AI endpoint isn't formatted properly. |
Endpoint Vertex AI tidak diformat dengan benar. Untuk mengetahui informasi selengkapnya, lihat Menggunakan endpoint pribadi untuk prediksi online. |
Pesan error: Quota exceeded for aiplatform.googleapis.com/online_prediction_requests_per_base_model with base model: textembedding-gecko. |
Jumlah permintaan yang diteruskan Cloud SQL ke Vertex AI melebihi batas 1.500 permintaan per menit per region per model per project. |
Server tertaut
Pesan error | Pemecahan masalah |
---|---|
Msg 7411, Level 16, State 1, Line 25
|
Opsi DataAccess dinonaktifkan. Jalankan
perintah berikut untuk mengaktifkan akses data:EXEC sp_serveroption @server='LINKED_SERVER_NAME', @optname='data access', @optvalue='TRUE' Ganti LINKED_SERVER_NAME dengan nama server tertaut. |
Access to the remote server is denied because no
login-mapping exists. (Microsoft SQL Server, Error: 7416)
|
Jika mengalami masalah ini saat membuat koneksi
terenkripsi, Anda perlu mencoba cara lain yang menunjukkan ID pengguna saat
sedang mengakses server tertaut. Untuk melakukannya, jalankan perintah berikut:
EXEC master.dbo.sp_addlinkedserver @server = N'LINKED_SERVER_NAME', @srvproduct= N'', @provider= N'SQLNCLI', @datasrc= N'TARGET_SERVER_ID', @provstr= N'Encrypt=yes;TrustServerCertificate=yes;User ID=USER_ID' Ganti kode berikut:
|
Logging
Masalah | Pemecahan masalah |
---|---|
Log audit tidak ditemukan. | Log Akses Data hanya ditulis jika operasi merupakan panggilan API berbasis pengguna yang diautentikasi yang membuat, mengubah, atau membaca data yang dibuat pengguna, atau jika operasi mengakses file konfigurasi atau metadata resource. |
Informasi operasi tidak ditemukan dalam log. | Anda ingin menemukan informasi selengkapnya tentang suatu operasi.
Misalnya, pengguna telah dihapus tetapi Anda tidak dapat mengetahui siapa yang melakukannya. Log menunjukkan operasi dimulai tetapi tidak memberikan informasi lebih lanjut. Anda harus mengaktifkan logging audit agar informasi identitas pribadi (PII) yang mendetail seperti ini dapat dicatat ke dalam log. |
Beberapa log difilter dari log error.log
instance Cloud SQL untuk SQL Server.
|
Log yang difilter menyertakan
log AD tanpa stempel waktu, dan menyertakan:
Login failed for user 'x'. Reason: Token-based server access
validation failed with an infrastructure error. Login lacks connect endpoint
permission. [CLIENT: 127.0.0.1] . Log ini difilter karena
berpotensi menyebabkan kebingungan.
|
Logging menggunakan banyak kapasitas disk. | Ada tiga jenis file log yang menggunakan kapasitas disk: log pengulangan,
log umum, dan log biner.
Hubungkan ke database dan jalankan perintah berikut untuk mengetahui detail tentang setiap jenis: SHOW VARIABLES LIKE 'innodb_log_file%'; SELECT ROUND(SUM(LENGTH(argument)/POW(1024,2),2) AS GB from mysql.general_log; SHOW BINARY LOGS; |
File log sulit dibaca. | Anda lebih suka melihat log sebagai json atau teks.Anda dapat menggunakan
perintah
gcloud logging read
bersama dengan perintah pasca-pemrosesan linux untuk mendownload log.
Untuk mendownload log sebagai JSON: gcloud logging read \ "resource.type=cloudsql_database \ AND logName=projects/PROJECT_ID \ /logs/cloudsql.googleapis.com%2FLOG_NAME" \ --format json \ --project=PROJECT_ID \ --freshness="1d" \ > downloaded-log.json Untuk mendownload log sebagai TEXT: gcloud logging read \ "resource.type=cloudsql_database \ AND logName=projects/PROJECT_ID \ /logs/cloudsql.googleapis.com%2FLOG_NAME" \ --format json \ --project=PROJECT_ID \ --freshness="1d"| jq -rnc --stream 'fromstream(1|truncate_stream(inputs)) \ | .textPayload' \ --order=asc > downloaded-log.txt |
Log kueri tidak ditemukan di log PostgreSQL. | Anda perlu mengaktifkan flag pgaudit.
|
Mengelola instance
Masalah | Pemecahan masalah |
---|---|
Performa lambat setelah memulai ulang MySQL. | Cloud SQL memungkinkan penyimpanan data ke cache dalam kumpulan buffer InnoDB. Namun, setelah mulai ulang, cache ini akan selalu kosong, dan semua operasi baca memerlukan perjalanan dua arah ke backend untuk mendapatkan data. Akibatnya, kueri bisa lebih lambat dari yang diharapkan hingga cache terisi. |
Pemulihan error lambat. | general_log yang besar mungkin telah terakumulasi.
Anda dapat mengurangi waktu pemulihan error dengan mencegah
general_log yang besar terakumulasi. Jika Anda mengaktifkan general_log , potong tabel dan hanya aktifkan general_log untuk
jangka waktu yang singkat.
Anda dapat mengetahui ukuran log umum dengan terhubung ke database dan menjalankan kueri ini: SELECT ROUND(SUM(LENGTH(argument)/POW(1024,2)),2) from mysql.general_log;
|
Anda ingin mengetahui apa saja yang menggunakan ruang penyimpanan. | Misalnya, Anda melihat bahwa database hanya menggunakan tiga GB, tetapi
menyatakan bahwa penyimpanan sedang menggunakan 14 GB. Sebagian besar ruang yang tidak digunakan oleh tabel
digunakan oleh log biner dan/atau file sementara.
Hal-hal yang sebaiknya dicoba:
|
Kueri diblokir. | Kueri dapat mengunci database MySQL sehingga menyebabkan semua
kueri berikutnya mengalami pemblokiran/waktu tunggu.
Hubungkan ke database dan jalankan kueri ini:
Item pertama dalam daftar mungkin item yang memegang kunci, yang ditunggu oleh item berikutnya. Kueri |
Anda tidak dapat menghapus log biner secara manual. | Log biner tidak dapat dihapus secara manual. Log biner akan otomatis dihapus dengan pencadangan otomatis terkait, yang biasanya terjadi setelah sekitar tujuh hari. |
Anda ingin mencari informasi tentang file sementara. | File bernama ibtmp1 digunakan untuk menyimpan data
sementara. File ini direset setelah database dimulai ulang. Untuk menemukan informasi tentang
penggunaan file sementara, hubungkan ke database dan
jalankan kueri berikut:
|
Anda ingin mengetahui tentang ukuran tabel. | Informasi ini tersedia di database.
Hubungkan ke database dan jalankan kueri berikut:
|
mysqld mendapat sinyal 11. | Coba faktorkan ulang kueri agar tidak membuat terlalu banyak koneksi.
Jika cara ini tidak menyelesaikan masalah, hubungi dukungan pelanggan.
Sinyal 11 biasanya mewakili masalah software MySQL.
|
InnoDB: page_cleaner: 1000ms intended loop took 5215ms. The
settings might not be optimal. |
Pembersih halaman tidak dapat mengikuti tingkat perubahan pada instance.
Sekali per detik, pembersih halaman akan memindai kumpulan buffer untuk mencari halaman kotor yang akan
dikosongkan dari kumpulan buffer ke disk. Peringatan yang Anda lihat menunjukkan bahwa ada banyak
halaman kotor yang harus dikosongkan, dan perlu waktu lebih dari satu detik untuk mengosongkan
satu batch halaman tersebut ke disk.
Lakukan sharding pada instance jika memungkinkan. Menggunakan banyak instance Cloud SQL yang lebih kecil akan lebih baik daripada satu instance besar. |
Anda ingin mengetahui kueri apa yang sedang berjalan. | Hubungkan ke database dan jalankan kueri berikut:
|
Anda ingin mengetahui unit apa yang digunakan untuk kolom tertentu. | Hubungkan ke database dan jalankan kueri berikut
(menggunakan FIELD_NAME Anda sendiri):
|
Anda ingin menemukan nilai saat ini dari setelan database. | Hubungkan ke database dan jalankan kueri berikut
(menggunakan SETTING_NAME Anda sendiri):
Jalankan |
Anda ingin menghentikan proses latar belakang yang diblokir. | Pengguna harus memiliki peran pg_signal_backend .
Jalankan perintah berikut:
|
Instance hampir mencapai 100% pemakaian ID transaksi. | Pemantauan internal Anda memperingatkan bahwa instance hampir mencapai 100%
pemakaian ID transaksi. Anda ingin menghindari wraparound transaksi
yang dapat memblokir penulisan.
Tugas autovacuum mungkin diblokir, atau mungkin tidak mengklaim kembali ID transaksi dengan cukup cepat untuk mengimbangi workload. Untuk menghindari pemadaman layanan karena masalah wraparound transaksi, Anda dapat meninjau tips layanan mandiri ini untuk menangani wraparound TXID. Untuk saran penyesuaian umum, lihat Mengoptimalkan, memantau, dan memecahkan masalah operasi vacuum di PostgreSQL. |
Penyimpanan sementara meningkatkan penyimpanan otomatis. | Penyimpanan otomatis diaktifkan.
Proses mulai ulang akan menghapus file sementara, tetapi tidak mengurangi penyimpanan. Hanya dukungan pelanggan yang dapat mereset ukuran instance. |
Data sedang dihapus secara otomatis. | Sebuah skrip kemungkinan besar sedang berjalan di suatu tempat di lingkungan Anda.
Periksa log di sekitar waktu penghapusan dan periksa apakah ada skrip berbahaya yang berjalan dari dasbor atau proses otomatis lainnya. |
Instance tidak dapat dihapus. | Anda mungkin melihat pesan error ERROR: (gcloud.sql.instances.delete) HTTP Error
409: The instance or operation is not in an appropriate state to handle the
request , atau instance mungkin
memiliki status flag INSTANCE_RISKY_FLAG_CONFIG .
Beberapa kemungkinan penjelasan meliputi:
|
Instance macet karena ukuran data sementara yang besar. | Sistem dapat membuat banyak tabel sementara sekaligus, bergantung pada
kueri dan beban.
Sayangnya, Anda tidak dapat mengecilkan file Salah satu opsi mitigasi adalah membuat tabel sementara dengan
|
Terjadi error fatal selama upgrade berlangsung. | Log mungkin menampilkan lebih banyak data. Meskipun begitu, dukungan pelanggan mungkin diperlukan untuk membuat ulang instance secara paksa. |
Instance macet saat memulai ulang setelah kehabisan kapasitas disk. | Kemampuan peningkatan penyimpanan otomatis tidak diaktifkan.
Jika penyimpanan instance habis, dan kemampuan peningkatan penyimpanan otomatis tidak diaktifkan, instance Anda akan offline. Untuk menghindari masalah ini, Anda dapat mengedit instance untuk mengaktifkan peningkatan penyimpanan otomatis. |
Instance utama lokal Anda terhambat. | Google Cloud tidak dapat membantu instance yang tidak ada di Cloud SQL. |
Penonaktifan berjalan lambat saat memulai ulang. | Saat suatu instance dimatikan, semua koneksi yang belum
selesai dan tidak berakhir dalam 60 detik akan mengakibatkan proses penonaktifan berantakan.
Dengan memiliki koneksi yang dapat bertahan kurang dari 60 detik, sebagian besar penonaktifan yang berantakan dapat dihindari, termasuk koneksi dari command prompt database. Jika Anda membiarkan koneksi ini terbuka selama berjam-jam atau bahkan berhari-hari, maka proses penonaktifan bisa jadi berantakan. |
Pengguna tidak dapat dihapus. | Pengguna tersebut mungkin memiliki objek dalam database yang bergantung padanya. Anda
harus menghapus objek tersebut atau mengalihkannya ke pengguna lain.
Cari tahu objek mana yang bergantung pada pengguna tersebut, lalu hapus atau alihkan objek tersebut ke pengguna yang berbeda. |
Kueri tertentu berjalan lambat. | Kueri dapat berjalan lambat karena berbagai alasan, sebagian besar disebabkan oleh aspek database
tertentu. Salah satu alasan yang dapat melibatkan Cloud SQL adalah latensi jaringan,
yaitu saat resource sumber (penulis atau pembaca) dan resource tujuan
(Cloud SQL) berada di region yang berbeda.
Lihat tips performa umum secara khusus. Untuk penyisipan, update, atau penghapusan database yang berjalan lambat, pertimbangkan tindakan berikut:
Untuk mengurangi latensi, sebaiknya tempatkan resource sumber dan tujuan di region yang sama. |
Memori yang habis terindikasi, tetapi diagram pemantauan tidak menampilkannya. | Instance dapat gagal dan melaporkan Out of memory , tetapi
Konsol Google Cloud atau diagram Cloud Monitoring tampaknya menunjukkan bahwa masih ada
memori yang tersisa.
Ada faktor lain selain workload Anda yang dapat memengaruhi penggunaan memori, seperti jumlah koneksi aktif dan proses overhead internal. Meskipun begitu, hal ini tidak selalu tercantum dalam diagram pemantauan. Pastikan instance memiliki overhead yang cukup untuk memperhitungkan workload Anda serta beberapa overhead tambahan. |
Memulihkan instance yang telah dihapus. | Semua data pada instance, termasuk cadangan, akan hilang secara permanen saat
instance tersebut dihapus.
Untuk menyimpan data Anda, sebaiknya ekspor data ke Cloud Storage sebelum menghapus instance. Peran Admin Cloud SQL mencakup izin untuk menghapus instance. Untuk mencegah penghapusan yang tidak disengaja, berikan peran ini hanya jika diperlukan. |
Anda ingin mengganti nama instance Cloud SQL yang ada. | Cloud SQL tidak mendukung penggantian nama instance yang sudah ada.
Namun, ada cara lain untuk mencapai tujuan tersebut, yaitu dengan membuat instance baru.
Dalam kedua kasus seperti itu, Anda dapat menghapus instance lama setelah operasi selesai. Sebaiknya gunakan rute clone karena tidak akan berdampak pada performa dan tidak mengharuskan Anda mengulang langkah setelan konfigurasi instance apa pun seperti flag, jenis mesin, ukuran penyimpanan, dan memori. |
Terjadi error saat menghapus instance. | Jika perlindungan penghapusan diaktifkan, konfirmasi rencana Anda untuk menghapus instance tersebut. Selanjutnya, nonaktifkan perlindungan penghapusan sebelum menghapus instance. |
Private Service Connect
Masalah | Pemecahan masalah |
---|---|
Lampiran layanan instance tidak menerima endpoint Private Service Connect. |
|
Replikasi
Masalah | Pemecahan masalah |
---|---|
Replika baca tidak mulai direplikasi pada saat pembuatan. | Mungkin ada error yang lebih spesifik di file log. Periksa log di Cloud Logging untuk menemukan error yang sebenarnya. |
Tidak dapat membuat replika baca - error invalidFlagValue. | Salah satu tanda dalam permintaan tidak valid. Ini bisa berupa tanda yang Anda
berikan secara eksplisit atau tanda yang ditetapkan ke nilai default.
Pertama, pastikan nilai tanda Jika flag |
Tidak dapat membuat replika baca - error tidak diketahui. | Mungkin ada error yang lebih spesifik di file log.
Periksa log di
Cloud Logging untuk menemukan error yang sebenarnya.
Jika error-nya adalah: |
Disk penuh. | Ukuran disk instance utama dapat penuh selama pembuatan replika. Edit instance utama untuk mengupgradenya ke ukuran disk yang lebih besar. |
Instance replika menggunakan terlalu banyak memori. | Replika menggunakan memori sementara untuk meng-cache operasi baca yang
sering diminta, yang dapat menyebabkannya menggunakan lebih banyak memori daripada instance utama.
Mulai ulang instance replika untuk mengklaim kembali ruang memori sementara. |
Replikasi dihentikan. | Batas penyimpanan maksimum tercapai dan peningkatan penyimpanan otomatis
tidak diaktifkan.
Edit instance untuk mengaktifkan |
Jeda replikasi selalu tinggi. | Beban tulis terlalu tinggi untuk ditangani replika. Kelambatan replikasi
terjadi saat thread SQL pada replika tidak dapat mengikuti
thread IO. Beberapa jenis kueri atau beban kerja dapat menyebabkan kelambatan replikasi tinggi yang bersifat sementara atau
permanen untuk skema tertentu. Beberapa penyebab
umum kelambatan replikasi adalah:
Beberapa kemungkinan solusinya mencakup:
|
Pembuatan replika gagal dengan waktu tunggu. | Transaksi tanpa komitmen yang berjalan lama pada instance utama dapat menyebabkan
pembuatan replika baca gagal.
Buat ulang replika setelah menghentikan semua kueri yang berjalan. |