Ringkasan memulihkan instance

MySQL   |  PostgreSQL   |  SQL Server

Cloud SQL memungkinkan Anda memulihkan instance dari cadangan, atau dengan melakukan pemulihan point-in-time (PITR). Dengan begitu, Anda dapat 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 telah 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 dengan 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 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 pencadangan kustom atau menggunakan pencadangan yang ditingkatkan, Anda harus memperbarui konfigurasi pencadangan setelah pemulihan selesai.

Penting: Saat memulihkan cadangan ke instance yang ada, instance target harus memiliki setidaknya resource komputasi dan memori (vCPU dan RAM) yang sama dengan instance sumber tempat cadangan dibuat. Memulihkan cadangan ke instance dengan resource yang jauh lebih sedikit dapat menyebabkan operasi pemulihan gagal karena batasan resource selama startup dan pemulihan database. Anda mungkin melihat error seperti database failed to start after multiple retries.

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 sudah ada. Anda dapat menggunakan cadangan yang tersedia untuk memulihkan instance. Untuk mempelajari lebih lanjut cara kerja pencadangan di Cloud SQL, lihat Ringkasan pencadangan.

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

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

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

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

Memulihkan instance yang mendukung CMEK menggunakan pencadangan yang ditingkatkan

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

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

• Gunakan kunci Cloud KMS yang sama dengan instance asli. Ini adalah perilaku default.
• Pilih kunci Cloud KMS yang berbeda untuk instance target. Untuk memilih kunci yang berbeda, tetapkan flag --disk-encryption-key dalam perintah pemulihan.
• Kembalikan 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 tertentu dari database. Misalnya, jika error menyebabkan hilangnya 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 akan 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 konsol Google Cloud , PITR akan diaktifkan secara default. Jika Anda membuat instance Cloud SQL untuk MySQL dengan Ketersediaan tinggi diaktifkan, PITR juga akan diaktifkan secara default. Atau, 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.

Catatan: Untuk mempercepat pembuatan instance saat PITR diaktifkan, Cloud SQL menggunakan instant snapshot awal untuk PITR, bukan pencadangan standar. Snapshot ini nantinya akan dikonversi menjadi cadangan standar di latar belakang untuk mendukung operasi pemulihan.

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

Penyimpanan log untuk PITR

PITR menggunakan logging biner 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 11 Agustus 2023, kami meluncurkan penyimpanan log transaksi untuk PITR di Cloud Storage. Sejak peluncuran ini, kondisi berikut berlaku:

• Semua instance edisi Cloud SQL Enterprise Plus menyimpan log biner 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 telah mengaktifkan PITR sebelum 11 Agustus 2023 yang terus menyimpan log-nya untuk PITR di disk.

• Instance edisi Cloud SQL Enterprise yang dibuat dengan PITR diaktifkan sebelum 11 Agustus 2023 akan terus menyimpan lognya untuk PITR di disk.

  Catatan: Untuk instance yang dibuat sebelum 11 Agustus 2023, Cloud SQL akan otomatis mengalihkan lokasi log transaksi yang digunakan untuk PITR. Anda dapat menggunakan gcloud CLI atau Cloud SQL Admin API untuk memeriksa tempat penyimpanan log transaksi untuk instance Anda.

• Jika Anda mengupgrade instance edisi Cloud SQL Enterprise setelah 11 Agustus 2023 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 Anda. 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 11 Agustus 2023 akan menyimpan log yang digunakan untuk PITR di Cloud Storage.

Jika instance Anda menggunakan Cloud Storage untuk menyimpan log biner, 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, serta 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 biner 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 hilangnya log sebelumnya untuk PITR. Periode nonaktif terjadi karena instance harus dimulai ulang, dan log akan dihapus saat Anda menonaktifkan PITR.

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

• Memeriksa arsitektur jaringan instance. Jika instance berada di arsitektur jaringan lama, upgrade ke arsitektur jaringan baru.

• Jika ukuran log Anda 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 memerlukan pengaktifan ulang database.

Periode retensi log

Cloud SQL menyimpan log transaksi di Cloud Storage hingga nilai yang ditetapkan dalam setelan konfigurasi PITR transactionLogRetentionDays. 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 biner yang digunakan untuk PITR di Cloud Storage, instance juga menyimpan sejumlah kecil log biner duplikat di disk untuk memungkinkan replikasi log ke Cloud Storage. Secara default, saat Anda membuat instance dengan PITR diaktifkan, instance tersebut akan menyimpan log binernya 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 satu hari log di disk.

Untuk log biner PITR yang disimpan di disk, yang sedang dialihkan ke Cloud Storage, atau yang sudah dialihkan ke Cloud Storage, Cloud SQL akan mempertahankan log selama nilai minimum yang ditetapkan untuk salah satu konfigurasi berikut:

• Setelan konfigurasi pencadangan transactionLogRetentionDays
• Flag expire_logs_days atau binlog_expire_logs_seconds

Cloud SQL tidak menetapkan nilai apa pun untuk flag ini jika log biner disimpan di disk, sedang dialihkan ke Cloud Storage, atau telah dialihkan ke Cloud Storage. Jika log disimpan di disk, mengubah nilai flag ini dapat memengaruhi perilaku pemulihan PITR dan jumlah hari log yang disimpan di disk. Saat lokasi penyimpanan log dialihkan ke Cloud Storage, Anda tidak dapat mengubah nilai flag. Kami juga tidak menyarankan Anda mengonfigurasi salah satu nilai flag ke 0. Untuk mengetahui informasi selengkapnya, lihat Mengonfigurasi flag database.

Catatan: Jika instance Anda memiliki banyak log biner di disk dan Anda ingin menghemat kapasitas 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 sebanyak satu hari, setiap hari, selama beberapa hari. Akibatnya, Cloud SQL tidak menghapus semua log biner secara bersamaan.

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

Log dan penggunaan disk

Log dibuat secara rutin dan menggunakan ruang penyimpanan. Log biner akan dihapus secara otomatis dengan pencadangan otomatis terkait, yang terjadi setelah nilai yang ditetapkan untuk transactionLogRetentionDays terpenuhi.

Untuk mengetahui jumlah disk yang digunakan oleh log biner, periksa metrik bytes_used_by_data_type untuk instance. Nilai untuk jenis data binlog menampilkan ukuran binlog pada disk. Untuk instance yang menyimpan log transaksi yang digunakan untuk PITR di disk, Cloud SQL menghapus data dari disk setiap hari untuk memenuhi setelan PITR transactionLogRetentionDays, seperti yang dijelaskan dalam Pencadangan otomatis dan retensi log transaksi. Namun, jika Anda menetapkan flag expire_logs_days atau binlog_expire_logs_seconds ke nilai yang lebih rendah dari hari retensi log transaksi, Cloud SQL dapat menghapus log biner lebih cepat.

Jika ukuran log biner menyebabkan masalah pada instance Anda:

• Periksa apakah instance Anda menyimpan log di disk. Anda dapat mengalihkan lokasi penyimpanan log yang digunakan Cloud SQL untuk PITR dari disk ke Cloud Storage tanpa periode nonaktif menggunakan gcloud CLI atau Cloud SQL Admin API. Jika menggunakan edisi Cloud SQL Enterprise, Anda juga dapat mengupgrade ke edisi Cloud SQL Enterprise Plus untuk mengalihkan lokasi penyimpanan log PITR Anda.

• Anda dapat meningkatkan ukuran penyimpanan instance. Namun, peningkatan ukuran log biner dalam penggunaan disk mungkin bersifat sementara.

• Sebaiknya aktifkan peningkatan penyimpanan otomatis untuk menghindari masalah penyimpanan yang tidak terduga.

Untuk informasi selengkapnya tentang PITR, lihat Pemulihan point-in-time (PITR).

Setelah menyelesaikan pengalihan lokasi penyimpanan log transaksi ke Cloud Storage, Anda dapat mengosongkan kapasitas disk dengan mengurangi nilai flag expire_logs_days atau binlog_expire_logs_seconds. Untuk memeriksa status pengalihan, lihat Memeriksa lokasi penyimpanan log transaksi yang digunakan untuk PITR. Jika Anda ingin log tambahan tersedia di disk — misalnya, untuk menjelajahi log biner dengan utilitas mysqlbinlog — maka tingkatkan nilai flag ini. Cloud SQL mempertahankan log biner di disk selama jumlah hari retensi log transaksi minimum atau nilai yang ditetapkan untuk flag. Untuk mengetahui informasi selengkapnya tentang cara log untuk PITR disimpan setelah beralih dan cara mengosongkan kapasitas disk, lihat Log setelah beralih ke Cloud Storage.

Catatan: Beberapa instance yang dibuat antara Juni 2023 dan Agustus 2023 mungkin memiliki nilai flag expire_logs_days atau binlog_expire_logs_seconds yang ditetapkan secara otomatis ke setara dengan 7 hari.

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

• Jika ingin menghapus log dan memulihkan penyimpanan, Anda dapat menonaktifkan PITR tanpa mengaktifkannya kembali. Namun, mengurangi penyimpanan yang digunakan tidak akan mengurangi ukuran disk yang disediakan untuk instance.

• Log dihapus permanen sekali sehari, bukan terus-menerus. Menetapkan retensi log menjadi dua hari berarti setidaknya dua hari log, dan maksimal tiga hari log, akan dipertahankan. Sebaiknya tetapkan jumlah cadangan ke satu lebih dari jumlah hari retensi log.

  Misalnya, jika Anda menentukan 7 untuk nilai parameter transactionLogRetentionDays, maka untuk parameter backupRetentionSettings, tetapkan jumlah retainedBackups ke 8.

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

Memulihkan instance yang tidak tersedia

Anda dapat menggunakan PITR untuk memulihkan instance Cloud SQL yang tidak tersedia. PITR biasanya menawarkan objektif titik pemulihan (RPO) maksimum lima menit atau kurang.

Jika instance tidak tersedia, Anda dapat menggunakan API untuk mendapatkan waktu pemulihan paling awal dan terbaru kapan Anda dapat memulihkan instance dan melakukan pemulihan pada waktu tersebut. Jika zona tempat instance dikonfigurasi tidak dapat diakses, Anda dapat memulihkan instance ke zona utama atau sekunder yang berbeda dengan memberikan nilai untuk zona yang diinginkan.

Misalnya, instance Cloud SQL tidak tersedia pada pukul 16.00 EST. Jika waktu pemulihan terakhir adalah pada pukul 15.55 EST, maka Anda dapat memulihkan instance hingga waktu ini.

Memulihkan instance yang dihapus menggunakan PITR

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

Setelah instance dihapus, log PITR akan terus mengikuti setelan retensi yang ditentukan oleh instance saat aktif. Log PITR akan berakhir masa berlakunya berdasarkan setelan retensi secara berkelanjutan setelah instance dihapus. Periode yang berkelanjutan ditentukan berdasarkan periode retensi PITR yang ditetapkan pada instance sebelum penghapusan. 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 dipertahankan dapat diidentifikasi di Google Cloud dengan kolom berikut:

• instance_deletion_time
• log_retention_days

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

Periode pemulihan PITR didefinisikan sebagai waktu pemulihan paling awal dan paling akhir yang tersedia untuk memulihkan instance Anda menggunakan PITR. Untuk menemukan waktu pemulihan paling awal dan terbaru dari 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. Setiap cadangan yang dibuat selanjutnya akan mewarisi setelan storageAutoResize yang sama. Artinya, baik saat memulihkan cadangan ke instance baru maupun yang sudah ada, instance akan otomatis mengubah ukuran kapasitas penyimpanan sesuai kebutuhan. Fitur ini tidak diaktifkan pada instance lama. Untuk memeriksa setelan instance, lihat Melihat setelan instance.

• 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 sudah mencapai batas, operasi akan gagal dengan pesan error yang memberi tahu Anda kapan operasi dapat dijalankan kembali.

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)