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 |
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. |
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 yang besar akan menghadirkan tantangan yang tidak disebabkan oleh sekelompok instance yang lebih kecil. |
Jangan menggunakan terlalu banyak database atau tabel. |
Pertahankan jumlah database Anda kurang dari 500 database. Pertahankan jumlah tabel instance Anda kurang dari 50.000, atau 500.000 jika Anda memenuhi persyaratan hardware minimum 32+ core dan 200 G+ memori. Pertahankan jumlah tabel Anda untuk setiap database kurang dari 50.000 tabel. Terlalu banyak database atau tabel database dapat memengaruhi waktu upgrade database. |
Pastikan tabel Anda memiliki atau kunci utama atau kunci unik. | Cloud SQL menggunakan replikasi berbasis baris, yang berfungsi paling baik pada tabel dengan kunci utama atau kunci unik. |
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. |
Saat memigrasikan data dengan ekspor dan impor, gunakan mode SQL yang sama persis untuk impor seperti ekspor. | Lihat Menggunakan Mode SQL yang sama untuk impor dan ekspor. |
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. |
Langkah selanjutnya
Untuk informasi selengkapnya tentang praktik umum oleh mesin database, lihat:
- Praktik terbaik umum untuk MySQL
- Praktik terbaik umum untuk PostgreSQL
- Praktik terbaik umum untuk SQL Server