Mengonfigurasi MySQL di Compute Engine

Compute Engine menawarkan berbagai jenis instance dan opsi penyimpanan untuk membaca dan menulis data dari database MySQL Anda. Untuk memastikan Anda mencapai performa dan biaya terbaik untuk beban kerja database, sebaiknya jalankan di produk infrastruktur sebagai layanan (IaaS) generasi baru.

Rekomendasi konfigurasi berikut memperhitungkan bahwa beban kerja MySQL sering digunakan dalam sistem yang banyak membaca, seperti pemrosesan transaksi online (OLTP) atau database yang mendukung aplikasi web biasa. Alat ini juga mempertimbangkan pilihan konfigurasi umum, seperti menggunakan MySQL versi 8.0 atau yang lebih baru dan menggunakan mesin penyimpanan InnoDB. Untuk workload yang sensitif terhadap performa, Anda mungkin perlu menyesuaikan konfigurasi agar sesuai. Sebaiknya gunakan panduan ini sebagai titik awal untuk deployment, lalu uji dengan beban kerja sebenarnya untuk memvalidasi bahwa konfigurasi Anda memenuhi kebutuhan Anda.

Memilih virtual machine (VM)

Untuk workload MySQL, sebaiknya gunakan kelompok mesin C dan N generasi terbaru, karena mencakup bentuk yang berfungsi dengan baik untuk sebagian besar konfigurasi MySQL yang praktis. Untuk pengantar seri mesin ini, lihat Trusted Cloud by S3NS postingan blog berikut. Kelompok mesin ini menggunakan Titanium dan didasarkan pada prosesor Intel, AMD, dan Axion generasi terbaru.

Fokus pada performa

Untuk workload yang sensitif terhadap performa, seperti database MySQL yang penting bagi bisnis, sebaiknya gunakan instance C4 dan C4A terbaru jika tersedia di region Anda. Jika Anda tidak dapat mengaksesnya, instance C3 dan C3D menawarkan fokus yang serupa pada performa.

Instance ini menawarkan latensi terendah dan paling konsisten untuk operasi yang terikat komputasi, dan menyertakan fitur berguna berikut untuk workload yang berfokus pada performa:

  • Kontrol atas peristiwa pemeliharaan host dengan notifikasi awal
  • Kontrol peningkatan turbo inti tunggal untuk konsistensi performa yang lebih baik
  • Jaringan Tingkat_1 untuk bandwidth jaringan yang lebih tinggi

Jika menggunakan instance C4A, C3, atau C3D, Anda juga dapat menggunakan drive solid-state lokal (SSD Lokal) untuk memenuhi persyaratan performa tertentu.

Mengoptimalkan biaya

Untuk workload dengan prioritas utama Anda adalah mengoptimalkan biaya, seperti database MySQL dengan tingkat traffic rendah hingga sedang atau database yang digunakan dalam lingkungan pengujian atau pengembangan, sebaiknya gunakan instance N4 terbaru. Instance ini menggunakan pengelolaan resource dinamis generasi berikutnya Compute Engine untuk mengoptimalkan total biaya Anda sekaligus mempertahankan performa yang solid, tanpa jaminan kuat yang ditawarkan C4, C4A, C3, dan C3D. Untuk mengetahui detail selengkapnya, lihat Pengelolaan resource dinamis generasi berikutnya.

Mengonfigurasi ukuran VM

Untuk VM yang Anda gunakan, penting untuk memilih ukuran VM yang tepat untuk tingkat performa MySQL yang Anda inginkan.

Jika Anda menginginkan performa transaksi tulis per detik (TPS) yang tinggi, faktor utama yang perlu dipertimbangkan adalah block storage Anda. Untuk mengetahui detail selengkapnya, lihat Mengonfigurasi penyimpanan blok, di halaman ini.

Jika Anda menginginkan performa kueri baca per detik (QPS) yang tinggi, sebaiknya gunakan kumpulan buffer berbasis RAM MySQL untuk meng-cache data panas dan mengurangi akses disk. Untuk memaksimalkan manfaat ini, lakukan langkah-langkah berikut:

  • Pilih ukuran VM yang memastikan bahwa set kerja, atau jumlah total data yang diproses database Anda sekaligus, sesuai dengan kumpulan buffer.
  • Ukuran kumpulan buffer untuk menggunakan sebagian besar RAM di VM.

Untuk meminimalkan biaya penskalaan VM seperti ini, sebaiknya gunakan VM dengan rasio RAM yang tinggi terhadap CPU virtual (vCPU), agar tidak membayar vCPU yang tidak Anda gunakan.

Untuk mendapatkan keseimbangan yang ideal bagi sebagian besar workload MySQL, tentukan set kerja workload Anda, lalu pilih bentuk instance highmem terkecil yang sesuai dengan set kerja tersebut di RAM. Bentuk instance highmem memiliki RAM sekitar 8 GB per vCPU. Hal ini memberi Anda cukup memori untuk meng-cache set kerja yang besar, sekaligus mempertahankan CPU yang cukup untuk menangani beban kueri yang tinggi.

Untuk workload dengan set kerja yang besar tetapi rasio kueri yang rendah, dengan menggunakan instance N4, Anda dapat lebih mengoptimalkan total biaya dengan menggunakan jenis mesin kustom dengan memori yang diperluas untuk lebih meningkatkan rasio RAM ke vCPU.

Mengonfigurasi bandwidth jaringan VM

Untuk sebagian besar kasus penggunaan MySQL, Anda dapat tetap menggunakan batas bandwidth jaringan default untuk instance. Jika ini sesuai dengan kebutuhan Anda, Anda tidak perlu mengupgrade ke jaringan Tier_1.

Mengonfigurasi block storage

Google Cloud Hyperdisk adalah satu-satunya generasi block storage yang tahan lama yang tersedia untuk grup VM Compute Engine terbaru. Kami yakin bahwa Hyperdisk Balanced adalah yang paling cocok untuk sebagian besar workload MySQL. Untuk mengetahui informasi selengkapnya tentang Hyperdisk, buka dokumentasi Hyperdisk.

Google Cloud Hyperdisk

Hyperdisk Balanced menawarkan fitur berikut:

  • Latensi solid state drive (SSD) dengan biaya rendah
  • Konfigurasi berperforma tinggi untuk aplikasi yang memerlukannya
  • Daya tahan lebih dari 99,999% untuk melindungi dari risiko kegagalan hardware dan kerusakan data tersembunyi di seluruh industri
  • Enkripsi semua data Hyperdisk dalam penyimpanan dengan kunci enkripsi yang dikelola Google atau dikelola pelanggan

Pilih tingkat performa Anda

Dengan Hyperdisk Balanced, Anda memilih tingkat performa secara independen dari ukuran penyimpanan untuk disk, sehingga Anda dapat mengoptimalkan performa database sekaligus hanya membayar resource input/output (I/O) yang diperlukan oleh workload Anda. Jika kumpulan buffer database MySQL lebih besar dari set kerja, selama operasi steady-state, database dapat menayangkan hampir semua kueri baca dari kumpulan buffer, tanpa menyentuh disk.

Untuk memilih tingkat performa volume Hyperdisk, pertimbangkan workload operasi tulis MySQL Anda, dengan penekanan khusus pada hal berikut:

  • Akses ke log redo InnoDB
  • Pembaruan berikutnya pada file dan indeks data InnoDB

Di luar operasi steady-state, peristiwa pemeliharaan database juga dapat menyebabkan performa disk yang lebih berfluktuasi. Frekuensi terjadinya hal ini cenderung diskalakan dengan beban kerja tulis database Anda, sehingga lebih mungkin terjadi dalam situasi seperti pemulihan pasca-error menggunakan log redo atau sistem pencadangan yang menyalin dirinya sendiri dengan membaca semua perubahan database sejak pencadangan terakhir.

Mengubah ukuran disk

Ada tiga strategi umum untuk menentukan ukuran batas performa disk:

  1. Gunakan konfigurasi default. Setiap disk dilengkapi dengan setidaknya 3.000 input/output per detik (IOPS) dan throughput 140 MiBps. Hal ini cukup untuk workload MySQL dasar dan volume booting sistem operasi (OS). Jika kasus penggunaan Anda melebihi kapasitas ini, Anda dapat mengubah performa I/O yang disediakan sesuai permintaan tanpa menghentikan beban kerja.
  2. Ukur penggunaan Anda yang sudah ada. Jika database Anda sudah berjalan di lingkungan lain, catat IOPS dan throughput disknya dengan tingkat perincian satu menit atau kurang. Setelah Anda memiliki data selama satu hingga dua minggu, sehingga kumpulan sampel Anda menyertakan beberapa fluktuasi dalam beban dan peristiwa pemeliharaan normal, pilih nilai persentil tinggi dari set data tersebut, dan tambahkan buffer kecil untuk memperhitungkan pertumbuhan organik atau penggunaan yang tidak terduga.
  3. Perkirakan kebutuhan Anda, lalu ubah nanti. Jika tidak memiliki sumber data yang ada, Anda mungkin harus memperkirakan kebutuhan performa pada awalnya, lalu menyesuaikannya lebih lanjut setelah deployment. Sebaiknya siapkan nilai yang lebih tinggi dari yang Anda perkirakan akan diperlukan pada awalnya, sehingga workload Anda tidak mengalami bottleneck performa, lalu pada akhirnya kurangi performa yang disediakan agar sesuai dengan workload Anda.

Meningkatkan performa disk

Anda dapat meningkatkan performa setiap disk Hyperdisk Balanced hingga maksimum 160.000 IOPS dan throughput 2.400 MBps. Ukuran VM membantu menentukan batas performa maksimum Hyperdisk, jadi jika Anda menginginkan performa Hyperdisk yang sangat tinggi, Anda mungkin perlu meningkatkan jumlah core VM. Jika workload Anda yang paling berat memerlukan performa disk yang lebih tinggi daripada yang dapat diberikan oleh satu disk Hyperdisk Balanced, Anda dapat menggunakan salah satu metode berikut untuk menggabungkan beberapa disk Hyperdisk Balanced:

  • Mengupgrade ke Hyperdisk Extreme
  • Gunakan mekanisme redundant array of independent disks (RAID) software yang berbeda, seperti mdadm

Saat menskalakan database MySQL, Anda dapat meningkatkan kapasitas dan performa disk secara dinamis tanpa periode nonaktif. Hal ini membantu performa workload gaya pemrosesan analitik online (OLAP) yang melakukan join kompleks besar yang tidak dapat muat di RAM dan ditransfer ke disk. Dalam kasus yang jarang terjadi, workload MySQL yang memerlukan latensi penyimpanan sangat rendah dan dapat mentoleransi kehilangan data dapat menyimpan set data lengkapnya di SSD Lokal. Anda juga dapat menggunakan solusi campuran berikut untuk meningkatkan latensi baca dan membatasi pengurangan ketahanan:

  • Mencerminkan set data Anda antara Hyperdisk dan SSD Lokal.
  • Gunakan pengelola volume untuk mengonfigurasi SSD Lokal sebagai cache untuk data yang disimpan di Hyperdisk yang mendasarinya.

Manfaatkan fitur Hyperdisk tambahan

Hyperdisk juga memberi Anda fitur berikut, yang dapat meningkatkan atau menyederhanakan alur kerja ketersediaan tinggi dan pemulihan dari bencana di lokasi:

Untuk informasi selengkapnya tentang cara mengonfigurasi fitur ini dengan MySQL untuk Compute Engine, lihat bagian ketersediaan tinggi yang ada di halaman ini.

SSD lokal

Beberapa kelompok mesin Compute Engine memungkinkan Anda menggunakan SSD Lokal, bukan Hyperdisk. Ini bukan penyimpanan yang tahan lama, tetapi beban kerja MySQL sering menggunakannya untuk menyimpan tablespace sementara.

Untuk mengetahui informasi tentang cara menggunakan SSD Lokal untuk menskalakan database MySQL, lihat Penyesuaian ukuran disk dinamis, yang ada di halaman ini.

Fitur Compute Engine tambahan

Anda dapat menggunakan fitur Compute Engine berikut untuk membantu mengoptimalkan deployment MySQL.

Cloud Monitoring

Untuk memantau performa VM dan penggunaan layanan infrastruktur, gunakan konsolTrusted Cloud . Di halaman Instance VM, pada tab Observability, Anda dapat memantau metrik terkait performa seperti penggunaan CPU dan memori, bandwidth jaringan, dan performa instance yang disediakan. Demikian pula, di halaman Disk, di tab Observability, Anda dapat memantau throughput dan IOPS volume disk.

Untuk menyesuaikan metrik performa yang Anda lihat, gunakan Cloud Monitoring untuk membuat kueri. Anda dapat memilih metrik performa tertentu yang ingin dilihat untuk layanan infrastruktur. Untuk metrik khusus MySQL, Compute Engine menawarkan plugin beban kerja MySQL.

Praktik terbaik untuk mengonfigurasi sistem operasi

  • Gunakan sistem file yang sesuai. Google berfokus untuk mengoptimalkan sistem file ext4 dan XFS Linux; tetapi, sebagian besar sistem file sesuai untuk digunakan dengan MySQL.
  • Nonaktifkan Transparent Huge Pages (THP) dalam konfigurasi sistem operasi dasar Anda. Untuk mengetahui langkah-langkah menonaktifkan THP, lihat dokumentasi THP.
  • Jika Anda menggunakan Linux, gunakan flag relatime, dan lazytime untuk konfigurasi pemasangan sistem file. Hal ini mengurangi overhead performa yang terkait dengan pembaruan nilai atime, mtime, dan ctime pada file saat file tersebut dibaca, diubah, atau metadatanya diubah.

Praktik terbaik untuk mengonfigurasi MySQL

Sebaiknya gunakan setelan konfigurasi berikut untuk MySQL.

  • Gunakan MySQL versi terbaru. Google berfokus untuk mengoptimalkan MySQL versi 8.0 dan yang lebih baru.

  • Meningkatkan ukuran kumpulan buffer. MySQL menggunakan kumpulan buffer untuk meningkatkan performa baca dengan meng-cache data di RAM, sehingga mengurangi akses disk. Secara default, ukuran kumpulan buffer MySQL adalah 128 MiB, yang terlalu kecil untuk sebagian besar kasus penggunaan praktis. Sebaiknya tingkatkan ukuran innodb_buffer_pool_size agar lebih besar dari ukuran set kerja yang diakses aplikasi Anda di database. Hal ini biasanya terdiri dari langkah-langkah berikut:

    1. Ukur atau estimasi ukuran set kerja Anda pada salinan instance MySQL yang sedang berjalan.
    2. Pilih ukuran dan bentuk virtual machine (VM) dengan RAM yang cukup untuk menyesuaikan set kerja tersebut.
    3. Konfigurasikan ukuran kumpulan buffer di VM untuk menggunakan sebagian besar RAM yang tersedia.

  • Aktifkan buffering doublewrite. MySQL memiliki buffer doublewrite yang membantu melindungi dari tulisan yang rusak, mode kegagalan saat penulisan yang mencakup beberapa blok di disk mungkin hanya dilakukan sebagian jika kegagalan hardware atau daya terjadi di tengah penulisan. Untuk mendapatkan manfaat dari perlindungan ini, aktifkan innodb_doublewrite.

  • Tetapkan nilai innodb_flush_log_at_trx_commit ke 1. Hal ini memastikan bahwa transaksi tulis tahan lama di disk saat di-commit.

  • Untuk mengurangi overhead performa, tentukan nilai untuk innodb_flush_method. Untuk MySQL versi 8.0.14 dan yang lebih baru, tetapkan nilai innodb_flush_method ke O_DIRECT_NO_FSYNC, yang optimal, tetapi hanya ada dalam versi ini. Untuk MySQL versi yang lebih lama dari 8.0.14, tetapkan nilai innodb_flush_method ke O_DIRECT.

  • Dalam skenario replikasi ketersediaan tinggi, tetapkan nilai sync_binlog instance database primer ke 1. MySQL menggunakan log binernya untuk mengomunikasikan perubahan dari database utama ke database sekunder, sehingga memastikan bahwa log biner di-commit pada waktu commit transaksi, dengan jeda replika dan tujuan titik pemulihan (RPO) serendah mungkin di antara database.

  • Saat menggunakan MySQL pada kelompok mesin seri C, aktifkan innodb_numa_interleave. Hal ini memastikan bahwa kumpulan buffer MySQL dapat memanfaatkan kebijakan akses memori non-seragam (NUMA).

Kapan harus menonaktifkan buffering doublewrite

Buffer doublewrite MySQL, yang melindungi dari penulisan yang terputus, memiliki overhead performa hingga 25% untuk transaksi tulis MySQL, yang berpotensi memengaruhi latensi transaksi. Google Cloud Hyperdisk juga menawarkan perlindungan tulis yang terputus, sehingga jika Anda menggunakan MySQL untuk menulis langsung ke sistem file ext4 yang berjalan di Hyperdisk, Anda dapat menonaktifkan buffer doublewrite dengan aman.

Namun, agar perlindungan tulis yang terputus Hyperdisk efektif, Anda harus mengonfigurasi sistem file dan lapisan software perantara lainnya antara database dan disk untuk menghindari pengenalan tulis yang terputus di atas lapisan disk. Daftar berikut memberikan contoh konfigurasi yang mungkin memperkenalkan penulisan yang terputus di atas lapisan Hyperdisk:

  • Menjalankan instance MySQL di dalam penampung, seperti Google Kubernetes Engine atau Kubernetes yang dihosting sendiri.
  • Menyimpan file MySQL di sistem file XFS, yang tidak mendukung ukuran blok yang cukup besar di sebagian besar konfigurasi kernel Linux.
  • Menyimpan file MySQL Anda pada konfigurasi array disk independen redundan (RAID) yang menyebabkan striping disk, seperti mdadm untuk Linux atau Storage Spaces dan Storage Spaces Direct untuk Windows.
  • Menyimpan file MySQL di atas pengelola volume, seperti Logical Volume Manager (LVM) untuk Linux atau Storage Spaces dan Storage Spaces Direct untuk Windows.

  • Menyimpan file MySQL di Hyperdisk dengan Solid State Drive (SSD) lokal yang dikonfigurasi sebagai cache, seperti menggunakan lvmcache, dm-cache, atau bcache untuk Linux atau Storage Spaces untuk Windows.

  • Menjalankan instance MySQL di dalam VM menggunakan virtualisasi bertingkat.

Meskipun Anda dapat menyiapkan konfigurasi sebelumnya agar tidak menyebabkan tulisan yang terputus, sebaiknya jangan nonaktifkan buffering doublewrite saat menggunakannya, karena sulitnya memvalidasi bahwa konfigurasi tertentu aman.

(Opsional) Menonaktifkan buffering doublewrite

Untuk menonaktifkan buffering doublewrite, selesaikan langkah-langkah berikut:

  1. Pada sistem file ext4, Anda harus mengaktifkan fitur bigalloc dan mengonfigurasi ukuran cluster sistem file menjadi 16 KiB, atau lebih besar dari kelipatan 2 dari 16 KiB. Hal ini memastikan operasi tulis MySQL tidak akan dibagi menjadi IO terpisah oleh sistem file sebelum dikeluarkan ke Hyperdisk. Gagal menaikkan batas atau menggunakan nilai yang lebih kecil dari 16 KiB tidak akan melindungi dari penulisan yang terputus. Sebagai contoh dengan ukuran cluster 16 KiB, hal ini dikonfigurasi pada waktu pembuatan sistem file:

    mkfs.ext4 -O bigalloc -C 16384 /dev/<device-name>

  2. Nonaktifkan innodb_doublewrite dan tetapkan innodb_flush_method ke O_DIRECT atau O_DIRECT_NO_FSYNC (bergantung pada versi MySQL Anda seperti yang dijelaskan di atas).

Mengonfigurasi ketersediaan tinggi (HA) dan solusi pencadangan

Sebaiknya lindungi semua workload MySQL penting Anda dengan mengonfigurasi solusi ketersediaan tinggi (HA) dan pencadangan untuknya. Untuk HA dan pencadangan, faktor berikut adalah yang paling penting:

Solusi HA umumnya menargetkan RTO dan RPO mendekati nol, tetapi hanya melindungi dari kegagalan infrastruktur. Solusi pencadangan menargetkan periode RTO dan RPO yang lebih lama, tetapi memberikan cakupan untuk kumpulan skenario kegagalan yang lebih besar, seperti berikut:

  • Penghapusan data yang tidak disengaja
  • Serangan ransomware
  • Bencana alam

Mengonfigurasi ketersediaan tinggi (HA)

Fitur HA menggunakan redundansi penyimpanan dan komputasi untuk memastikan database MySQL Anda telah mengurangi periode nonaktif jika terjadi kegagalan atau pemadaman host, sehingga aplikasi klien dapat mengakses datanya meskipun instance atau zona tidak tersedia.

MySQL memungkinkan replikasi dalam mode berikut:

  • Mode asinkron. Dalam mode asinkron, primary mengonfirmasi transaksi penulisan segera setelah di-commit secara lokal, sehingga jika terjadi pemadaman layanan di primary, sejumlah kecil data yang baru ditulis mungkin akan hilang selama failover, karena RPO mendekati nol, tetapi tidak benar-benar nol.
  • Mode semisinkron. Dalam mode semisinkron, replika utama menunggu untuk mengonfirmasi transaksi hingga jumlah replika yang dapat dikonfigurasi telah mengonfirmasi penerimaan transaksi. Hal ini sangat meningkatkan peluang tidak ada kehilangan data selama failover yang tidak terencana, karena RPO secara efektif nol.

Untuk kedua mode tersebut, RTO ditentukan oleh seberapa cepat health check melakukan hal berikut:

  1. Identifikasi instance yang gagal.
  2. Memicu failover.
  3. Beri tahu klien bahwa instance failover kini menjadi instance utama, dengan menggunakan domain name system (DNS) atau cara lain untuk mengidentifikasi server database.

Dalam kedua mode replikasi, Anda harus memiliki instance failover untuk direplikasi. Anda dapat menemukan instance tersebut di salah satu tempat berikut:

  • Zona yang sama dengan tempat instance utama berada
  • Zona yang berbeda dalam region tempat primary berada
  • Region yang berbeda dengan region utama

Untuk mempertahankan ketersediaan tinggi bahkan selama pemadaman layanan zona, sebaiknya gunakan konfigurasi berikut:

  • Tempatkan instance utama dan instance penggantian di zona yang berbeda, baik berada dalam region yang sama maupun tidak.
  • Gunakan replikasi asinkron. Hal ini karena, jika Anda menggunakan replikasi semisinkron, menempatkan instance utama dan failover di zona terpisah dapat menyebabkan latensi tinggi untuk commit transaksi tulis.
  • Jika Anda memerlukan RPO nol, gunakan Hyperdisk Balanced High Availability, yang memungkinkan Anda mereplikasi disk secara sinkron di dua zona dalam region yang sama. Untuk mengetahui detailnya, lihat panduan Google tentang cara menyediakan layanan HA menggunakan Hyperdisk High Availability. Saat Anda mengonfigurasi Ketersediaan Tinggi Hyperdisk yang Seimbang, sebaiknya integrasikan dengan Grup Instance Terkelola Stateful untuk mendiagnosis masalah kondisi instance dan mengotomatiskan tindakan pemulihan.

Mengonfigurasi rencana pencadangan dan ketahanan data

Rencana pencadangan dan ketahanan data membantu mencegah kehilangan data selama kegagalan seperti penghapusan data secara tidak sengaja, serangan ransomware, dan bencana alam. Anda juga dapat menggunakannya sebagai penyimpanan dingin untuk persyaratan kepatuhan dan audit. Untuk MySQL, ada banyak metodologi pencadangan yang dapat dipilih, beberapa di antaranya berfungsi di tingkat database, dan beberapa di antaranya berfungsi di tingkat volume penyimpanan. Saat memilih metodologi, Anda harus mempertimbangkan persyaratan RTO dan RPO secara utama.

Mencadangkan di tingkat database

Untuk pencadangan tingkat database, pertimbangkan untuk menggunakan opsi berikut yang disediakan MySQL:

  • Pencadangan inkremental berdasarkan logging biner, yang membuat dump data logis. Hal ini mencakup hal berikut:
  • Alat yang mengelola proses pencadangan untuk Anda, seperti MySQL Enterprise Backup.

Untuk mengetahui informasi selengkapnya tentang opsi pencadangan tingkat database MySQL, lihat Pencadangan dan Pemulihan dalam dokumentasi MySQL.

Untuk opsi mana pun, Anda harus memiliki sistem penyimpanan sekunder untuk menyalin data cadangan. Sebaiknya gunakan alat berikut:

Menggunakan Hyperdisk untuk membuat snapshot dan meng-clone di tingkat penyimpanan

Untuk pencadangan tingkat penyimpanan, sebaiknya gunakan produk Hyperdisk untuk mengambil snapshot, meng-clone, dan mengambil tampilan point-in-time database MySQL Anda. RPO untuk pendekatan ini bergantung pada seberapa sering Anda mengambil snapshot database, dan RTO bergantung pada solusi spesifik yang Anda gunakan.

Jika pemulihan cepat penting bagi Anda, dan Anda hanya memerlukan cakupan cadangan dalam zona, sebaiknya gunakan snapshot instan Hyperdisk. Instant snapshot mengambil data pada titik waktu tertentu secara inkremental, dan dapat memulihkan data dengan cepat ke volume Hyperdisk baru melalui pembuatan salinan disk, sehingga memberikan RTO dalam hitungan menit. Dengan snapshot, Anda dapat memulihkan data saat konten disk telah ditimpa, dihapus, atau rusak, dan tersedia secara lokal di zona atau region yang sama dengan disk sumber. Untuk informasi selengkapnya, lihat Tentang snapshot instan

Untuk skenario pemulihan dari bencana, saat data harus disimpan dengan redundansi yang lebih tinggi daripada disk asli, dan di lokasi terpisah untuk memastikan bahwa satu bencana tidak memengaruhi semua replika data, sebaiknya gunakan snapshot disk standar dan arsip Hyperdisk. Snapshot arsip dan disk standar membuat salinan data dalam disk pada waktu tertentu dan menyimpannya dengan redundansi tinggi dalam format yang tidak dapat diubah. Saat Anda membuat beberapa snapshot disk, seperti dengan jadwal snapshot, Hyperdisk hanya menyimpan perubahan inkremental. Snapshot disk standar dan arsip cocok jika Anda dapat menerima RTO yang lebih tinggi, karena penyalinan data dari penyimpanan snapshot kembali ke penyimpanan VM dapat berarti bahwa data tersebut memerlukan waktu yang lebih lama untuk dipulihkan. Untuk mengetahui informasi selengkapnya, lihat Membuat snapshot disk standar dan arsip.

Snapshot instan Hyperdisk serta snapshot standar dan arsipnya konsisten dengan error dalam satu disk. Artinya, saat Anda melakukan pemulihan dari snapshot, database MySQL harus menjalankan langkah-langkah pemulihan InnoDB normal untuk mengembalikan log dan file datanya ke status yang konsisten. Bergantung pada konfigurasi log redo InnoDB, hal ini dapat memperpanjang RTO. Pola berikut dapat semakin mempersulit upaya Anda untuk membuat snapshot database yang konsisten:

  • File database MySQL Anda tersebar di beberapa volume.
  • Anda menggunakan utilitas RAID software Linux, seperti mdadm.
  • Anda telah memisahkan lokasi penyimpanan MySQL yang dikonfigurasi di seluruh sistem file pada disk yang berbeda.

Untuk membuat snapshot yang tidak memerlukan pemulihan setelah pemulihan snapshot, selesaikan langkah-langkah berikut:

  1. Mengunci akses tulis ke database MySQL untuk sementara.
  2. Hapus semua buffering yang sedang berlangsung ke disk menggunakan perintah LOCK INSTANCE FOR BACKUP dan FLUSH TABLES WITH READ LOCK.
  3. Memulai operasi snapshot.

  4. Untuk skenario multi-disk, setelah Anda melakukan flush di tingkat MySQL, jalankan perintah sync dan fsfreeze di server untuk mengosongkan semua penulisan yang sedang berlangsung ke disk dan menjeda penulisan baru yang masuk di tingkat sistem file.

Setelah mengambil snapshot awal database, Anda tidak perlu terus mengunci disk, karena Hyperdisk dengan cepat mengambil tampilan titik waktu, lalu dapat memproses langkah-langkah penulisan penyimpanan berikutnya secara asinkron. Jika Anda memerlukan langkah-langkah ini untuk konsistensi snapshot, dan Anda ingin menghapus dampak penulisan ini pada database utama, Anda juga dapat menjalankan pencadangan terhadap replika database, bukan database utama.

Langkah berikutnya