Tentang pencadangan Cloud SQL

Halaman ini menjelaskan cara kerja cadangan instance Cloud SQL. Anda dapat melakukan pencadangan pada instance utama.

Untuk mengetahui petunjuk langkah demi langkah dalam menjadwalkan pencadangan atau membuat pencadangan on demand, lihat Membuat dan Mengelola Pencadangan On Demand dan Otomatis.

Untuk ringkasan cara memulihkan data ke instance dari cadangan, lihat Ringkasan pemulihan instance.

Yang disediakan oleh cadangan

Cadangan membantu Anda memulihkan data yang hilang ke instance Cloud SQL. Selain itu, jika instance mengalami masalah, Anda dapat memulihkannya ke status sebelumnya menggunakan cadangan untuk menimpanya. Aktifkan pencadangan otomatis untuk instance apa pun yang berisi data yang diperlukan. Cadangan melindungi data Anda dari kehilangan atau kerusakan.

Pengaktifan pencadangan otomatis bersama dengan logging transaksi juga diperlukan untuk beberapa operasi, seperti pembuatan clone dan replika.

Biaya pencadangan

Secara default, Cloud SQL menyimpan 7 cadangan otomatis untuk setiap instance edisi Cloud SQL Enterprise dan 15 cadangan otomatis untuk setiap instance edisi Cloud SQL Enterprise Plus , selain pencadangan on-demand. Anda dapat mengonfigurasi jumlah cadangan otomatis yang akan dipertahankan (dari 1 hingga 365). Kami mengenakan tarif lebih rendah untuk penyimpanan cadangan dibandingkan untuk jenis instance lainnya.

Cloud SQL tidak mencadangan instance jika Anda menghentikan atau menghapus instance tersebut. Jika Anda menghapus instance, data tersebut hanya akan dipertahankan selama 4 hari. Untuk memulihkan instance dan datanya, hubungi Dukungan Google Cloud dalam periode 4 hari dengan menyertakan semua informasi instance yang diperlukan.

Lihat halaman harga untuk mengetahui informasi selengkapnya.

Cadangan versus ekspor

Pencadangan dikelola oleh Cloud SQL sesuai dengan kebijakan retensi, dan disimpan secara terpisah dari instance Cloud SQL. Cadangan Cloud SQL berbeda dengan ekspor yang diupload ke Cloud Storage, tempat Anda mengelola siklus proses. Cadangan mencakup seluruh database. Ekspor dapat memilih konten tertentu.

Operasi pencadangan dan pemulihan tidak dapat digunakan untuk mengupgrade database ke versi yang lebih baru. Anda hanya dapat memulihkan dari pencadangan ke sebuah instance dengan versi database yang sama.

Untuk melakukan upgrade ke versi yang lebih baru, pertimbangkan untuk menggunakan Database Migration Service atau mengekspor lalu mengimpor database Anda ke instance Cloud SQL baru.

Tentang ukuran cadangan

Pencadangan Cloud SQL bersifat inkremental. Pencadangan CLoud SQL ini hanya berisi data yang berubah setelah pencadangan sebelumnya diambil. Cadangan terlama memiliki ukuran yang serupa dengan database Anda, tetapi ukuran cadangan berikutnya bergantung pada laju perubahan data. Ketika cadangan terlama dihapus, ukuran cadangan terlama berikutnya akan bertambah, sehingga cadangan penuh masih ada.

Jenis pencadangan

Cloud SQL menjalankan dua jenis pencadangan:

Pencadangan sesuai permintaan

Anda dapat membuat cadangan kapan saja. Hal ini dapat bermanfaat jika Anda ingin menjalankan operasi yang berisiko pada database, atau jika Anda memerlukan cadangan dan tidak ingin menunggu periode pencadangan. Anda dapat membuat cadangan sesuai permintaan untuk instance apa pun, baik instance tersebut telah mengaktifkan pencadangan otomatis atau belum.

Pencadangan sesuai permintaan tidak dihapus secara otomatis seperti pencadangan otomatis. Pesan akan tetap ada sampai Anda menghapusnya atau sampai instance-nya dihapus. Karena tidak dihapus secara otomatis, pencadangan sesuai permintaan dapat berdampak jangka panjang terhadap biaya tagihan Anda.

Pencadangan otomatis

Pencadangan otomatis dilakukan setiap hari, dalam periode pencadangan 4 jam. Pencadangan dimulai selama periode pencadangan. Jika memungkinkan, jadwalkan pencadangan saat instance Anda memiliki aktivitas paling sedikit.

Sebaiknya Anda tidak menghapus cadangan otomatis karena cadangan tersebut diperlukan untuk mendukung pemulihan point-in-time.

Selama periode pencadangan, pencadangan otomatis dilakukan setiap hari saat instance Anda berjalan. Satu pencadangan otomatis tambahan akan dilakukan setelah instance Anda dihentikan untuk mengamankan semua perubahan sebelum instance berhenti. HIngga tujuh pencadangan terbaru akan disimpan, secara default. Anda dapat mengonfigurasi jumlah cadangan otomatis yang akan dipertahankan, dari 1 hingga 365. Nilai retensi log transaksi dan cadangan dapat diubah dari setelan default. Pelajari lebih lanjut.

Tempat cadangan disimpan

Lokasi cadangan meliputi:

  • Lokasi default yang Cloud SQL pilih, berdasarkan lokasi instance asli.
  • Lokasi kustom yang Anda pilih saat Anda tidak ingin menggunakan lokasi default.

Lokasi pencadangan default

Jika Anda tidak menentukan lokasi penyimpanan, cadangan Anda akan disimpan di multiregion yang secara geografis paling dekat dengan lokasi instance Cloud SQL Anda. Misalnya, jika instance Cloud SQL Anda berada di us-central1, cadangan Anda akan disimpan di multi-regionus secara default. Namun, lokasi default seperti australia-southeast1 berada di luar multi-region. Multi-region terdekat adalah asia.

Lokasi pencadangan kustom

Cloud SQL dapat Anda gunakan untuk memilih lokasi kustom untuk data cadangan Anda. Hal ini berguna jika organisasi Anda perlu mematuhi peraturan residensi data yang mengharuskan Anda menyimpan cadangan dalam batas geografis tertentu. Jika memiliki jenis persyaratan ini, organisasi Anda mungkin menggunakan kebijakan organisasi Pembatasan Lokasi Resource. Dengan kebijakan ini, saat Anda mencoba menggunakan lokasi geografis yang tidak mematuhi kebijakan, Anda akan melihat peringatan di halaman Pencadangan. Jika melihat pemberitahuan ini, Anda perlu mengubah lokasi cadangan ke lokasi yang diizinkan oleh kebijakan.

Saat memilih lokasi kustom untuk cadangan, pertimbangkan hal berikut:

  • Biaya: satu cluster di instance Anda mungkin berada di region dengan biaya yang lebih rendah daripada cluster lainnya.
  • Kedekatan dengan server aplikasi: Anda sebaiknya menyimpan cadangan sedekat mungkin dengan aplikasi penyaluran.
  • Penggunaan penyimpanan: Anda memerlukan ruang penyimpanan yang cukup untuk menyimpan cadangan seiring bertambahnya ukuran. Bergantung pada workload, Anda mungkin memiliki cluster dengan ukuran berbeda atau penggunaan disk yang berbeda. Hal ini dapat mempengaruhi klaster yang Anda pilih.

Untuk mengetahui daftar lengkap nilai regional yang valid, lihat Lokasi Instance. Untuk daftar lengkap nilai multi-region, lihat Lokasi multi-region.

Untuk mengetahui informasi selengkapnya tentang cara menyetel lokasi cadangan dan melihat lokasi cadangan yang digunakan untuk instance, lihat Menetapkan lokasi kustom untuk cadangan dan Melihat lokasi cadangan.

Pencadangan otomatis dan retensi log transaksi

Cadangan otomatis digunakan untuk memulihkan instance Cloud SQL. Kombinasi pencadangan otomatis dan log transaksi digunakan untuk melakukan pemulihan point-in-time.

Pencadangan otomatis dapat dipertahankan hingga satu tahun dengan mengonfigurasi periode retensi, sedangkan pencadangan on demand akan dipertahankan hingga Anda menghapus cadangan atau hingga instance dihapus.

Meskipun log transaksi dihitung dalam hari, pencadangan otomatis tidak dijamin terjadi pada batas hari. Unit yang berbeda digunakan untuk setelan retensi ini. Retensi cadangan otomatis dihitung dan dapat ditetapkan dari satu hingga 365 cadangan.

Retensi log transaksi dihitung dalam hari. Untuk instance edisi Cloud SQL Enterprise Plus, rentangnya adalah 1 hingga 35 hari, dengan default 14 hari. Untuk instance edisi Cloud SQL Enterprise, rentangnya adalah 1 hingga 7 hari, dengan default 7 hari. Untuk instance edisi Cloud SQL Enterprise Plus dan edisi Cloud SQL Enterprise, setelan retensi log transaksi harus kurang dari setelan retensi cadangan.

Batas bawah berguna untuk instance pengujian, karena log dan cadangan dihapus dengan lebih cepat. Untuk log transaksi, ukuran disk tidak bertambah banyak dengan batas bawah. Menggunakan nilai yang lebih tinggi untuk retensi cadangan otomatis memungkinkan Anda melakukan pemulihan dari waktu yang lebih lama.

Log dihapus permanen sekali sehari, bukan terus-menerus. Jika jumlah hari retensi log sama dengan jumlah cadangan, dapat terjadi retensi log yang tidak memadai. Misalnya, menetapkan retensi log ke tujuh hari dan retensi cadangan ke tujuh cadangan berarti bahwa antara enam dan tujuh hari log akan disimpan.

Sebaiknya tetapkan jumlah cadangan ke setidaknya satu lebih banyak daripada jumlah hari retensi log untuk menjamin retensi log minimum pada hari tertentu.

Aktivitas tulis yang tinggi ke database dapat menghasilkan log transaksi dalam jumlah besar, yang dapat menghabiskan banyak kapasitas disk dan menyebabkan peningkatan disk untuk instance dengan peningkatan penyimpanan otomatis diaktifkan. Sebaiknya Anda menyesuaikan ukuran penyimpanan instance untuk retensi log transaksi.

Lihat Menyetel retensi cadangan otomatis.

Lihat Menyetel retensi log transaksi.

Dapatkah saya mengekspor cadangan?

Tidak, Anda tidak dapat mengekspor cadangan. Anda hanya dapat mengekspor data instance. Lihat Mengekspor data dari Cloud SQL.

Tentang pengguna cadangan khusus

Cloud SQL membuat pengguna database khusus, cloudsqladmin, untuk setiap instance, dan membuat sandi khusus instance yang unik untuk instance tersebut. Cloud SQL login sebagai pengguna cloudsqladmin untuk melakukan pencadangan otomatis.

Pengaruh pencadangan terhadap operasi instance

Operasi tulis dan operasi lainnya tidak terpengaruh oleh operasi pencadangan.

Batasan kapasitas cadangan

Cloud SQL membatasi kapasitas operasi pencadangan di disk data. Anda diizinkan untuk memiliki maksimum lima operasi pencadangan setiap 50 menit per instance per project. Jika operasi pencadangan gagal, pencadangan tersebut tidak akan mengurangi kuota ini. Jika Anda mencapai batas, operasi akan gagal dengan pesan error yang memberi tahu kapan Anda dapat mencoba lagi.

Mari kita lihat cara Cloud SQL melakukan pembatasan kapasitas untuk pencadangan.

Cloud SQL menggunakan token dari bucket untuk menentukan jumlah operasi pencadangan yang tersedia pada satu waktu. Setiap instance memiliki bucket. Ada maksimum lima token di bucket yang dapat Anda gunakan untuk operasi pencadangan. Setiap 10 menit, token baru ditambahkan ke bucket. Jika bucket penuh, token akan meluap.

Setiap kali Anda melakukan operasi pencadangan, token akan diberikan dari bucket. Jika operasi berhasil, token akan dihapus dari bucket. Jika gagal, token akan dikembalikan ke bucket. Diagram berikut menunjukkan cara kerjanya:

Cara kerja token

Pemeriksaan pencadangan dan integritas data

Cloud SQL melakukan pemeriksaan integritas database latar belakang secara otomatis untuk mengidentifikasi potensi masalah integritas data. Pemeriksaan ini dilakukan sebagai proses offline dengan memulihkan sampling dari pencadangan atau cadangan pemulihan yang diinisiasi oleh pelanggan.

Cadangan pemulihan

Setelah instance dihapus, Cloud SQL akan menghapus semua cadangan. Untuk mencegah penghapusan instance secara tidak sengaja, Cloud SQL menyimpan cadangan instance selama empat hari. Untuk memulihkan instance yang dihapus, hubungi Layanan Pelanggan Google Cloud dalam waktu empat hari.

Cloud SQL menyimpan setidaknya satu cadangan harian terakhir yang bagus dari setiap instance aktif. Oleh karena itu, jika tidak ada cadangan berkualitas yang tersedia, Anda dapat menggunakan cadangan harian untuk memulihkan instance dengan menghubungi Layanan Pelanggan Google Cloud.

Tabel yang tidak dicatat

Tabel yang tidak dicatat akan otomatis dihapus total selama pemulihan cadangan.

Pemecahan masalah

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 gcloud sql operations list untuk mencantumkan semua operasi untuk instance Cloud SQL yang ditentukan.

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:

  • 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, 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 force restart instance.

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, dari 1 hingga 365. 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 memberitahukan 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.
  • 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.
Anda mendapati bahwa data Anda hilang saat melakukan operasi pencadangan/pemulihan. Tabel dibuat dalam keadaan tidak di-log. Contoh:

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 belum dicatat ke dalam log, Anda dapat membuang database tersebut ke sebuah file, dan memuat ulang data tersebut setelah mengubah file dump ke ALTER TABLE ke SET LOGGED di tabel tersebut.

Langkah selanjutnya