Praktik terbaik umum

Halaman ini berisi tentang praktik terbaik untuk mendapatkan performa, ketahanan, dan ketersediaan terbaik dari Cloud SQL.

Jika terjadi masalah pada instance Cloud SQL, tinjau dokumentasi dukungan berikut saat melakukan pemecahan masalah:

Konfigurasi dan administrasi instance

Praktik terbaik Informasi selengkapnya
Baca dan ikuti pedoman operasional untuk memastikan bahwa instance Anda tercakup dalam SLA Cloud SQL.
Konfigurasikan masa pemeliharaan pada instance utama untuk mengontrol waktu saat update yang mengganggu dapat terjadi. Lihat Masa pemeliharaan.
Untuk workload read-heavy, tambahkan replika baca untuk memindahkan traffic dari instance utama. Secara opsional, Anda dapat menggunakan load balancer seperti HAProxy untuk mengelola traffic ke replika.
Jika Anda menghapus dan membuat ulang instance secara rutin, gunakan stempel waktu dalam ID instance untuk meningkatkan kemungkinan ID instance baru dapat digunakan.
Jangan memulai operasi administratif sebelum operasi sebelumnya selesai.

Instance Cloud SQL tidak menerima permintaan operasi baru hingga operasi sebelumnya selesai. Jika Anda mencoba untuk memulai operasi baru sebelum waktunya, permintaan operasi akan gagal. Operasi ini termasuk memulai ulang instance.

Status instance di konsol Google Cloud tidak menunjukkan bahwa operasi sedang berjalan. Tanda centang hijau hanya menunjukkan bahwa instance berada dalam status RUNNABLE. Untuk melihat bahwa operasi sedang berjalan, buka tab Operasi, lalu periksa status operasi terbaru.

Konfigurasikan penyimpanan untuk mengakomodasi pemeliharaan database yang penting.

Jika setelan instance aktifkan peningkatan penyimpanan otomatis dalam keadaan nonaktif atau setelan batas peningkatan penyimpanan otomatis dalam keadaan aktif, pastikan Anda memiliki minimal 20% dari kapasitas yang tersedia untuk mengakomodasi operasi pemeliharaan database penting apa pun yang dapat dijalankan Cloud SQL.

Agar mendapatkan pemberitahuan saat kapasitas disk yang tersisa kurang dari 20%, buat kebijakan pemberitahuan berbasis metrik pada metrik pemakaian disk dengan posisi di atas nilai minimum dan nilai sebesar .8. Untuk informasi selengkapnya, lihat Membuat kebijakan pemberitahuan berbasis metrik.
Cegah penggunaan CPU yang berlebihan.

Anda dapat melihat persentase CPU yang tersedia yang digunakan instance di halaman detail instance di konsol Google Cloud. Untuk informasi selengkapnya, lihat Metrik. Anda juga dapat memantau penggunaan CPU dan menerima pemberitahuan pada batas yang ditentukan menggunakan Membuat kebijakan pemberitahuan batas metrik.

Untuk menghindari penggunaan yang berlebihan, Anda dapat meningkatkan jumlah CPU untuk instance Anda. Jika ingin mengubah CPU, instance harus dimulai ulang. Jika instance sudah mencapai batas maksimum jumlah CPU, Anda harus melakukan sharding database ke beberapa instance.
Hindari terjadinya kehabisan memori.

Saat mencari tanda-tanda kehabisan memori, Anda sebaiknya menggunakan metrik penggunaan sebagai langkah utama. Untuk menghindari terjadinya error kehabisan memori, sebaiknya upayakan agar metrik ini tetap berada di bawah 90%.

Anda juga dapat menggunakan metrik total_usage untuk mengamati persentase memori yang tersedia yang digunakan instance Cloud SQL, termasuk memori yang digunakan container database dan memori yang dialokasikan oleh cache sistem operasi.

Dengan mengamati perbedaan antara kedua metrik tersebut, Anda dapat mengidentifikasi jumlah memori yang digunakan oleh proses dengan jumlah yang digunakan oleh cache sistem operasi. Anda dapat menggunakan kembali memori dalam cache ini.

Untuk memprediksi masalah kehabisan memori, periksa kedua metrik dan tafsirkan keduanya bersamaan. Jika metrik tampak tinggi, kemungkinan memori instance rendah. Masalah ini dapat disebabkan oleh konfigurasi kustom, ukuran instance yang terlalu kecil untuk workload, atau kombinasi dari faktor-faktor ini.

Skalakan instance Cloud SQL untuk meningkatkan ukuran memorinya. Jika ingin mengubah ukuran memori instance, instance harus dimulai ulang. Jika instance sudah mencapai ukuran memori maksimum, Anda harus melakukan sharding database ke beberapa instance. Untuk mempelajari lebih lanjut cara memantau kedua metrik di konsol Google Cloud, lihat Metrik.
Pastikan instance Anda memiliki ID transaksi yang optimal.

Anda dapat menampilkan penggunaan ID transaksi instance di halaman Metrics Explorer di konsol Google Cloud dengan menetapkan Resource Type sebagai Cloud SQL Database dan Metric sebagai Percentage of instance's transaction IDs consumed. Untuk informasi selengkapnya, lihat Membuat chart dengan Metrics Explorer.

Menyesuaikan dan memantau instance database dapat membantu mengurangi atau menghindari masalah terkait vacuum. Pantau penggunaan ID transaksi instance Anda, lalu aktifkan dan sesuaikan parameter autovacuum sesuai dengan workload pada instance Anda. Untuk mengetahui informasi selengkapnya, lihat Mengatasi perlindungan menyeluruh ID transaksi (TXID).

Arsitektur data

Praktik terbaik Informasi selengkapnya
Jika memungkinkan, bagi instance besar menjadi instance yang lebih kecil. Jika memungkinkan, menggunakan banyak instance Cloud SQL yang lebih kecil akan lebih baik dibandingkan dengan menggunakan satu instance besar. Mengelola instance monolitik besar memiliki tantangan, tidak seperti saat mengelola instance yang lebih kecil.
Jangan menggunakan terlalu banyak tabel database.

Pertahankan jumlah tabel instance kurang dari 10.000 tabel. Terlalu banyak tabel database dapat memengaruhi waktu upgrade database.

Implementasi aplikasi

Praktik terbaik Informasi selengkapnya
Gunakan praktik pengelolaan koneksi yang baik, seperti penggabungan koneksi dan backoff eksponensial. Menggunakan teknik ini akan meningkatkan penggunaan resource pada aplikasi dan membantu Anda tetap berada dalam batas koneksiCloud SQL. Untuk informasi dan contoh kode selengkapnya, lihat Mengelola koneksi database.
Uji respons aplikasi Anda terhadap update pemeliharaan yang dapat terjadi sewaktu-waktu selama masa pemeliharaan. Coba pemeliharaan mandiri untuk menyimulasikan update pemeliharaan. Selama pemeliharaan, instance Anda akan menjadi tidak tersedia untuk beberapa saat, serta koneksi yang ada akan dihentikan. Menguji peluncuran pemeliharaan dapat membantu Anda untuk lebih memahami cara aplikasi dalam menangani pemeliharaan terjadwal dan seberapa cepat sistem dapat pulih.
Uji respons aplikasi Anda terhadap failover yang dapat terjadi sewaktu-waktu. Anda dapat memulai failover secara manual menggunakan konsol Google Cloud, gcloud CLI, atau API. Lihat Memulai failover.
Hindari transaksi besar. Pertahankan agar transaksi tetap kecil dan singkat. Jika memerlukan update database yang besar, lakukanlah dalam beberapa transaksi yang lebih kecil, bukan satu transaksi besar.
Jika menggunakan Proxy Auth Cloud SQL, pastikan Anda menggunakan versi terbaru. Lihat Menjaga agar Proxy Auth Cloud SQL selalu dalam keadaan terbaru.

Impor dan ekspor data

Praktik terbaik Informasi selengkapnya
Gunakan ekspor serverless. Ekspor serverless memindahkan operasi ekspor ke instance sementara, sehingga instance utama dapat terus melayani kueri dan menjalankan operasi dengan performa seperti biasa. Setelah ekspor data selesai, instance sementara akan otomatis dihapus.
Mempercepat impor untuk ukuran instance kecil. Untuk instance kecil, Anda dapat meningkatkan CPU dan RAM instance untuk sementara guna meningkatkan performa saat mengimpor set data besar.
Jika Anda mengekspor data untuk diimpor ke Cloud SQL, pastikan Anda menggunakan prosedur yang tepat. Lihat Mengekspor data dari server database yang dikelola secara eksternal.

Pencadangan dan pemulihan

Praktik terbaik Informasi selengkapnya
Lindungi data Anda dengan fungsi Cloud SQL yang sesuai.

Pencadangan, pemulihan point-in-time, dan ekspor adalah cara untuk memberikan perlindungan dan redundansi data. Keduanya saling melindungi dari berbagai skenario dan saling melengkapi dalam strategi perlindungan data yang tangguh.

Pencadangan ringan; fungsi ini memberikan cara untuk memulihkan data pada instance ke kondisi semula saat Anda mengambil pencadangannya. Namun, pencadangan memiliki beberapa batasan. Jika instance dihapus, cadangannya juga akan terhapus. Anda tidak dapat mencadangkan satu database atau tabel. Jika region tempat instance berada tidak tersedia, Anda tidak dapat memulihkan instance dari cadangan tersebut, bahkan di region yang tersedia.

Pemulihan point-in-time membantu Anda memulihkan instance ke titik waktu tertentu. Misalnya, jika error menyebabkan hilangnya data, Anda dapat memulihkan database ke statusnya sebelum error terjadi. Pemulihan point-in-time selalu membuat instance baru; Anda tidak dapat melakukan pemulihan point-in-time untuk instance yang ada.

Proses ekspor memerlukan waktu lebih lama karena file eksternal dibuat di Cloud Storage yang dapat digunakan untuk membuat ulang data Anda. Ekspor tidak akan terpengaruh jika Anda menghapus instance. Selain itu, Anda dapat mengekspor hanya satu database atau bahkan tabel, bergantung pada format ekspor yang Anda pilih.

Mengukur instance untuk memperhitungkan retensi log transaksi (biner). Aktivitas tulis yang tinggi ke database dapat menghasilkan log transaksi (biner) dalam jumlah besar, yang dapat menghabiskan banyak kapasitas disk, dan menyebabkan peningkatan disk untuk instance yang diaktifkan guna meningkatkan penyimpanan secara otomatis. Sebaiknya Anda menyesuaikan ukuran penyimpanan instance untuk retensi log transaksi.
Lindungi instance dan cadangan Anda dari penghapusan yang tidak disengaja.

Instance Cloud SQL yang dibuat di konsol Google Cloud atau melalui Terraform mampu mencegah penghapusan yang tidak disengaja secara default.

Gunakan fitur ekspor di Cloud SQL untuk mengekspor data Anda sebagai perlindungan tambahan. Gunakan Cloud Scheduler dengan REST API untuk mengotomatiskan pengelolaan ekspor. Untuk skenario lanjutan lainnya, gunakan Cloud Scheduler dengan Cloud Functions untuk otomatisasi.

Setel dan pantau

Menyesuaikan dan memantau instance database dapat membantu mengurangi atau menghindari masalah terkait vacuum.

Operasi VACUUM memiliki varian yang berbeda dengan tingkat penguncian yang berbeda: VACUUM standar dan VACUUM FULL. Opsi VACUUM FULL dapat mengklaim kembali lebih banyak kapasitas disk, tetapi secara eksklusif mengunci tabel dan berjalan lambat. Sebagai gantinya, gunakan bentuk standar VACUUM, yang dapat berjalan secara paralel dengan operasi database produksi. Saat Anda menggunakan operasi VACUUM, perintah seperti SELECT, INSERT, UPDATE, and DELETE akan terus berfungsi secara normal. Anda tidak akan dapat mengubah definisi tabel dengan perintah seperti ALTER TABLE saat sedang di-vacuum.

Berikut beberapa rekomendasi yang mungkin dapat membantu mengurangi waktu yang diperlukan untuk menyelesaikan operasi VACUUM:

  • Meningkatkan memori sistem dan maintenance_work_mem. Tindakan ini mengumpulkan lebih banyak tupel dalam setiap iterasi dan menyelesaikan pekerjaan secepat mungkin. Perlu diketahui bahwa saat autovacuum berjalan, hingga autovacuum_max_workers kali memori ini dapat dialokasikan, jadi berhati-hatilah untuk tidak menetapkan nilai default terlalu tinggi.
  • Operasi VACUUM menghasilkan banyak catatan write-ahead log (WAL). Jika memungkinkan untuk mengurangi jumlah data WAL, misalnya dengan tidak mengonfigurasi replika untuk instance ini, operasi akan selesai lebih cepat.
  • Jika tabel telah mencapai batas dua miliar ID transaksi karena tidak ada tuple yang dibekukan, coba kurangi jumlah pekerjaan yang dilakukan dalam mode satu pengguna. Salah satu opsi yang memungkinkan adalah menetapkan vacuum_freeze_min_age=1,000,000,000 (nilai maksimum yang diizinkan, meningkat dari nilai default 50,000,000). Nilai baru ini akan mengurangi jumlah tuple yang dibekukan hingga dua kali.
  • PostgreSQL versi 12.0 dan versi yang lebih baru mendukung pembersihan dan operasi VACUUM tanpa membersihkan entri indeks. Hal ini sangat penting, karena pembersihan indeks memerlukan pemindaian indeks yang lengkap, dan jika ada beberapa indeks, maka waktu totalnya bergantung pada ukuran indeks.
  • Indeks yang lebih besar menghabiskan banyak waktu untuk melakukan pemindaian indeks, oleh karena itu, INDEX_CLEANUP OFF sebaiknya digunakan untuk membersihkan dan membekukan data tabel dengan cepat. Versi PostgreSQL sebelum 12.0 perlu menyesuaikan jumlah indeks. Artinya, jika ada indeks nonkritis, sebaiknya lepas indeks NON-CRITICAL untuk mempercepat operasi vacuum.

Langkah selanjutnya

Untuk informasi selengkapnya tentang praktik umum oleh mesin database, lihat: