Pemecahan Masalah Cloud SQL

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:

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

Jika Anda menghapus instance tanpa membuat cadangan akhir data, pemulihan data tidak dapat dilakukan. Namun, jika Anda memulihkan instance, Cloud SQL juga akan memulihkan cadangan. Untuk mengetahui informasi selengkapnya tentang cara memulihkan instance yang dihapus, lihat Mempertahankan cadangan setelah penghapusan instance.

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.

• Tetapkan nilai cadangan akhir agar sesuai dengan konfigurasi cadangan yang ada di instance.
• Biarkan kolom cadangan akhir kosong saat Anda menghapus instance. Jika Anda mengosongkan kolom, Cloud SQL akan menggunakan konfigurasi pencadangan akhir yang ditetapkan di setelan instance untuk membuat pencadangan akhir dan menentukan retensinya.

Hapus semua Authorized Networks entri 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.

• Operasi lambat untuk membuat login Microsoft Entra ID
• Tidak dapat membuat login Microsoft Entra ID
• Tidak dapat terhubung ke instance menggunakan autentikasi Microsoft Entra ID

Untuk mengetahui informasi selengkapnya tentang cara membantu mengatasi masalah ini, lihat Memecahkan masalah integrasi Microsoft Entra ID.

Terhubung dengan pengguna default, lalu ubah pengguna.

Zona yang dipilih tidak memiliki kapasitas untuk resource yang diminta atau jenis VM pada saat permintaan pembuatan instance. Mungkin ada permintaan operasional tinggi secara bersamaan di lokasi regional tertentu tersebut pada saat permintaan.

Untuk mengatasi masalah ini, coba lagi buat instance di zona lain atau coba lagi buat instance di zona yang sama yang menerima error pada waktu yang berbeda.

• 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
    

Aktifkan Service Networking API menggunakan perintah berikut dan coba buat instance Cloud SQL lagi.

gcloud services enable servicenetworking.googleapis.com \
--project=PROJECT_ID
    

Pastikan nama DNS yang ingin Anda tambahkan ke sertifikat server instance Cloud SQL memenuhi kriteria berikut:

• Tidak memiliki karakter pengganti.
• Tidak memiliki titik di akhir.
• Memenuhi spesifikasi RFC 1034.

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

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 mysqldump untuk migrasi impor terkelola, lihat Tanda sinkronisasi awal yang diizinkan dan default

Penyelesaian: Jangan jalankan pernyataan DDL pada database sumber selama fase dump awal. Sebelum Anda menjalankan pernyataan DDL apa pun, mulai ulang migrasi dan tunggu hingga fase dump awal selesai.

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 binlog-do-db, binlog-ignore-db, replicate-do-db, atau replicate-ignore-db tidak ditetapkan dengan cara yang bertentangan.

Jalankan perintah show master status pada instance utama untuk melihat setelan saat ini.

Hal-hal yang sebaiknya dicoba:

• Periksa metrik replikasi untuk instance replika Anda di bagian Cloud Monitoring pada konsol Google Cloud .
• Error dari thread IO MySQL atau thread SQL dapat ditemukan di Cloud Logging dalam file log mysql.err.
• Error ini juga dapat ditemukan saat menghubungkan ke instance replika. Jalankan perintah SHOW REPLICA STATUS, dan periksa kolom berikut dalam output:
  • Replica_IO_Running
  • Replica_SQL_Running
  • Last_IO_Error
  • Last_SQL_Error

Jika Anda menemukan error Unknown database DATABASE_NAME on query. Error_code: MY-001049, berarti replikasi gagal karena pernyataan SQL yang direplikasi mencoba mereferensikan database yang tidak dipilih untuk migrasi. Untuk memulihkan replikasi, tentukan apakah error berdasarkan pesan disebabkan oleh DDL pada salah satu objek berikut:

• Acara atau rutinitas. Anda dapat menjalankan CALL mysql.skipReplicationError() di replika, yang akan mencegah peristiwa atau rutinitas direplikasi dan melanjutkan replikasi.
• Batasan atau tampilan kunci asing. Setelah menentukan database tempat objek yang diubah oleh pernyataan berada, Anda memiliki dua opsi untuk pemulihan. Anda dapat menghapus database dari database yang dipilih yang sedang dimigrasikan, atau Anda dapat menjalankan CALL mysql.skipReplicationError() pada replika untuk melanjutkan replikasi sambil melewati batasan atau propagasi tampilan ke replika.

Tingkatkan ukuran disk instance replika. Anda dapat meningkatkan ukuran disk secara manual atau mengaktifkan peningkatan penyimpanan otomatis.

Buat file dump baru menggunakan setelan flag yang benar, dan konfigurasi replika eksternal menggunakan file tersebut

1. Hubungkan ke klien mysql Anda melalui instance Compute Engine.
2. Jalankan mysqldump lalu gunakan flag --master-data=1 dan --flush-privileges.

   Penting: Jangan sertakan flag --set-gtid-purged=OFF.

   Pelajari lebih lanjut.

3. Pastikan file dump yang baru saja dibuat berisi baris SET @@GLOBAL.GTID_PURGED='...'.
4. Upload file dump ke bucket Cloud Storage dan konfigurasi replika menggunakan file dump.

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.

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.

EXEC sp_serveroption
    @server='LINKED_SERVER_NAME',
    @optname='data access',
    @optvalue='TRUE'

Ganti LINKED_SERVER_NAME dengan nama server tertaut.