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 mendapatkan performa dan biaya terbaik untuk workload database, sebaiknya jalankan produk infrastruktur sebagai layanan (IaaS) generasi yang lebih baru.

Rekomendasi konfigurasi berikut mempertimbangkan bahwa beban kerja MySQL sering digunakan dalam sistem yang banyak membaca, seperti pemrosesan transaksi online (OLTP) atau database yang mendukung aplikasi web umum. Panduan ini juga memperhitungkan 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 Anda, lalu lakukan pengujian dengan workload sebenarnya untuk memvalidasi bahwa konfigurasi Anda memenuhi kebutuhan Anda.

Pilih virtual machine (VM) Anda

Untuk workload MySQL, sebaiknya gunakan kelompok mesin C dan N generasi terbaru, karena kelompok mesin ini mencakup bentuk yang berfungsi baik untuk sebagian besar konfigurasi MySQL praktis. Untuk pengantar tentang seri mesin ini, lihat Google Cloud 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 mencakup fitur berguna berikut untuk workload yang berfokus pada performa:

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

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

Mengoptimalkan biaya

Untuk workload yang prioritas utamanya adalah mengoptimalkan biaya, seperti database MySQL dengan tingkat traffic rendah hingga sedang atau database yang digunakan di lingkungan pengujian atau pengembangan, sebaiknya gunakan instance N4 terbaru. Instance ini menggunakan pengelolaan resource dinamis generasi berikutnya dari 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 setiap 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, yang ada 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 aktif 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.
  • Ukur ukuran kumpulan buffer untuk menggunakan sebagian besar RAM di VM.

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

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

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

Mengonfigurasi bandwidth jaringan VM

Untuk sebagian besar kasus penggunaan MySQL, Anda dapat menggunakan batas bandwidth jaringan default untuk instance Anda. 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 dan tersedia untuk kelompok VM Compute Engine terbaru. Kami yakin bahwa Hyperdisk Balanced adalah pilihan terbaik 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 membutuhkannya
  • Ketahanan lebih baik dari 99,999% untuk melindungi dari risiko kegagalan hardware dan kerusakan data diam-diam yang terjadi di seluruh industri
  • Enkripsi semua data Hyperdisk dalam penyimpanan dengan kunci enkripsi yang dikelola Google atau dikelola pelanggan

Pilih tingkat performa Anda

Dengan Hyperdisk Seimbang, Anda dapat memilih tingkat performa secara terpisah dari ukuran penyimpanan untuk disk, sehingga Anda dapat mengoptimalkan performa database sekaligus hanya membayar sumber daya input/output (I/O) yang dibutuhkan workload Anda. Jika buffer pool database MySQL lebih besar daripada set kerjanya, selama operasi dalam kondisi stabil, database tersebut dapat melayani hampir semua kueri baca dari buffer pool, tanpa menyentuh disk.

Untuk memilih tingkat performa untuk volume Hyperdisk Anda, pertimbangkan workload 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 dalam kondisi stabil, peristiwa pemeliharaan database juga dapat menyebabkan performa disk yang lebih tidak stabil. Frekuensi terjadinya hal ini cenderung meningkat seiring dengan workload tulis database Anda, sehingga lebih mungkin terjadi dalam situasi seperti pemulihan setelah error menggunakan log redo atau sistem pencadangan yang menyalin dirinya sendiri dengan membaca semua perubahan database sejak pencadangan terakhir.

Menentukan ukuran disk

Ada tiga strategi umum untuk menentukan ukuran batas performa disk Anda:

  1. Gunakan konfigurasi default. Setiap disk dilengkapi dengan input/output per detik (IOPS) minimal 3.000 dan throughput 140 MiBps. Hal ini sudah cukup untuk workload MySQL dasar dan volume booting sistem operasi (OS). Jika kasus penggunaan Anda melampaui batas ini, Anda dapat memodifikasi performa I/O yang disediakan sesuai permintaan tanpa menghentikan workload Anda.
  2. Ukur penggunaan Anda saat ini. Jika database Anda sudah berjalan di lingkungan lain, catat IOPS dan throughput disk-nya dengan perincian satu menit atau kurang. Setelah Anda memiliki data selama satu hingga dua minggu, sehingga set sampel Anda mencakup 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 Anda pada awalnya, lalu menyesuaikannya lebih lanjut setelah deployment. Sebaiknya sediakan nilai yang lebih tinggi daripada yang Anda perkirakan akan dibutuhkan pada awalnya, sehingga beban kerja Anda tidak mengalami hambatan performa, lalu kurangi performa yang disediakan agar sesuai dengan beban kerja Anda.

Meningkatkan performa disk

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

  • Mengupgrade ke Hyperdisk Extreme
  • Gunakan mekanisme software redundant array of independent disks (RAID) 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 analitis online (OLAP) yang melakukan penggabungan kompleks dalam jumlah besar yang tidak dapat dimuat dalam RAM dan meluas ke disk. Dalam kasus yang jarang terjadi, workload MySQL yang memerlukan latensi penyimpanan yang sangat rendah dan dapat mentoleransi kehilangan data dapat menyimpan seluruh set datanya di SSD Lokal. Anda juga dapat menggunakan solusi hybrid berikut untuk meningkatkan latensi baca dan membatasi penurunan daya tahan:

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

Memanfaatkan fitur Hyperdisk tambahan

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

Untuk mengetahui 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 penggunaan SSD Lokal untuk menskalakan database MySQL, lihat Pengubahan 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 konsolGoogle Cloud . Di halaman VM Instances, di tab Observability, Anda dapat memantau metrik terkait performa seperti penggunaan CPU dan memori, bandwidth jaringan, dan performa yang disediakan untuk instance Anda. Demikian pula, di halaman Disks, 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 Anda. Untuk metrik khusus MySQL, Compute Engine menawarkan plugin beban kerja MySQL.

Praktik terbaik untuk mengonfigurasi sistem operasi Anda

  • Gunakan sistem file yang sesuai. Google berfokus pada pengoptimalan untuk sistem file ext4 dan XFS Linux; namun, sebagian besar sistem file cocok 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 memperbarui 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.

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

    1. Ukur atau perkirakan ukuran set kerja Anda pada salinan instance MySQL yang sedang berjalan.
    2. Pilih ukuran dan bentuk mesin virtual (VM) dengan RAM yang cukup untuk memuat set kerja tersebut.
    3. Konfigurasi ukuran buffer pool di VM agar menggunakan sebagian besar RAM yang tersedia.

  • Aktifkan buffer penulisan ganda. MySQL memiliki buffer penulisan ganda yang membantu melindungi dari penulisan yang terganggu, yaitu mode kegagalan saat penulisan yang mencakup beberapa blok pada disk mungkin hanya dilakukan sebagian jika terjadi kegagalan hardware atau daya 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 bersifat tahan lama di disk saat transaksi tersebut dilakukan.

  • 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 di versi ini. Untuk MySQL versi yang lebih lama dari 8.0.14, tetapkan nilai innodb_flush_method ke O_DIRECT.

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

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

Waktu untuk menonaktifkan buffer penulisan ganda

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

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

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

  • Menyimpan file MySQL Anda 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 Anda di dalam VM menggunakan virtualisasi bertingkat.

Meskipun Anda dapat menyiapkan konfigurasi sebelumnya agar tidak menimbulkan penulisan yang terpotong, sebaiknya jangan nonaktifkan buffer penulisan ganda saat menggunakannya, karena sulit untuk memvalidasi bahwa konfigurasi tertentu aman.

(Opsional) Menonaktifkan buffer penulisan ganda

Untuk menonaktifkan buffer penulisan ganda, selesaikan langkah-langkah berikut:

  1. Pada sistem file ext4, Anda harus mengaktifkan fitur bigalloc dan mengonfigurasi ukuran cluster sistem file menjadi 16 KiB, atau kelipatan pangkat 2 yang lebih besar dari 16 KiB. Hal ini memastikan penulisan MySQL tidak akan dipecah 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 saat 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 untuk workload tersebut. Untuk HA dan pencadangan, faktor-faktor berikut adalah yang paling penting:

Solusi HA umumnya menargetkan RTO dan RPO mendekati nol, tetapi hanya melindungi dari kegagalan infrastruktur. Solusi pencadangan menargetkan jangka waktu RTO dan RPO yang lebih lama, tetapi memberikan cakupan untuk serangkaian 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 bahwa database MySQL Anda memiliki periode nonaktif yang lebih singkat jika terjadi kegagalan atau gangguan host, sehingga aplikasi klien dapat mengakses datanya meskipun instance atau zona tidak tersedia.

MySQL memungkinkan replikasi dalam mode berikut:

  • Mode asinkron. Dalam mode asinkron, primer mengonfirmasi transaksi penulisan segera setelah dilakukan secara lokal, jadi jika terjadi pemadaman pada primer, sejumlah kecil data yang baru ditulis mungkin hilang selama failover, karena RPO mendekati nol, tetapi tidak benar-benar nol.
  • Mode semisinkron. Dalam mode semisinkron, replika utama menunggu untuk mengonfirmasi transaksi hingga sejumlah replika yang dapat dikonfigurasi telah mengonfirmasi penerimaan transaksi. Hal ini sangat meningkatkan kemungkinan tidak ada data yang hilang selama failover yang tidak direncanakan, karena RPO secara efektif nol.

Untuk kedua mode, RTO ditentukan oleh seberapa cepat pemeriksaan kondisi melakukan hal berikut:

  1. Mengidentifikasi instance yang gagal.
  2. Picu failover.
  3. Memberi tahu klien bahwa instance failover kini menjadi instance utama, dengan menggunakan sistem nama domain (DNS) atau cara lain untuk mengidentifikasi server database.

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

  • Zona yang sama dengan tempat instance utama berada
  • Zona yang berbeda dalam region tempat primer berada
  • Berada di region yang berbeda dengan region utama

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

  • Tempatkan instance utama dan failover Anda di zona yang berbeda, baik di 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 Ketersediaan Tinggi Hyperdisk. Saat mengonfigurasi Ketersediaan Tinggi Seimbang Hyperdisk, sebaiknya lakukan integrasi dengan Grup Instance Terkelola Stateful untuk mendiagnosis masalah kesehatan 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 yang tidak disengaja, 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 bekerja di tingkat database, dan beberapa di antaranya bekerja di tingkat volume penyimpanan. Saat memilih metodologi, Anda harus mempertimbangkan persyaratan RTO dan RPO Anda terlebih dahulu.

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 ini, Anda harus memiliki sistem penyimpanan sekunder untuk menyalin data cadangan ke dalamnya. 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 pencadangan dalam zona, sebaiknya gunakan snapshot instan Hyperdisk. Instant snapshot mengambil data secara inkremental pada titik waktu tertentu, dan dapat memulihkan data dengan cepat ke volume Hyperdisk baru melalui kloning disk, sehingga memberikan RTO dalam hitungan menit. Snapshot ini memungkinkan Anda memulihkan data saat konten disk telah ditimpa, dihapus, atau rusak, dan tersedia secara lokal di zona atau region yang sama dengan disk sumber. Untuk mengetahui informasi selengkapnya, lihat Tentang snapshot instan

Untuk skenario pemulihan dari bencana, yang datanya 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 disk arsip dan standar membuat salinan data di 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 mentoleransi RTO yang lebih tinggi, karena penyalinan data dari penyimpanan snapshot kembali ke penyimpanan VM dapat berarti bahwa pemulihannya memerlukan waktu yang lebih lama. Untuk mengetahui informasi selengkapnya, lihat Membuat snapshot disk standar dan arsip.

Snapshot instan Hyperdisk serta snapshot arsip dan standarnya bersifat konsisten terhadap error dalam satu disk. Artinya, saat Anda memulihkan dari snapshot, database MySQL Anda harus menjalankan langkah-langkah pemulihan InnoDB normal untuk mengembalikan file log dan data 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 yang dikonfigurasi MySQL 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. Kosongkan semua buffer yang sedang diproses ke disk menggunakan perintah LOCK INSTANCE FOR BACKUP dan FLUSH TABLES WITH READ LOCK.
  3. Mulai operasi snapshot.

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

Setelah mengambil snapshot awal database, Anda tidak perlu terus mengunci disk, karena Hyperdisk dengan cepat mengambil tampilan pada satu titik waktu, lalu dapat memproses langkah-langkah penyalinan 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