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 jangka waktu 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 menyetelnya 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 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 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.

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 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 gangguan, Anda masih dapat mengambil daftar cadangan dalam project tertentu untuk dipulihkan.

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

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 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 secara manual.

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

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 binernya 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 11 Agustus 2023 yang akan terus menyimpan lognya 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 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 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 penyimpanan log transaksi 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:

• Periksa arsitektur jaringan instance. Jika instance menggunakan 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 dialihkan ke Cloud Storage, atau yang sudah dialihkan ke Cloud Storage, Cloud SQL akan menyimpan log untuk nilai minimum yang ditetapkan untuk salah satu konfigurasi berikut:

• Setelan konfigurasi pencadangan transactionLogRetentionDays
• Flag expire_logs_days atau flag 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. Saat 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 tanda. Sebaiknya Anda juga tidak mengonfigurasi nilai flag menjadi 0. Untuk mengetahui informasi selengkapnya, lihat Mengonfigurasi flag database.

Catatan: Jika instance Anda memiliki banyak log biner 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 biner secara bersamaan.

Untuk instance yang mengaktifkan kunci enkripsi yang dikelola pelanggan (CMEK), log biner 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 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 di 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, seperti yang dijelaskan dalam Pencadangan otomatis dan retensi log transaksi.transactionLogRetentionDays Namun, jika Anda menetapkan flag expire_logs_days atau binlog_expire_logs_seconds ke nilai yang lebih rendah daripada hari retensi log transaksi, Cloud SQL dapat menghapus log biner lebih awal.

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 waktu henti dengan 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 mengganti 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 mengetahui informasi selengkapnya tentang PITR, lihat Pemulihan point-in-time (PITR).

Setelah Anda menyelesaikan pengalihan lokasi penyimpanan log transaksi ke Cloud Storage, Anda dapat mengosongkan ruang 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 menyimpan log biner di disk selama minimal hari penyimpanan log transaksi atau nilai yang ditetapkan untuk flag. Untuk mengetahui informasi selengkapnya tentang cara log untuk PITR disimpan setelah peralihan dan cara mengosongkan ruang disk, lihat Log setelah peralihan ke Cloud Storage.

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

Batasan PITR

Batasan berikut terkait dengan instance Anda yang mengaktifkan PITR dan ukuran log transaksi Anda 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 semua 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 tersebut.

• 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 paling akhir 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 primer 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 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 dihapus. Untuk menggunakan fitur ini, instance Anda harus mengaktifkan PITR dan cadangan 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 instance tersebut aktif. Log PITR akan habis masa berlakunya berdasarkan setelan retensi secara berkelanjutan setelah instance dihapus. Periode bergulir 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, maka log PITR terbaru akan dihapus 14 hari setelah penghapusan instance. Setelah 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 ditentukan sebagai waktu pemulihan paling awal dan paling akhir 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.

• Kapasitas penyimpanan instance target setidaknya harus sebesar kapasitas instance yang dicadangkan. Jumlah penyimpanan yang digunakan tidak menjadi masalah. Anda dapat melihat kapasitas penyimpanan instance di konsol halaman instance Cloud SQL.

• 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 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)