Ringkasan memulihkan instance

MySQL   |  PostgreSQL   |  SQL Server

Cloud SQL memungkinkan Anda memulihkan instance dari cadangan, atau dengan melakukan pemulihan point-in-time (PITR). Hal ini memungkinkan Anda memulihkan instance ke periode atau waktu tertentu dengan memulihkan cadangan ke instance yang ada, atau memulihkan cadangan ke instance baru. Untuk memulihkan, Anda dapat menggunakan cadangan instance aktif atau yang dihapus. Operasi pemulihan mengambil setelan, database, dan pengguna instance sumber, lalu menetapkannya di instance target yang Anda pilih.

Saat Anda memulihkan ke instance baru, instance target dapat berada di region atau project yang berbeda dari instance sumber. Instance target juga dapat menggunakan jumlah core atau jumlah memori yang berbeda dari instance sumber.

Cloud SQL selalu menetapkan kapasitas penyimpanan instance target ke nilai maksimum ukuran disk yang dikonfigurasi dan disk cadangan. Disk cadangan merupakan ukuran disk saat cadangan diambil.

Saat melakukan pemulihan pada instance, pertimbangkan hal berikut:

• Operasi pemulihan akan menimpa semua data pada instance target.
• Flag dari instance sumber tidak dipulihkan. Setiap flag yang sebelumnya ditetapkan pada instance target akan dipertahankan setelah pemulihan.
• Instance target tidak tersedia untuk koneksi selama operasi pemulihan; koneksi yang ada akan terputus.
• Jika Anda memulihkan ke instance dengan replika baca, Anda harus menghapus semua replika dan membuatnya kembali setelah operasi pemulihan selesai.
• Operasi pemulihan akan memulai ulang instance.
• Setelah Anda memulihkan dari cadangan, konfigurasi cadangan instance target akan ditetapkan ke nilai default. Jika instance sumber Anda memiliki konfigurasi cadangan kustom atau menggunakan cadangan yang ditingkatkan, Anda harus memperbarui konfigurasi cadangan setelah pemulihan selesai.

Memulihkan menggunakan cadangan

Cloud SQL memungkinkan Anda memulihkan instance menggunakan cadangan. Anda dapat menggunakan cadangan dari instance aktif atau yang dihapus, dan menggunakannya untuk memulihkan ke instance baru atau yang ada. Anda dapat menggunakan cadangan yang tersedia untuk memulihkan instance. Untuk mempelajari lebih lanjut cara kerja cadangan di Cloud SQL, lihat Ringkasan cadangan.

Saat memulihkan instance menggunakan cadangan, Anda dapat melakukan hal berikut:

• Memulihkan ke instance baru
• Memulihkan ke instance yang ada
• Memulihkan ke instance di project atau region lain

Jika terjadi pemadaman layanan, Anda masih dapat mengambil a daftar cadangan di project tertentu untuk dipulihkan.

Untuk memulihkan instance menggunakan cadangan, lihat Memulihkan instance menggunakan cadangan.

Memulihkan instance yang mendukung CMEK menggunakan cadangan yang ditingkatkan

Saat Anda menggunakan instance yang mendukung CMEK dengan cadangan yang ditingkatkan, cadangan Anda akan dilindungi oleh CMEK yang sama dengan instance. Hal ini dapat menjadi bagian penting dari rencana cadangan Anda untuk instance yang memerlukan enkripsi CMEK karena mempertahankan cadangan terenkripsi CMEK Anda di project terpisah tempat cadangan dapat berhasil dipulihkan meskipun project workload asli Anda terganggu atau dihapus.

Saat Anda memulihkan cadangan yang ditingkatkan dari instance yang mendukung CMEK ke instance baru, Anda dapat memilih salah satu opsi enkripsi berikut untuk instance baru:

• Menggunakan kunci Cloud KMS yang sama dengan instance asli. Ini adalah perilaku default.
• Memilih kunci Cloud KMS yang berbeda untuk instance target. Untuk memilih kunci yang berbeda, tetapkan flag --disk-encryption-key dalam perintah pemulihan.
• Mengembalikan ke Google-owned and Google-managed encryption keys untuk instance target. Untuk menggunakan GMEK, tetapkan flag --clear-disk-encryption dalam perintah pemulihan.

Pemulihan point-in-time (PITR)

PITR memungkinkan Anda memulihkan instance ke waktu database tertentu. Misalnya, jika error menyebabkan kehilangan data, Anda dapat memulihkan database ke statusnya sebelum error terjadi. Tidak seperti pemulihan menggunakan cadangan, PITR selalu membuat instance baru. Anda tidak dapat melakukan PITR ke instance yang ada. Instance baru mewarisi setelan instance sumber, mirip dengan saat Anda membuat clone.

Jika Anda membuat instance edisi Cloud SQL Enterprise Plus, PITR akan diaktifkan secara default. Anda harus menonaktifkan fitur ini secara manual jika tidak ingin mengaktifkannya.

Jika Anda membuat instance edisi Cloud SQL Enterprise di Google Cloud konsol, PITR akan diaktifkan secara default. Jika tidak, jika Anda membuat instance menggunakan gcloud CLI, Terraform, atau Cloud SQL Admin API, PITR akan dinonaktifkan secara default. Untuk mengaktifkan PITR untuk instance ini, Anda harus mengaktifkannya secara manual.

Untuk petunjuk langkah demi langkah guna melakukan PITR, lihat Menggunakan pemulihan point-in-time (PITR).

Penyimpanan log untuk PITR

PITR menggunakan untuk mengarsipkan log. Saat Anda memulihkan instance yang ada menggunakan cadangan, log arsip ini akan dihapus dan tidak akan tersedia untuk melakukan PITR. Hanya log baru yang dibuat setelah pemulihan selesai yang dapat digunakan untuk PITR.

Pada 31 Mei 2024, kami meluncurkan penyimpanan log transaksi untuk PITR di Cloud Storage. Sejak peluncuran ini, ketentuan berikut berlaku:

• Semua instance edisi Cloud SQL Enterprise Plus menyimpan log transaksi yang digunakan untuk PITR di Cloud Storage. Hanya instance edisi Cloud SQL Enterprise Plus yang Anda upgrade dari edisi Cloud SQL Enterprise sebelum 1 April 2024 dan mengaktifkan PITR sebelum 31 Mei 2024 yang terus menyimpan log untuk PITR di disk.

• Instance edisi Cloud SQL Enterprise yang dibuat dengan PITR diaktifkan sebelum 31 Mei 2024 terus menyimpan log untuk PITR di disk.

  Catatan: Untuk instance yang dibuat sebelum 31 Mei 2024, Cloud SQL akan otomatis mengalihkan lokasi log transaksi yang digunakan untuk PITR untuk Anda. Anda dapat menggunakan gcloud CLI atau Cloud SQL Admin API untuk memeriksa tempat log transaksi disimpan untuk instance Anda.

• Jika Anda mengupgrade instance edisi Cloud SQL Enterprise setelah 31 Mei 2024 yang menyimpan log transaksi untuk PITR di disk ke edisi Cloud SQL Enterprise Plus, proses upgrade akan mengalihkan lokasi penyimpanan log transaksi yang digunakan untuk PITR ke Cloud Storage. Untuk mengetahui informasi selengkapnya, lihat Mengupgrade instance ke edisi Cloud SQL Enterprise Plus menggunakan upgrade langsung.

• Semua instance edisi Cloud SQL Enterprise yang Anda buat dengan PITR diaktifkan setelah 31 Mei 2024 menyimpan log yang digunakan untuk PITR di Cloud Storage.

Jika instance Anda menggunakan Cloud Storage untuk menyimpan log transaksi, log tersebut akan disimpan di region yang sama dengan instance utama. Log ini disimpan hingga 35 hari untuk edisi Cloud SQL Enterprise Plus dan 7 hari untuk edisi Cloud SQL Enterprise dan tidak menimbulkan biaya tambahan per instance.

Untuk mengetahui informasi selengkapnya tentang cara memeriksa lokasi penyimpanan log transaksi yang digunakan untuk PITR, lihat memeriksa tempat log transaksi disimpan untuk instance Anda.

Untuk instance yang menyimpan log transaksi hanya di disk, Anda dapat mengalihkan lokasi penyimpanan log transaksi yang digunakan untuk PITR dari disk ke Cloud Storage menggunakan gcloud CLI atau Cloud SQL Admin API. Untuk mengetahui informasi selengkapnya, lihat Mengalihkan penyimpanan log transaksi ke Cloud Storage.

Perhatian: Memindahkan log transaksi dari disk ke Cloud Storage akan menyebabkan periode nonaktif selama beberapa menit dan kehilangan log sebelumnya untuk PITR. Periode nonaktif terjadi karena instance harus dimulai ulang, dan log akan dihapus saat Anda menonaktifkan PITR.

Untuk memastikan log instance Anda disimpan di Cloud Storage, bukan di disk, selesaikan tindakan berikut:

• Periksa arsitektur jaringan instance. Jika instance menggunakan arsitektur jaringan lama, maka upgrade ke arsitektur jaringan baru.

• Jika ukuran log di disk menyebabkan masalah performa untuk instance Anda, nonaktifkan PITR dan aktifkan kembali. Tindakan ini memastikan bahwa log baru disimpan di Cloud Storage, bukan di disk.

  Perhatian: Jika Anda menonaktifkan dan mengaktifkan kembali PITR, semua log yang ada akan dihapus, dan Anda tidak akan dapat menjalankan PITR lebih awal dari waktu Anda mengaktifkannya kembali. Mengaktifkan dan menonaktifkan PITR mengharuskan database dimulai ulang.

Periode retensi log

Cloud SQL menyimpan log transaksi di Cloud Storage hingga nilai yang ditetapkan dalam transactionLogRetentionDays setelan konfigurasi PITR. Nilai ini dapat berkisar dari 1 hingga 35 hari untuk edisi Cloud SQL Enterprise Plus dan 1 hingga 7 hari untuk edisi Cloud SQL Enterprise. Jika nilai untuk parameter ini tidak ditetapkan, periode retensi log transaksi default adalah 14 hari untuk instance edisi Cloud SQL Enterprise Plus dan 7 hari untuk instance edisi Cloud SQL Enterprise. Untuk mengetahui informasi selengkapnya tentang cara menetapkan jumlah hari retensi log transaksi, lihat Menetapkan retensi log transaksi.

Meskipun instance menyimpan log transaksi yang digunakan untuk PITR di Cloud Storage, instance juga menyimpan log transaksi duplikat dalam jumlah yang lebih kecil di disk untuk memungkinkan replikasi log ke Cloud Storage. Secara default, saat Anda membuat instance dengan PITR diaktifkan, instance akan menyimpan log transaksinya untuk PITR di Cloud Storage. Cloud SQL juga menetapkan nilai flag expire_logs_days dan binlog_expire_logs_seconds ke nilai yang setara dengan satu hari secara otomatis. Hal ini berarti log selama satu hari di disk.

Untuk log transaksi PITR yang disimpan di disk, yang dialihkan ke Cloud Storage, atau yang sudah dialihkan ke Cloud Storage, Cloud SQL menyimpan log untuk nilai minimum yang ditetapkan untuk salah satu konfigurasi berikut:

• Setelan konfigurasi cadangan transactionLogRetentionDays
• Flag expire_logs_days atau binlog_expire_logs_seconds

Cloud SQL tidak menetapkan nilai apa pun untuk flag ini jika log transaksi disimpan di disk, dialihkan ke Cloud Storage, atau sudah dialihkan ke Cloud Storage. Saat log disimpan di disk, mengubah nilai flag ini dapat memengaruhi perilaku pemulihan PITR dan jumlah log yang disimpan di disk. Saat lokasi penyimpanan log dialihkan ke Cloud Storage, Anda tidak dapat mengubah nilai flag. Sebaiknya jangan mengonfigurasi nilai flag menjadi 0. Untuk mengetahui informasi selengkapnya, lihat Mengonfigurasi flag database.

Catatan: Jika instance Anda memiliki log transaksi dalam jumlah besar di disk dan Anda ingin menghemat ruang disk, sebaiknya kurangi nilai berikut secara perlahan:

• Setelan konfigurasi transactionLogRetentionDays
• Flag database expire_logs_days
• Flag database binlog_expire_logs_seconds

Misalnya, untuk mencegah masalah performa, kurangi nilai flag satu hari setiap hari selama beberapa hari. Akibatnya, Cloud SQL tidak menghapus semua log transaksi secara bersamaan.

Untuk instance yang mengaktifkan kunci enkripsi yang dikelola pelanggan (CMEK), log transaksi akan dienkripsi menggunakanCMEK versi terbaru. Untuk melakukan pemulihan, versi kunci terbaru diperlukan untuk semua hari yang disimpan sebagai bagian dari parameter retained-transaction-log-days.

Batasan PITR

Batasan berikut terkait dengan instance Anda yang mengaktifkan PITR dan ukuran log transaksi di disk yang menyebabkan masalah pada instance Anda:

• Anda dapat menonaktifkan PITR dan mengaktifkannya kembali untuk memastikan Cloud SQL menyimpan log di Cloud Storage di region yang sama dengan instance. Namun, Cloud SQL akan menghapus log yang ada sehingga Anda tidak dapat melakukan operasi PITR lebih awal dari waktu Anda mengaktifkan kembali PITR.
• Anda dapat meningkatkan ukuran penyimpanan instance, tetapi peningkatan ukuran log transaksi dalam penggunaan disk mungkin bersifat sementara.
• Untuk menghindari masalah penyimpanan yang tidak terduga, sebaiknya aktifkan peningkatan penyimpanan otomatis. Rekomendasi ini hanya berlaku jika instance Anda mengaktifkan PITR dan log Anda disimpan di disk.

• Pemulihan point-in-time (PITR) tidak dapat diaktifkan di instance Cloud SQL tujuan jika memiliki beberapa database dengan nama fisik yang sama.

Snapshot database

Anda tidak dapat menggunakan snapshot database SQL Server di database mana pun dalam instance yang mengaktifkan PITR.

Snapshot database dapat mengganggu pencadangan database lengkap dan pencadangan log transaksi yang digunakan PITR. Gangguan ini dapat mencegah operasi PITR berhasil untuk database apa pun di instance.

Model pemulihan database untuk PITR

Jika Anda mengaktifkan PITR pada suatu instance, Cloud SQL akan otomatis menetapkan model pemulihan dari database yang ada dan database berikutnya ke model pemulihan penuh.

Perhatian: Setelah mengaktifkan PITR pada instance, jangan mengubah model pemulihan database menjadi Sederhana. Hal ini dapat merusak rantai pencadangan log transaksi, dan Anda mungkin tidak dapat memulihkan data instance ke titik saat model pemulihan disetel ke Sederhana.

Untuk informasi selengkapnya tentang model pemulihan SQL Server, baca dokumentasi Microsoft.

Untuk petunjuk langkah demi langkah guna melakukan PITR, lihat [Menggunakan pemulihan point-in-time (PITR)][perform-pitr].

Memulihkan instance yang dihapus menggunakan PITR

Anda dapat menggunakan PITR untuk memulihkan instance Cloud SQL setelah dihapus. Untuk menggunakan fitur ini, instance Anda harus mengaktifkan PITR dan cadangan yang disimpan sebelum instance dihapus. Jika diaktifkan, log PITR akan disimpan setelah Anda menghapus instance.

Setelah instance dihapus, log PITR akan terus mengikuti setelan retensi yang ditentukan oleh instance saat aktif. Log PITR akan habis masa berlakunya berdasarkan setelan retensi secara bergilir setelah instance dihapus. Periode bergilir ditentukan berdasarkan periode retensi data PITR yang ditetapkan pada instance sebelum dihapus. Misalnya, jika instance edisi Cloud SQL Enterprise Plus Anda memiliki retensi PITR yang ditetapkan ke 14 hari, log PITR terbaru akan dihapus 14 hari setelah penghapusan instance. Saat masa berlaku log PITR berakhir, log tersebut tidak dapat dipulihkan.

Karena nama instance dapat digunakan kembali setelah instance dihapus di Cloud SQL, log PITR yang disimpan dapat diidentifikasi di Google Cloud dengan kolom berikut:

• instance_deletion_time
• log_retention_days

Kolom ini memungkinkan Anda mengidentifikasi apakah log PITR termasuk instance yang dihapus.

Periode pemulihan PITR ditentukan sebagai waktu pemulihan paling awal dan terbaru yang tersedia untuk memulihkan instance Anda menggunakan PITR. Untuk menemukan waktu pemulihan paling awal dan terbaru instance yang dihapus, lihat Mendapatkan waktu pemulihan paling awal dan terbaru.

Untuk memulihkan instance menggunakan PITR setelah penghapusan instance, lihat Melakukan PITR pada instance yang dihapus.

Persyaratan untuk memulihkan ke instance baru

Saat Anda memulihkan instance ke instance baru, perhatikan persyaratan berikut:

• Instance target harus memiliki versi database yang sama dengan instance tempat cadangan diambil.

• Saat membuat instance baru, fitur storageAutoResize diaktifkan secara default. Cadangan yang dibuat berikutnya akan mewarisi setelan storageAutoResize yang sama. Artinya, baik memulihkan cadangan ke instance baru atau yang ada, instance akan otomatis mengubah ukuran kapasitas penyimpanan sesuai kebutuhan. Instance lama tidak mengaktifkan fitur ini. Untuk memeriksa setelan instance, lihat Melihat setelan instance. Persyaratan ini berlaku terlepas dari apakah Anda melakukan PITR database tunggal atau tidak.

• Instance target harus dalam status RUNNABLE.

Memulihkan batasan kapasitas

Anda dapat melakukan maksimum tiga operasi pemulihan setiap 30 menit per instance per region per project. Jika operasi pemulihan gagal, operasi tersebut tidak akan dihitung dalam kuota ini. Jika Anda mencapai batas, operasi akan gagal dengan pesan error yang memberi tahu kapan Anda dapat menjalankan operasi lagi.

Cloud SQL menggunakan token dari bucket untuk menentukan jumlah operasi pemulihan yang tersedia pada satu waktu. Untuk setiap cadangan, ada bucket untuk setiap project target dan region target. Instance target dari project yang sama menggunakan satu bucket jika berada di region yang sama. Ada maksimum tiga token di setiap bucket yang dapat Anda gunakan untuk operasi pemulihan. Setiap 10 menit, token baru ditambahkan ke bucket. Jika bucket penuh, token akan meluap.

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

Misalnya, dalam gambar berikut, Cadangan1, Cadangan2, dan Cadangan3 adalah cadangan dari instance sumber yang sama.

• Setiap cadangan (Cadangan1, Cadangan2, dan Cadangan3) memiliki bucket token sendiri untuk operasi pemulihan yang menargetkan berbagai instance dalam Project 1 di Region A (Cadangan11A, Cadangan21A, dan Cadangan31A). Karena setiap cadangan memiliki bucket sendiri, Anda dapat memulihkan setiap cadangan ke instance yang sama tiga kali setiap tiga puluh menit.
• Setiap cadangan memiliki bucket untuk project terpisah dan untuk region terpisah. Misalnya, jika ada lima project di satu region, ada lima bucket untuk cadangan itu di region tersebut, satu di setiap project. Pada gambar sebelumnya, kita memiliki dua project di region A: Project 1 dan Project n.
  • Cadangan1 memiliki dua bucket token untuk operasi pemulihan di Region A. Satu bucket untuk Project 1 (Bucket11A), dan satu bucket untuk Project n (Bucket1nA).
  • Demikian pula, Cadangan3 memiliki dua bucket untuk operasi pemulihan di Region A. Satu untuk project 1 (Bucket31A) dan satu untuk project n (Bucket3nA).
• Cadangan3 memiliki satu bucket di Region B, untuk Project1, karena semua instance dalam project target yang sama dan region target yang sama menggunakan satu bucket.

Langkah berikutnya

• Melakukan pemulihan dari cadangan
• Menggunakan pemulihan point-in-time (PITR)