Halaman ini menjelaskan cara menggunakan pemulihan point-in-time (PITR) untuk memulihkan instance Cloud SQL utama Anda.
Untuk mempelajari PITR lebih lanjut, lihat Pemulihan point-in-time (PITR).
Secara default, PITR diaktifkan saat Anda membuat instance edisi Cloud SQL Enterprise Plus, terlepas dari apakah Anda membuat instance menggunakan konsol Google Cloud, gcloud CLI, Terraform, atau Cloud SQL Admin API.
Jika Anda membuat instance edisi Cloud SQL Enterprise di konsol Google Cloud, PITR akan diaktifkan secara default. Jika tidak, jika Anda membuat instance menggunakan gcloud CLI, Terraform, atau Cloud SQL Admin API, Anda harus mengaktifkan PITR secara manual.
Penyimpanan log untuk PITR
Cloud SQL menggunakan log biner 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.
Jika Anda mengupgrade instance edisi Cloud SQL Enterprise setelah 1 April 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 Anda. Untuk 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.
Untuk mengetahui informasi selengkapnya tentang cara memeriksa lokasi penyimpanan log transaksi yang digunakan untuk PITR, lihat Memeriksa lokasi penyimpanan log transaksi yang digunakan untuk PITR.
Untuk instance yang hanya menyimpan log biner di disk, Anda dapat mengganti lokasi penyimpanan log transaksi yang digunakan untuk PITR dari disk ke Cloud Storage menggunakan gcloud CLI atau Cloud SQL Admin API tanpa menimbulkan downtime. Untuk informasi selengkapnya, lihat Mengganti penyimpanan log transaksi ke Cloud Storage.
Periode retensi log
Cloud SQL mempertahankan log transaksi di Cloud Storage hingga
nilai yang ditetapkan di 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 log biner 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 binernya untuk PITR di Cloud Storage. Cloud SQL juga menetapkan nilai
flag expire_logs_days
dan binlog_expire_logs_seconds
ke setara dengan satu hari secara otomatis. Ini berarti satu hari log di disk.
Untuk log biner PITR yang disimpan di disk, yang dialih ke Cloud Storage, atau yang sudah dialihkan ke Cloud Storage, Cloud SQL akan mempertahankan log untuk nilai minimum yang ditetapkan untuk salah satu konfigurasi berikut:
- Setelan konfigurasi pencadangan
transactionLogRetentionDays
Flag
expire_logs_days
ataubinlog_expire_logs_seconds
Cloud SQL tidak menetapkan nilai apa pun untuk flag ini jika log biner disimpan di disk, 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. Anda tidak dapat mengubah nilai ini saat lokasi penyimpanan log sedang dalam proses dialihkan ke Cloud Storage. Sebaiknya Anda juga tidak mengonfigurasi nilai salah satu tanda ini ke
0
. Untuk mengetahui informasi selengkapnya tentang flag ini, lihat Mengonfigurasi flag database.
Untuk
instance yang mengaktifkan kunci enkripsi yang dikelola pelanggan (CMEK),
log biner akan dienkripsi menggunakanCMEK versi terbaru. Untuk melakukan pemulihan, semua versi kunci yang merupakan versi terbaru untuk
jumlah hari yang Anda konfigurasi untuk
parameter
retained-transaction-log-days
harus tersedia.
Log dan penggunaan disk
Log dibuat secara rutin dan menggunakan ruang penyimpanan. Log biner
akan otomatis dihapus 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 akan 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 mengganti lokasi penyimpanan log yang digunakan untuk PITR dari disk ke Cloud Storage tanpa downtime 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 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.
Jika ingin menghapus log dan memulihkan ruang penyimpanan di disk, 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 parametertransactionLogRetentionDays
, untuk parameterbackupRetentionSettings
, tetapkan jumlahretainedBackups
ke8
.
Untuk informasi selengkapnya tentang PITR, lihat Pemulihan point-in-time (PITR).
Setelah 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 tombol, lihat
Memeriksa lokasi penyimpanan log transaksi yang digunakan untuk PITR.
Jika Anda ingin log tambahan tersedia
di disk—misalnya, untuk membuka log biner dengan
utilitas mysqlbinlog
—
tingkatkan nilai tanda ini. Cloud SQL mempertahankan log biner di disk selama minimum hari retensi log transaksi atau nilai yang ditetapkan untuk flag. Untuk informasi selengkapnya tentang cara log untuk PITR disimpan setelah peralihan dan cara mengosongkan ruang disk, lihat Log setelah peralihan ke Cloud Storage.
Mengaktifkan PITR
Saat Anda membuat instance baru di konsol Google Cloud, baik Pencadangan otomatis dan Aktifkan pemulihan point-in-time akan diaktifkan secara otomatis.Prosedur berikut memungkinkan PITR pada instance utama yang sudah ada.
Konsol
-
Di konsol Google Cloud, buka halaman Instance Cloud SQL.
- Buka menu tindakan lainnya untuk instance yang ingin Anda aktifkan PITR, lalu klik Edit.
- Di bagian Customize your instance, luaskan bagian Data Protection.
- Pilih kotak centang Aktifkan pemulihan point-in-time.
- Di kolom Days of logs, masukkan jumlah hari untuk menyimpan log, dari 1-35 untuk edisi Cloud SQL Enterprise Plus, atau 1-7 untuk edisi Cloud SQL Enterprise.
- Klik Simpan.
gcloud
- Tampilkan ringkasan instance:
gcloud sql instances describe INSTANCE_NAME
- Jika Anda melihat
enabled: false
di bagianbackupConfiguration
, aktifkan pencadangan terjadwal:gcloud sql instances patch INSTANCE_NAME \ --backup-start-time=HH:MM
Tentukan parameter
backup-start-time
menggunakan waktu 24 jam dalam zona waktu UTC±00. - Mengaktifkan PITR:
gcloud sql instances patch INSTANCE_NAME \ --enable-bin-log
Jika Anda mengaktifkan PITR pada instance utama, Anda juga dapat mengonfigurasi jumlah hari saat Anda ingin mempertahankan log transaksi dengan menambahkan parameter berikut:
--retained-transaction-log-days=RETAINED_TRANSACTION_LOG_DAYS
- Konfirmasi perubahan Anda:
gcloud sql instances describe INSTANCE_NAME
Di bagian
backupConfiguration
, Anda akan melihatbinaryLogEnabled: true
jika perubahan berhasil.
Terraform
Untuk mengaktifkan PITR, gunakan resource Terraform.
Menerapkan perubahan
Untuk menerapkan konfigurasi Terraform di project Google Cloud, selesaikan langkah-langkah di bagian berikut.
Menyiapkan Cloud Shell
- Luncurkan Cloud Shell.
-
Tetapkan project Google Cloud default tempat Anda ingin menerapkan konfigurasi Terraform.
Anda hanya perlu menjalankan perintah ini sekali per project, dan dapat dijalankan di direktori mana pun.
export GOOGLE_CLOUD_PROJECT=PROJECT_ID
Variabel lingkungan akan diganti jika Anda menetapkan nilai eksplisit dalam file konfigurasi Terraform.
Menyiapkan direktori
Setiap file konfigurasi Terraform harus memiliki direktorinya sendiri (juga disebut modul root).
-
Di Cloud Shell, buat direktori dan file baru di dalam direktori tersebut. Nama file harus memiliki
ekstensi
.tf
—misalnyamain.tf
. Dalam tutorial ini, file ini disebut sebagaimain.tf
.mkdir DIRECTORY && cd DIRECTORY && touch main.tf
-
Jika mengikuti tutorial, Anda dapat menyalin kode contoh di setiap bagian atau langkah.
Salin kode contoh ke dalam
main.tf
yang baru dibuat.Atau, salin kode dari GitHub. Tindakan ini direkomendasikan jika cuplikan Terraform adalah bagian dari solusi menyeluruh.
- Tinjau dan ubah contoh parameter untuk diterapkan pada lingkungan Anda.
- Simpan perubahan Anda.
-
Lakukan inisialisasi Terraform. Anda hanya perlu melakukan ini sekali per direktori.
terraform init
Secara opsional, untuk menggunakan versi penyedia Google terbaru, sertakan opsi
-upgrade
:terraform init -upgrade
Menerapkan perubahan
-
Tinjau konfigurasi dan pastikan resource yang akan dibuat atau
diupdate oleh Terraform sesuai yang Anda inginkan:
terraform plan
Koreksi konfigurasi jika diperlukan.
-
Terapkan konfigurasi Terraform dengan menjalankan perintah berikut dan memasukkan
yes
pada prompt:terraform apply
Tunggu hingga Terraform menampilkan pesan "Apply complete!".
- Buka project Google Cloud Anda untuk melihat hasilnya. Di Konsol Google Cloud, buka resource Anda di UI untuk memastikan bahwa Terraform telah membuat atau mengupdatenya.
Menghapus perubahan
Untuk menghapus perubahan Anda, lakukan langkah-langkah berikut:
- Untuk menonaktifkan perlindungan penghapusan, di file konfigurasi Terraform Anda, tetapkan
argumen
deletion_protection
kefalse
.deletion_protection = "false"
- Terapkan konfigurasi Terraform dengan menjalankan perintah berikut dan
memasukkan
yes
pada prompt:terraform apply
-
Hapus resource yang sebelumnya diterapkan dengan konfigurasi Terraform Anda dengan menjalankan perintah berikut dan memasukkan
yes
pada prompt:terraform destroy
REST v1
Sebelum menggunakan salah satu data permintaan, lakukan penggantian berikut:
- PROJECT_ID: ID atau nomor project project Google Cloud yang berisi instance
- INSTANCE_NAME: nama instance replika utama atau baca yang Anda konfigurasikan untuk ketersediaan tinggi
- START_TIME: waktu (dalam jam dan menit)
Metode HTTP dan URL:
PATCH https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME
Meminta isi JSON:
{ "settings": { "backupConfiguration": { "startTime": "START_TIME", "enabled": true, "binaryLogEnabled": true } } }
Untuk mengirim permintaan Anda, perluas salah satu opsi berikut:
Anda akan menerima respons JSON yang mirip dengan yang berikut ini:
REST v1beta4
Sebelum menggunakan salah satu data permintaan, lakukan penggantian berikut:
- PROJECT_ID: ID atau nomor project project Google Cloud yang berisi instance
- INSTANCE_NAME: nama instance replika utama atau baca yang Anda konfigurasikan untuk ketersediaan tinggi
- START_TIME: waktu (dalam jam dan menit)
Metode HTTP dan URL:
PATCH https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/INSTANCE_NAME
Meminta isi JSON:
{ "settings": { "backupConfiguration": { "startTime": "START_TIME", "enabled": true, "binaryLogEnabled": true } } }
Untuk mengirim permintaan Anda, perluas salah satu opsi berikut:
Anda akan menerima respons JSON yang mirip dengan yang berikut ini:
Melakukan PITR dengan menggunakan stempel waktu
Menggunakan stempel waktu adalah pendekatan yang direkomendasikan untuk melakukan
PITR.
Cloud SQL menggunakan utilitas mysqlbinlog
untuk memulihkan
instance hingga waktu tertentu. Untuk informasi selengkapnya tentang utilitas mysqlbinlog
, lihat dokumentasi referensi MySQL.
Untuk menyelesaikan tugas berikut, Anda harus memiliki hal berikut:
- Pencadangan dan logging biner diaktifkan untuk instance, dengan log biner berkelanjutan sejak pencadangan terakhir sebelum peristiwa yang ingin Anda pulihkan. Untuk informasi selengkapnya, lihat Mengaktifkan logging biner.
- Stempel waktu untuk menentukan titik pemulihan. Peristiwa yang terjadi pada dan setelah stempel waktu ini tidak tercermin dalam instance baru.
Konsol
-
Di konsol Google Cloud, buka halaman Instance Cloud SQL.
- Buka menu tindakan lainnya untuk instance yang ingin pulihkan, lalu klik Create clone.
- Secara opsional, di halaman Create a clone, perbarui ID clone baru tersebut.
- Pilih Clone dari titik waktu sebelumnya.
- Masukkan waktu PITR.
- Klik Buat clone.
gcloud
Membuat clone menggunakan PITR.
Ganti kode berikut:
- SOURCE_INSTANCE_NAME - Nama instance tempat Anda memulihkan.
- NEW_INSTANCE_NAME - Nama untuk clone.
- TIMESTAMP - Zona waktu UTC untuk instance sumber dalam format RFC 3339. Misalnya, 2012-11-15T16:19:00.094Z.
gcloud sql instances clone SOURCE_INSTANCE_NAME \ NEW_INSTANCE_NAME \ --point-in-time 'TIMESTAMP'
REST v1
Sebelum menggunakan salah satu dari data permintaan, lakukan penggantian berikut:
- project-id: ID project
- target-instance-id: ID instance target
- source-instance-id: ID instance sumber
- restore-timestamp Point-in-time untuk memulihkan hingga
Metode HTTP dan URL:
POST https://sqladmin.googleapis.com/v1/projects/project-id/instances/source-instance-id/clone
Meminta isi JSON:
{ "cloneContext": { "kind": "sql#cloneContext", "destinationInstanceName": "target-instance-id", "pointInTime": "restore-timestamp" } }
Untuk mengirim permintaan Anda, perluas salah satu opsi berikut:
Anda akan menerima respons JSON yang mirip dengan yang berikut ini:
REST v1beta4
Sebelum menggunakan salah satu dari data permintaan, lakukan penggantian berikut:
- project-id: ID project
- target-instance-id: ID instance target
- source-instance-id: ID instance sumber
- restore-timestamp Point-in-time untuk memulihkan hingga
Metode HTTP dan URL:
POST https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/source-instance-id/clone
Meminta isi JSON:
{ "cloneContext": { "kind": "sql#cloneContext", "destinationInstanceName": "target-instance-id", "pointInTime": "restore-timestamp" } }
Untuk mengirim permintaan Anda, perluas salah satu opsi berikut:
Anda akan menerima respons JSON yang mirip dengan yang berikut ini:
Menonaktifkan PITR
Konsol
-
Di konsol Google Cloud, buka halaman Instance Cloud SQL.
- Buka menu tindakan lainnya untuk instance yang ingin Anda nonaktifkan, lalu pilih Edit.
- Di bawah Customize your instance, luaskan bagian Data Protection.
- Hapus opsi Aktifkan pemulihan point-in-time.
- Klik Simpan.
gcloud
- Nonaktifkan pemulihan point-in-time:
gcloud sql instances patch INSTANCE_NAME \ --no-enable-bin-log
- Konfirmasi perubahan Anda:
gcloud sql instances describe INSTANCE_NAME
Di bagian
backupConfiguration
, Anda akan melihatbinaryLogEnabled: false
jika perubahan berhasil.
REST v1
Sebelum menggunakan salah satu dari data permintaan, lakukan penggantian berikut:
- project-id: ID project
- instance-id: ID instance
Metode HTTP dan URL:
PATCH https://sqladmin.googleapis.com/v1/projects/project-id/instances/instance-id
Meminta isi JSON:
{ "settings": { "backupConfiguration": { "enabled": false, "binaryLogEnabled": false } } }
Untuk mengirim permintaan Anda, perluas salah satu opsi berikut:
Anda akan menerima respons JSON yang mirip dengan yang berikut ini:
REST v1beta4
Sebelum menggunakan salah satu dari data permintaan, lakukan penggantian berikut:
- project-id: ID project
- instance-id: ID instance
Metode HTTP dan URL:
PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id
Meminta isi JSON:
{ "settings": { "backupConfiguration": { "enabled": false, "binaryLogEnabled": false } } }
Untuk mengirim permintaan Anda, perluas salah satu opsi berikut:
Anda akan menerima respons JSON yang mirip dengan yang berikut ini:
Memeriksa lokasi penyimpanan log transaksi yang digunakan untuk PITR
Anda dapat memeriksa tempat instance Cloud SQL menyimpan log transaksi yang digunakan untuk PITR.
gcloud
Untuk menentukan apakah instance Anda menyimpan log untuk PITR di disk atau Cloud Storage, gunakan perintah berikut:
gcloud sql instances describe INSTANCE_NAME
Ganti INSTANCE_NAME dengan nama instance.
Anda juga dapat memeriksa lokasi penyimpanan log transaksi untuk beberapa instance dalam project yang sama. Untuk menentukan lokasi beberapa instance, gunakan perintah berikut:
gcloud sql instances list --show-transactional-log-storage-state
Contoh respons:
NAME DATABASE_VERSION LOCATION TRANSACTIONAL_LOG_STORAGE_STATE my_01 MYSQL_8_0 us-central-1 DISK my_02 MYSQL_8_0 us-central-1 CLOUD_STORAGE ...
Dalam output perintah, kolom transactionalLogStorageState
atau kolom TRANSACTIONAL_LOG_STORAGE_STATE
memberikan informasi tentang tempat log transaksi untuk PITR disimpan untuk instance.
Status penyimpanan log transaksi yang mungkin terjadi adalah sebagai berikut:
DISK
: instance menyimpan log transaksi yang digunakan untuk PITR di disk. Jika Anda mengupgrade instance edisi Cloud SQL Enterprise ke edisi Cloud SQL Enterprise Plus, proses upgrade akan otomatis mengalihkan lokasi penyimpanan log ke Cloud Storage. Untuk informasi selengkapnya, lihat Mengupgrade instance ke edisi Cloud SQL Enterprise Plus menggunakan upgrade langsung. Anda juga dapat memilih untuk mengalihkan lokasi penyimpanan menggunakan gcloud CLI atau Cloud SQL Admin API tanpa mengupgrade edisi instance dan tanpa menimbulkan periode nonaktif. Untuk informasi selengkapnya, lihat Mengganti penyimpanan log transaksi ke Cloud Storage.SWITCHING_TO_CLOUD_STORAGE
: instance mengalihkan lokasi penyimpanan untuk log transaksi PITR ke Cloud Storage.SWITCHED_TO_CLOUD_STORAGE
: instance telah menyelesaikan pengalihan lokasi penyimpanan untuk log transaksi PITR dari disk ke Cloud Storage.CLOUD_STORAGE
: instance menyimpan log transaksi yang digunakan untuk PITR di Cloud Storage.
Mengalihkan penyimpanan log transaksi ke Cloud Storage
Jika instance Anda menyimpan log transaksi yang digunakan untuk PITR di disk, Anda dapat mengalihkan lokasi penyimpanan ke Cloud Storage tanpa mengalami periode nonaktif. Proses keseluruhan untuk beralih lokasi penyimpanan memerlukan waktu sekitar durasi periode retensi log transaksi (hari) untuk diselesaikan. Segera setelah Anda memulai tombol, log transaksi akan mulai bertambah di Cloud Storage. Selama operasi, Anda dapat memeriksa status keseluruhan proses menggunakan perintah di Memeriksa lokasi penyimpanan log transaksi yang digunakan untuk PITR.
Setelah keseluruhan proses peralihan ke Cloud Storage selesai, Cloud SQL akan menggunakan log transaksi dari Cloud Storage untuk PITR.
gcloud
Untuk mengalihkan lokasi penyimpanan ke Cloud Storage, gunakan perintah berikut:
gcloud sql instances patch INSTANCE_NAME \ --switch-transaction-logs-to-cloud-storage
Ganti INSTANCE_NAME dengan nama instance. Instance harus berupa instance utama, bukan instance replika. Responsnya mirip dengan hal berikut ini:
The following message is used for the patch API method. {"name": "INSTANCE_NAME", "project": "PROJECT_NAME", "switchTransactionalLogsToCloudStorageEnabled": "true"} Patching Cloud SQL instance...done. Updated [https://sqladmin.prod.googleapis.com/v1/projects/PROJECT_NAME/instances/INSTANCE_NAME].
Jika perintah menampilkan error, lihat Memecahkan masalah peralihan ke Cloud Storage untuk mengetahui kemungkinan langkah berikutnya.
REST v1
Sebelum menggunakan salah satu data permintaan, lakukan penggantian berikut:
- PROJECT_ID: project ID.
- INSTANCE_ID: ID instance. Instance harus berupa instance utama, bukan instance replika.
Metode HTTP dan URL:
PATCH https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID
Meminta isi JSON:
{ "switchTransactionLogsToCloudStorageEnabled": true }
Untuk mengirim permintaan Anda, perluas salah satu opsi berikut:
Anda akan menerima respons JSON yang mirip dengan yang berikut ini:
Jika permintaan menampilkan error, lihat Memecahkan masalah peralihan ke Cloud Storage untuk mengetahui kemungkinan langkah berikutnya.
REST v1beta4
Sebelum menggunakan salah satu data permintaan, lakukan penggantian berikut:
- PROJECT_ID: project ID.
- INSTANCE_ID: ID instance. Instance harus berupa instance utama, bukan instance replika.
Metode HTTP dan URL:
PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID
Meminta isi JSON:
{ "switchTransactionLogsToCloudStorageEnabled": true }
Untuk mengirim permintaan Anda, perluas salah satu opsi berikut:
Anda akan menerima respons JSON yang mirip dengan yang berikut ini:
Jika permintaan menampilkan error, lihat Memecahkan masalah peralihan ke Cloud Storage untuk mengetahui kemungkinan langkah berikutnya.
Penyimpanan dan konfigurasi log transaksi setelah peralihan
Setelah proses pengalihan ke Cloud Storage selesai untuk instance,
Cloud SQL masih menyimpan salinan log biner di disk untuk tujuan replikasi.
Menyimpan log biner di disk dapat berguna
jika Anda ingin menjelajahi log biner dengan utilitas mysqlbinlog
.
Jika Anda mengonfigurasi flag expire_logs_days
atau
binlog_expire_logs_seconds
di instance sebelum beralih, nilai yang dikonfigurasi akan tetap sama.
Setelah beralih, karena log biner yang digunakan untuk melakukan PITR kini disimpan di Cloud Storage, pastikan nilai flag mencerminkan retensi log transaksi di disk yang Anda harapkan. Cloud SQL hanya menyimpan log di disk untuk nilai minimum salah satu dari hal berikut:
- setelan konfigurasi PITR
transactionLogRetentionDays
sebelum beralih. Nilai default untuk setelan ini adalah 7 hari. - flag
expire_logs_days
ataubinlog_expire_logs_seconds
yang Anda tetapkan pada instance secara manual.
Jika Anda ingin menghemat ruang disk, setelah proses pengalihan selesai, konfigurasikan nilai tanda expire_logs_days
atau binlog_expire_logs_seconds
menjadi 1 hari untuk mengurangi ukuran disk yang dialokasikan dan biaya penyimpanan disk. Untuk informasi selengkapnya tentang
penyimpanan log transaksi dan PITR,
lihat Penyimpanan log untuk PITR.
Untuk mengetahui informasi selengkapnya tentang cara memeriksa penggunaan disk, lihat Log dan penggunaan disk.
Menetapkan retensi log transaksi
Untuk menetapkan jumlah hari untuk menyimpan log biner:
Konsol
-
Di konsol Google Cloud, buka halaman Instance Cloud SQL.
- Buka menu tindakan lainnya untuk instance yang ingin Anda gunakan untuk menetapkan log transaksi, lalu pilih Edit.
- Di bawah Customize your instance, luaskan bagian Data Protection.
- Di bagian Aktifkan pemulihan point-in-time, luaskan Opsi lanjutan.
- Masukkan jumlah hari untuk menyimpan log, dari 1-35 untuk edisi Cloud SQL Enterprise Plus atau 1-7 untuk edisi Cloud SQL Enterprise.
- Klik Simpan.
gcloud
Edit instance untuk menetapkan jumlah hari yang diperlukan untuk menyimpan log biner.
Ganti kode berikut:
- INSTANCE_NAME: Nama instance yang ingin Anda tetapkan log transaksinya.
DAYS_TO_RETAIN: Jumlah hari log transaksi yang perlu disimpan. Untuk edisi Cloud SQL Enterprise Plus, rentang yang valid adalah antara 1 hingga 35 hari, dengan default 14 hari. Untuk edisi Cloud SQL Enterprise, rentang yang valid adalah antara 1 hingga 7 hari, dengan default 7 hari.
Jika tidak ada nilai yang ditentukan, nilai default akan digunakan. Hal ini hanya berlaku jika PITR diaktifkan. Menyimpan log transaksi dalam waktu yang lebih lama memerlukan ukuran penyimpanan yang lebih besar.
gcloud sql instances patch INSTANCE_NAME \ --retained-transaction-log-days=DAYS_TO_RETAIN
REST v1
Sebelum menggunakan salah satu data permintaan, lakukan penggantian berikut:
- PROJECT_ID: project ID.
- INSTANCE_ID: ID instance.
DAYS_TO_RETAIN: jumlah hari untuk menyimpan log transaksi. Untuk edisi Cloud SQL Enterprise Plus, rentang yang valid adalah antara 1 hingga 35 hari, dengan default 14 hari. Untuk edisi Cloud SQL Enterprise, rentang yang valid adalah antara 1 hingga 7 hari, dengan default 7 hari.
Jika tidak ada nilai yang ditentukan, nilai default akan digunakan. Hal ini hanya berlaku jika PITR diaktifkan. Menyimpan log transaksi dalam waktu yang lebih lama memerlukan ukuran penyimpanan yang lebih besar.
Metode HTTP dan URL:
PATCH https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID
Meminta isi JSON:
{ "settings": { "backupConfiguration": { "transactionLogRetentionDays": "DAYS_TO_RETAIN" } } }
Untuk mengirim permintaan Anda, perluas salah satu opsi berikut:
Anda akan menerima respons JSON yang mirip dengan yang berikut ini:
REST v1beta4
Sebelum menggunakan salah satu data permintaan, lakukan penggantian berikut:
- PROJECT_ID: project ID.
- INSTANCE_ID: ID instance.
DAYS_TO_RETAIN: jumlah hari untuk menyimpan log transaksi. Untuk edisi Cloud SQL Enterprise Plus, rentang yang valid adalah antara 1 hingga 35 hari, dengan default 14 hari. Untuk edisi Cloud SQL Enterprise, rentang yang valid adalah antara 1 hingga 7 hari, dengan default 7 hari.
Jika tidak ada nilai yang ditentukan, nilai default akan digunakan. Hal ini hanya berlaku jika PITR diaktifkan. Menyimpan log transaksi dalam waktu yang lebih lama memerlukan ukuran penyimpanan yang lebih besar.
Metode HTTP dan URL:
PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID
Meminta isi JSON:
{ "settings": { "backupConfiguration": { "transactionLogRetentionDays": "DAYS_TO_RETAIN" } } }
Untuk mengirim permintaan Anda, perluas salah satu opsi berikut:
Anda akan menerima respons JSON yang mirip dengan yang berikut ini:
Melakukan PITR menggunakan posisi log biner
Meskipun sebaiknya Anda melakukan PITR menggunakan stempel waktu seperti yang dijelaskan dalam Melakukan PITR menggunakan stempel waktu, Anda juga dapat melakukan PITR dengan memberikan posisi log biner tertentu dalam file log biner.
Untuk informasi selengkapnya tentang PITR menggunakan posisi log biner, lihat Referensi MySQL, PITR Menggunakan Log Biner.
Sebelum memulai
Sebelum menyelesaikan tugas ini, Anda harus memiliki:
Pencadangan dan logging biner diaktifkan untuk instance, dengan log biner berkelanjutan sejak pencadangan terakhir sebelum peristiwa yang ingin Anda pulihkan. Untuk informasi selengkapnya, lihat Mengaktifkan logging biner.
Log biner harus tersedia di disk agar Anda dapat menjelajahinya untuk menemukan peristiwa. Untuk memeriksa durasi retensi log biner di disk, lihat Periode retensi log. Anda tidak dapat menjelajahi log biner yang disimpan di Cloud Storage dengan utilitas
mysqlbinlog
.Nama file log biner dan posisi peristiwa yang ingin Anda pulihkan (peristiwa tersebut dan semua peristiwa yang muncul setelah tidak tercermin dalam instance baru). Untuk informasi selengkapnya, lihat Mengidentifikasi posisi log biner.
Setelah mengidentifikasi nama file dan posisi log biner, lakukan PITR menggunakan posisi peristiwa log biner.
Mengidentifikasi posisi pemulihan
Gunakan klien MySQL untuk terhubung ke instance yang ingin Anda pulihkan.
Untuk melakukannya, gunakan Cloud Shell atau mesin klien lokal Anda. Untuk informasi selengkapnya, lihat Opsi koneksi untuk aplikasi eksternal.
Tampilkan file log biner untuk instance:
SHOW BINARY LOGS;
Tampilkan 100 peristiwa pertama dalam file log biner terbaru:
SHOW BINLOG EVENTS IN '<BINARY_LOG_FILE>' LIMIT 100;
Anda dapat menyesuaikan jumlah baris yang ditampilkan, tetapi tidak menampilkan semua peristiwa dalam file sampai Anda mengetahui ukuran file tersebut. Menampilkan banyak peristiwa dapat memengaruhi performa sistem.
Jika peristiwa yang Anda cari tidak ditampilkan, gunakan posisi terakhir yang ditampilkan sebagai titik awal untuk menelusuri kumpulan peristiwa berikutnya:
SHOW BINLOG EVENTS IN '<BINARY_LOG_FILE>' FROM <POSITION> LIMIT 100;
Ketika Anda menemukan peristiwa yang menandai titik waktu yang ingin Anda pulihkan, catat posisinya (ditunjukkan sebagai
Pos
) dan nama file log biner.Nama file log biner dan posisi adalah nilai yang Anda gunakan untuk PITR.
Di bawah ini adalah beberapa contoh output dari perintah SHOW BINLOG EVENTS:
+------------------+-----+-------------+-----------+-------------+-----------------------------------------------------+ | Log_name | Pos | Event_type | Server_id | End_log_pos | Info | +------------------+-----+-------------+-----------+-------------+-----------------------------------------------------+ | mysql-bin.000011 | 4 | Format_desc | 88955285 | 120 | Server ver: 5.6.30-log, Binlog ver: 4 | | mysql-bin.000011 | 120 | Query | 88955285 | 211 | create database db1 | | mysql-bin.000011 | 211 | Query | 88955285 | 310 | use `db1`; CREATE TABLE t (c CHAR(20)) | | mysql-bin.000011 | 310 | Query | 88955285 | 381 | BEGIN | | mysql-bin.000011 | 381 | Table_map | 88955285 | 426 | table_id: 18 (db1.t) | | mysql-bin.000011 | 310 | Query | 88955285 | 381 | BEGIN | | mysql-bin.000011 | 426 | Write_rows | 88955285 | 464 | table_id: 18 flags: STMT_END_F | | mysql-bin.000011 | 464 | Xid | 88955285 | 495 | COMMIT /* xid=56 */ | | mysql-bin.000011 | 495 | Query | 88955285 | 566 | BEGIN | | mysql-bin.000011 | 566 | Table_map | 88955285 | 611 | table_id: 18 (db1.t) | | mysql-bin.000011 | 611 | Write_rows | 88955285 | 649 | table_id: 18 flags: STMT_END_F | | mysql-bin.000011 | 649 | Xid | 88955285 | 680 | COMMIT /* xid=57 */ | | mysql-bin.000011 | 680 | Query | 88955285 | 751 | BEGIN | | mysql-bin.000011 | 751 | Table_map | 88955285 | 796 | table_id: 18 (db1.t) | | mysql-bin.000011 | 796 | Write_rows | 88955285 | 834 | table_id: 18 flags: STMT_END_F | | mysql-bin.000011 | 834 | Xid | 88955285 | 865 | COMMIT /* xid=58 */ | | mysql-bin.000011 | 865 | Query | 88955285 | 977 | use `db1`; DROP TABLE `t` /* generated by server */ | +------------------+-----+-------------+-----------+-------------+-----------------------------------------------------+ 16 rows in set (0.04 sec)
Untuk memulihkan hingga pernyataan DROP TABLE, yang dicetak tebal di atas, Anda harus menggunakan "865" di "mysql-bin.000011" sebagai posisi pemulihan. Pernyataan DROP TABLE dan semua operasi setelahnya tidak tercermin dalam instance baru.
Melakukan PITR menggunakan posisi peristiwa log biner
gcloud
Gunakan perintah
gcloud sql instances clone
dengan tanda
--bin-log-file-name
dan --bin-log-position
.
-
Buat instance baru menggunakan nama file log biner dan posisi pemulihan.
Ganti kode berikut:
- SOURCE_INSTANCE_NAME: Nama instance tempat Anda memulihkan.
- NEW_INSTANCE_NAME: Nama untuk clone.
- BINLOG_FILE_NAME: Nama untuk log biner, seperti
mysql-bin.187288
. - POSITION: Posisi dalam log biner yang akan
dipulihkan, seperti
50001356
.
gcloud sql instances clone SOURCE_INSTANCE_NAME \ NEW_INSTANCE_NAME \ --bin-log-file-name="BINLOG_FILE_NAME" \ --bin-log-position=POSITION
Misalnya, perintah
gcloud sql instances clone
mungkin terlihat mirip dengan yang berikut ini:gcloud sql instances clone instance1 \ instance1-clone \ --bin-log-file-name=mysql-bin.0000031 \ --bin-log-position=107 \
- Gunakan ID operasi yang ditampilkan dari perintah
clone
untuk memeriksa status operasi pemulihan.gcloud sql operations describe OPERATION_ID
Saat operasi sedang berlangsung, status
RUNNING
akan ditampilkan. Setelah operasi selesai, statusDONE
akan ditampilkan.
REST v1
Buat instance baru menggunakan nama file log biner dan posisi pemulihan yang telah Anda identifikasi:
Sebelum menggunakan salah satu data permintaan, lakukan penggantian berikut:
- project-id: ID project
- target-instance-id: ID instance target
- source-instance-id: ID instance sumber
- binary-log-file-name Nama file log biner
- binary-log-position Posisi dalam file log biner
Metode HTTP dan URL:
POST https://sqladmin.googleapis.com/v1/projects/project-id/instances/source-instance-id/clone
Meminta isi JSON:
{ "cloneContext": { "kind": "sql#cloneContext", "destinationInstanceName": "target-instance-id", "binLogCoordinates": { "kind": "sql#binLogCoordinates", "binLogFileName": "binary-log-file-name", "binLogPosition": "binary-log-position" } } }
Untuk mengirim permintaan Anda, perluas salah satu opsi berikut:
Anda akan menerima respons JSON yang mirip dengan yang berikut ini:
REST v1beta4
Buat instance baru menggunakan nama file log biner dan posisi pemulihan yang telah Anda identifikasi:
Sebelum menggunakan salah satu data permintaan, lakukan penggantian berikut:
- project-id: ID project
- target-instance-id: ID instance target
- source-instance-id: ID instance sumber
- binary-log-file-name Nama file log biner
- binary-log-position Posisi dalam file log biner
Metode HTTP dan URL:
POST https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/source-instance-id/clone
Meminta isi JSON:
{ "cloneContext": { "kind": "sql#cloneContext", "destinationInstanceName": "target-instance-id", "binLogCoordinates": { "kind": "sql#binLogCoordinates", "binLogFileName": "binary-log-file-name", "binLogPosition": "binary-log-position" } } }
Untuk mengirim permintaan Anda, perluas salah satu opsi berikut:
Anda akan menerima respons JSON yang mirip dengan yang berikut ini:
Memecahkan masalah
Masalah | Pemecahan masalah |
---|---|
ATAU
|
Stempel waktu yang Anda berikan tidak valid. |
ATAU
|
Stempel waktu yang Anda berikan adalah untuk waktu saat cadangan atau saat koordinat binlog tidak dapat ditemukan. |
Memecahkan masalah peralihan ke Cloud Storage
Tabel berikut mencantumkan kemungkinan error yang mungkin ditampilkan dengan kode INVALID REQUEST
saat Anda mengalihkan lokasi penyimpanan log transaksi dari disk ke Cloud Storage.
Masalah | Pemecahan masalah |
---|---|
Switching the storage location of the transaction logs
used for PITR is not supported for instances with database type %s.
|
Pastikan Anda menjalankan perintah gcloud CLI atau membuat permintaan API di instance Cloud SQL untuk MySQL atau Cloud SQL untuk PostgreSQL. Mengganti lokasi penyimpanan untuk log transaksi menggunakan gcloud CLI atau Cloud SQL Admin API tidak didukung untuk Cloud SQL untuk SQL Server. |
MySQL transactional logging is not enabled on this instance.
|
MySQL menggunakan logging biner sebagai log transaksi untuk pemulihan point-in-time (PITR). Untuk mendukung PITR, MySQL mengharuskan Anda mengaktifkan logging biner di instance. Untuk mengetahui informasi selengkapnya tentang cara mengaktifkan logging biner, lihat Mengaktifkan PITR. |
This command is not supported on replica instances.
Run the command on the primary instance instead.
|
Pastikan Anda menentukan instance utama saat menjalankan perintah atau membuat permintaan API. |
This instance is already storing transaction logs used for PITR in
Cloud Storage
|
Untuk memverifikasi lokasi penyimpanan log transaksi, jalankan perintah di Memeriksa lokasi penyimpanan log transaksi yang digunakan untuk PITR. |
The instance is already switching transaction logs used for PITR from disk
to Cloud Storage.
|
Tunggu hingga operasi tombol selesai. Untuk memverifikasi status operasi dan lokasi penyimpanan log transaksi, jalankan perintah di Memeriksa lokasi penyimpanan log transaksi yang digunakan untuk PITR. |
Langkah selanjutnya
- Mengonfigurasi flag pada clone Anda