Memecahkan masalah

Jalankan perintah gcloud sql operations list untuk mencantumkan semua operasi untuk instance Cloud SQL yang ditentukan.

Lihat di log dan filter berdasarkan teks untuk menemukan pengguna. Anda mungkin perlu menggunakan log audit untuk informasi pribadi. File log yang relevan meliputi:

• cloudsql.googleapis.com/postgres.log
• Jika Cloud Audit Logs diaktifkan dan Anda memiliki izin yang diperlukan untuk melihatnya, cloudaudit.googleapis.com/activity mungkin juga tersedia.

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.

Jika benar-benar perlu membatalkan operasi, Anda dapat meminta dukungan pelanggan untuk force restart instance.

Buat pengguna database sebelum memulihkan dump SQL.

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.

• Mungkin ada terlalu banyak koneksi terbuka. Terlalu banyak koneksi dapat terjadi akibat kesalahan yang terjadi di tengah-tengah suatu koneksi di mana tidak ada penyetelan autovacuum untuk membersihkan koneksi yang tidak aktif.
• Kegagalan instance yang berulang dapat terjadi jika ada kode kustom yang menggunakan logika percobaan ulang yang tidak berhenti setelah beberapa kegagalan.
• Kemungkinan traffic terlalu banyak. Gunakan penggabungan koneksi dan praktik terbaik lainnya untuk konektivitas.

Hal-hal yang perlu dicoba:

1. Verifikasi bahwa database telah disiapkan untuk autovacuum.
2. Periksa apakah ada logika percobaan ulang koneksi yang disiapkan dalam kode kustom.
3. Turunkan traffic hingga database pulih, lalu naikkan traffic secara perlahan.

CREATE UNLOGGED TABLE ....

Tabel berikut tidak termasuk dalam pemulihan dari cadangan:

• Isi tabel yang tidak di-log tidak dapat bertahan saat terjadi failover pada instance HA.
• Tabel yang tidak di-log tidak dapat bertahan saat terjadi error postgres.
• Tabel yang tidak di-log tidak direplikasi ke replika baca.
• Tabel yang tidak di-log akan otomatis dihapus total selama pemulihan 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 tidak di-log, maka Anda dapat mengekspor database tersebut ke suatu file, dan memuat ulang datanya setelah memodifikasi file yang diekspor keALTER TABLE ke SET LOGGED pada tabel tersebut.

Anda mencoba membatalkan operasi impor atau ekspor yang telah selesai, gagal atau dibatalkan. Jika operasi sedang berjalan, Anda dapat membatalkannya.

Cloud SQL tidak mendukung pembatalan operasi karena memiliki jenis operasi selain IMPORT atau EXPORT.

Cloud SQL saat ini tidak dapat membatalkan operasi impor atau ekspor. Coba lagi dalam beberapa detik. Jika masalah berlanjut, hubungi Dukungan Google Cloud.

Hapus semua entri Authorized Networks dari instance Cloud SQL jika memungkinkan. Atau, buat replika tanpa entri Authorized Networks apapun.

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 gcloud untuk meng-clone instance dan memberikan nilai untuk parameter
--allocated-ip-range-name. Untuk informasi selengkapnya, lihat Meng-clone instance dengan IP pribadi.

• Ketidakstabilan jaringan.
• Tidak ada respons terhadap perintah keep-alive TCP (baik klien maupun server tidak responsif, mungkin kelebihan beban)
• Masa pakai koneksi mesin database terlampaui dan server mengakhiri koneksi.

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:

1. Backoff eksponensial. Tingkatkan interval waktu antara setiap percobaan ulang, secara eksponensial.
2. Tambahkan juga backoff acak.

Menggabungkan metode ini membantu mengurangi throttling.

Sertifikat klien telah habis masa berlakunya atau jalur ke sertifikat salah.

Buat ulang sertifikat dengan membuat ulang sertifikat.

Terhubung dengan pengguna default, lalu ubah pengguna.

• Ukuran rentang IP yang dialokasikan untuk koneksi layanan pribadi lebih kecil dari /24.
• Ukuran rentang IP yang dialokasikan untuk koneksi layanan pribadi terlalu kecil untuk jumlah instance Cloud SQL.
• Persyaratan ukuran rentang IP yang dialokasikan akan lebih besar jika instance dibuat di beberapa region. Lihat ukuran rentang yang dialokasikan

Untuk mengatasi masalah ini, Anda dapat memperluas rentang IP yang dialokasikan atau mengalokasikan rentang IP tambahan ke koneksi layanan pribadi. Untuk informasi selengkapnya, lihat Mengalokasikan rentang alamat IP.

Jika menggunakan tanda --allocated-ip-range-name saat membuat instance Cloud SQL, Anda hanya dapat memperluas rentang IP yang ditentukan.

Jika Anda mengalokasikan rentang baru, pastikan alokasinya tidak tumpang tindih dengan alokasi yang ada.

Setelah membuat rentang IP baru, perbarui peering vpc dengan perintah berikut:

gcloud services vpc-peerings update \
--service=servicenetworking.googleapis.com \
--ranges=OLD_RESERVED_RANGE_NAME,NEW_RESERVED_RANGE_NAME \
--network=VPC_NETWORK \
--project=PROJECT_ID \
--force
    

Jika Anda memperluas alokasi yang sudah ada, pastikan untuk hanya menambah rentang alokasi dan tidak menguranginya. Misalnya, jika alokasi asli adalah 10.0.10.0/24, buat alokasi baru dengan minimal 10.0.10.0/23.

Secara umum, jika dimulai dari alokasi /24, mengurangi /mask sebesar 1 untuk setiap kondisi (grup jenis instance tambahan, region tambahan) adalah aturan praktis yang baik. Misalnya, jika mencoba membuat kedua grup jenis instance pada alokasi yang sama, beralih dari /24 ke /23 sudah cukup.

Setelah memperluas rentang IP yang ada, perbarui peering vpc dengan perintah berikut:

gcloud services vpc-peerings update \
--service=servicenetworking.googleapis.com \
--ranges=RESERVED_RANGE_NAME \
--network=VPC_NETWORK \
--project=PROJECT_ID
    

Gunakan ekspor CSV untuk mengekspor hal yang Anda butuhkan saja.

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.

Edit file dump untuk menghapus referensi.

Lakukan ekspor manual menggunakan alat pg_dump.

Anda dapat membangun sistem ekspor otomatis Anda sendiri menggunakan produk Google Cloud seperti Cloud Scheduler, Pub/Sub, dan Cloud Functions. Produk-produk tersebut mirip dengan artikel ini yang membahas tentang mengotomatiskan pencadangan.

Hubungkan ke database dan setel zona waktu database ke zona yang Anda inginkan, baik per pengguna atau per database.

Di Cloud SQL untuk PostgreSQL, Anda dapat menentukan hal berikut ini. Setelan ini tidak berubah setelah sesi ditutup, mirip seperti konfigurasi .conf:

ALTER DATABASE dbname SET TIMEZONE TO 'timezone';
ALTER USER username SET TIMEZONE TO 'timezone';

Setelan ini hanya berlaku untuk koneksi baru ke database. Untuk melihat perubahan zona waktu, putuskan sambungan dari instance, lalu hubungkan kembali ke zona waktu tersebut.

Edit instance untuk mengupgrade ke ukuran mesin yang lebih besar untuk mendapatkan lebih banyak CPU dan memori.

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:

• Menutup semua koneksi.
• Mengakhiri tugas yang mungkin menghabiskan resource.

Buat pengguna database sebelum mengimpor.

Mungkin terjadi penggunaan disk yang tidak terduga setelah mengimpor data. Penggunaan ini mungkin karena penggunaan pemulihan point-in-time.

Untuk mengatasi hal ini, setelah mengimpor data, nonaktifkan pemulihan point-in-time jika Anda ingin menghapus log dan memulihkan penyimpanan. Perlu diingat bahwa mengurangi penyimpanan yang digunakan tidak akan mengurangi ukuran penyimpanan yang disediakan untuk instance tersebut.

Pesan error ini muncul jika Anda mencoba mengimpor file dump SQL yang diupload di Cloud Storage ke database Cloud SQL, dan tugas impor telah berjalan selama sekitar empat hari.

ROLE_NAME adalah peran database kustom yang ditentukan dalam database PostgreSQL sumber. Pengguna cloudsqlsuperuser default mengimpor file dump SQL. Namun, pengguna ini mungkin tidak termasuk dalam peran ROLE_NAME.

Untuk mengatasi masalah ini, selesaikan beberapa langkah berikut:

1. Buat peran ROLE_NAME di database tujuan tempat Anda mengimpor file dump SQL.

2. Jangan gunakan pengguna cloudsqlsuperuser untuk mengimpor file. Sebagai gantinya, di database tujuan, tetapkan pengguna yang merupakan anggota peran ROLE_NAME. Untuk menentukan pengguna, jalankan perintah berikut:

   gcloud sql import sql INSTANCE URI [--async]
[--database=DATABASE, -d DATABASE] [--user=USER] [GCLOUD_WIDE_FLAG …]

Flag log_statement dapat disetel ke tidak ada dan flag logging_collector dapat disetel ke nonaktif. Jika logging masih terjadi, mungkin ada flag terkait log lainnya yang dapat disesuaikan. Anda dapat mengedit instance untuk mengubah flag ini.

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.

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
   

1. Dari terminal, hubungkan ke database Anda:

   gcloud sql connect INSTANCE_NAME
         

2. Jalankan perintah ini untuk membuat ekstensi:

   CREATE EXTENSION pgaudit;
         

3. Keluar dari database, dan jalankan perintah berikut dari terminal:

   gcloud sql instances patch INSTANCE_NAME \
   --database-flags=cloudsql.enable_pgaudit=on,pgaudit.log=all
        

SELECT datname, usename, application_name as appname, client_addr, state, now() - backend_start as conn_age, now() - xact_start as xact_age, now() - query_start as query_age, now() - state_change as last_activity_age, wait_event_type, wait_event, query FROM pg_stat_activity WHERE state <> 'idle' ORDER BY 8 DESC LIMIT 20;

SELECT name, setting, unit FROM pg_settings WHERE name = 'FIELD_NAME'.

SHOW SETTING_NAME;

Jalankan SHOW ALL; untuk melihat seluruh setelan.

Jalankan perintah berikut:

1.       GRANT pg_signal_backend TO USERNAME;
         

2. Temukan ID proses dari proses yang diblokir atau macet:

         SELECT pid, usename, state, query FROM pg_stat_activity;
         

3. Hentikan proses yang sedang berjalan atau tidak aktif menggunakan perintah berikut:

         SELECT pg_cancel_backend(pid)
               FROM pg_stat_activity
               WHERE usename = 'USERNAME';
         
         

         SELECT pg_terminate_backend(pid)
               FROM pg_stat_activity
               WHERE usename = 'USERNAME';
         
         

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.

Proses mulai ulang akan menghapus file sementara, tetapi tidak mengurangi penyimpanan. Hanya dukungan pelanggan yang dapat mereset ukuran instance.

Periksa log di sekitar waktu penghapusan dan periksa apakah ada skrip berbahaya yang berjalan dari dasbor atau proses otomatis lainnya.

Beberapa kemungkinan penjelasan meliputi:

• Operasi lain sedang berlangsung. Operasi Cloud SQL tidak berjalan secara bersamaan. Tunggu hingga operasi lainnya selesai.
• Peringatan INSTANCE_RISKY_FLAG_CONFIG dipicu setidaknya setiap kali satu flag beta digunakan. Hapus setelan flag yang berisiko dan mulai ulang instance

Sayangnya, Anda tidak dapat mengecilkan file ibtmp1 dengan metode apa pun selain memulai ulang layanan.

Salah satu opsi mitigasi adalah membuat tabel sementara dengan ROW_FORMAT=COMPRESSED, sehingga tabel tersebut disimpan dalam tablespace file per tabel di direktori file sementara. Namun, kelemahannya adalah biaya performa yang terkait dengan pembuatan dan penghapusan tablespace file per tabel untuk setiap tabel sementara.

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.

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.

Cari tahu objek mana yang bergantung pada pengguna tersebut, lalu hapus atau alihkan objek tersebut ke pengguna yang berbeda.

Lihat tips performa umum secara khusus.

Untuk penyisipan, update, atau penghapusan database yang berjalan lambat, pertimbangkan tindakan berikut:

• Periksa lokasi penulis dan database; mengirim data jarak jauh dapat menyebabkan latensi.
• Periksa lokasi pembaca dan database; latensi lebih memengaruhi performa baca daripada performa tulis

Untuk mengurangi latensi, sebaiknya tempatkan resource sumber dan tujuan di region yang sama.

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.

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.

Namun, ada cara lain untuk mencapai tujuan tersebut, yaitu dengan membuat instance baru.

• Anda dapat meng-clone instance yang ingin diganti namanya dan menetapkan nama baru untuk instance yang di-clone. Cara ini memungkinkan Anda membuat instance baru tanpa harus mengimpor data secara manual. Sama seperti saat membuat instance baru, instance yang di-clone akan memiliki alamat IP baru.
• Anda dapat mengekspor data dari instance ke dalam bucket Cloud Storage, membuat instance baru dengan nama baru yang diinginkan, lalu mengimpor data ke dalam instance baru tersebut.

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.

Pertama, pastikan nilai tanda max_connections lebih besar dari atau sama dengan nilai pada tanda utama.

Jika flag max_connections sudah ditetapkan dengan tepat, periksa log di Cloud Logging untuk menemukan error yang sebenarnya.

Jika error-nya adalah: set Service Networking service account as servicenetworking.serviceAgent role on consumer project, makan nonaktifkan dan aktifkan kembali Service Networking API. Tindakan ini akan membuat akun layanan yang diperlukan untuk melanjutkan prosesnya.

Mulai ulang instance replika untuk mengklaim kembali ruang memori sementara.

Edit instance untuk mengaktifkan automatic storage increase.

• Kueri lambat pada replika. Temukan dan perbaiki.
• Semua tabel harus memiliki kunci utama/unik. Setiap update pada tabel tersebut tanpa kunci utama/unik akan menyebabkan pemindaian tabel penuh pada replika tersebut.
• Kueri seperti DELETE ... WHERE field < 50000000 menyebabkan kelambatan replikasi dengan replikasi berbasis baris karena sejumlah besar update tertumpuk di replika.

Beberapa kemungkinan solusinya mencakup:

• Edit instance untuk meningkatkan ukuran replika.
• Kurangi beban pada database.
• Kirim traffic baca ke replika baca.
• Indeks tabel.
• Iidentifikasi dan perbaiki kueri penulisan yang lambat.
• Membuat ulang replika.

Jika Anda harus menggunakan indeks hash, upgrade ke PostgreSQL 10+. Atau, jika Anda juga ingin menggunakan replika, jangan gunakan indeks hash di PostgreSQL 9.6.

Buat ulang replika setelah menghentikan semua kueri yang berjalan.