Mysqldump adalah utilitas klien yang digunakan untuk melakukan backup logis dari database MySQL. Alat migrasi populer ini berguna untuk berbagai kasus penggunaan MySQL seperti:
- Cadangkan dan pulihkan database.
- Memigrasikan data dari satu server ke server lain.
- Memigrasikan data di berbagai penyedia layanan MySQL terkelola.
- Memigrasikan data antar versi MySQL yang berbeda.
Mysqldump bekerja dengan membaca objek database sumber dan menghasilkan serangkaian pernyataan SQL yang disimpan dalam file dump. Dengan memutar ulang pernyataan ini di server database tujuan, data asli direkonstruksi. Karena model ini menggunakan pembacaan seluruh database dan kemudian pada dasarnya membangun kembali, baik dump maupun restore adalah operasi yang memakan waktu untuk database besar. Prosesnya bahkan mungkin menjadi rumit jika Anda mengalami kesalahan selama membuang atau memulihkan karena dapat menyebabkan Anda memperbaiki masalah dan menjalankan kembali operasi. Inilah sebabnya mengapa penting untuk merencanakan dengan baik sebelum Anda melakukan dump dan memulihkan aktivitas.
Dalam seri blog 2 bagian ini, kami membahas beberapa aspek umum yang harus Anda tangani di awal untuk memastikan aktivitas dump dan pemulihan yang berhasil. Di bagian pertama, kami fokus pada prasyarat yang perlu Anda perhatikan saat mengimpor data tabel MySQL dan di bagian kedua, kita akan berbicara tentang cara menangani impor untuk objek dan tampilan program yang disimpan.
1. Persyaratan ruang
Pertama, penting untuk memastikan bahwa volume database tujuan Anda memiliki ruang yang cukup untuk menampung data yang diimpor. Secara khusus, Anda harus berhati-hati jika log biner diaktifkan pada database MySQL tujuan Anda, karena log biner yang dihasilkan saat mengimpor data mungkin berukuran hampir sama dengan data itu sendiri. Log biner diperlukan jika Anda ingin memulihkan data Anda di satu server dan ingin itu direplikasi. Dalam kasus seperti itu, sebaiknya rencanakan ukuran tujuan yang lebih besar dari dua kali ukuran database sumber.
Hal ini juga penting untuk memastikan ruang yang cukup tersedia pada volume di mana Anda menghasilkan file output mysqldump. Tanpa tindakan pencegahan ini, Anda mungkin melihat dump atau restore Anda gagal karena ruang yang tidak mencukupi setelah berjalan untuk waktu yang lama yang kehilangan waktu dan usaha produktif Anda.
2. Sql_mode
pengaturan sql_mode untuk server MySQL menentukan sintaks pernyataan SQL dan pemeriksaan validasi data yang dilakukan server untuk operasi. Penting untuk memastikan sql_mode sumber dan tujuan server MySQL kompatibel satu sama lain, atau Anda mungkin mengalami kegagalan saat memulihkan dump yang telah Anda ambil. Mari kita tunjukkan ini dengan sebuah contoh.
Misalnya Anda memiliki tabel di sumber Anda yang memiliki kolom tanggal yang memiliki entri sebagai tanggal nol:
mysql> show create table sched; --------------------------------------------------------+ | Table | Create Table | --------------------------------------------------------+ | sched | CREATE TABLE `sched` ( `id` int(11) DEFAULT NULL, `ts` date DEFAULT NULL ) ENGINE=InnoDB DEFAULT CHARSET=latin1 | +-------+--------------------------------------------------------------------------------------------------------------------- mysql> select * from sched; +------+------------+ | id | ts | +------+------------+ | 1 | 2020-01-12 | | 2 | 0000-00-00 | +------+------------+
Misalkan sql_mode yang ketat (dan NO_ZERO_DATE ) dinonaktifkan pada sumber, tetapi diaktifkan pada tujuan – memulihkan baris tersebut akan mengakibatkan kegagalan seperti:
ERROR 1292 (22007) at line 40: Incorrect date value: '0000-00-00' for column 'ts’' at row 2
Anda biasanya akan melihat masalah seperti itu jika menggunakan compact dump dengan mengaktifkan opsi compact sebagai bagian dari mysqldump Anda.
Jika compact dinonaktifkan (yang secara default) maka Anda tidak akan menghadapi masalah ini karena mysqldump menghasilkan pernyataan kondisional berikut sebagai bagian dari dump:
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE,SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
Ini berarti bahwa selama pemulihan sql_mode diatur ke 'NO_AUTO_VALUE_ON_ZERO' sebelum memulihkan data tabel sehingga pemulihan berjalan dengan baik.
3. Unique_checks dan foreign_key_checks
Secara default (jika Anda tidak menggunakan opsi –compact), mysqldump juga menyetel yang berikut:
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */; /*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
Seperti yang dijelaskan di sini, Anda dapat mempercepat operasi pemulihan dengan mematikan sementara pemeriksaan keunikan selama sesi. Untuk tabel besar, ini menghemat banyak I/O disk karena InnoDB dapat menggunakan buffer perubahannya untuk menulis catatan indeks sekunder dalam satu batch.
Jika Anda memiliki FOREIGN KEY kendala dalam tabel Anda, Anda dapat mempercepat operasi pemulihan tabel dengan mematikan pemeriksaan kunci asing selama sesi pemulihan:Untuk tabel besar, ini dapat menghemat banyak I/O disk.
Menonaktifkan FOREIGN_KEY_CHECKS juga akan membantu menghindari kesalahan karena pemeriksaan batasan kunci sebelumnya selama operasi pemulihan. Setiap kali tabel dengan batasan kunci foregin dibuat, MySQL mengharapkan bahwa tabel induk yang dirujuk oleh kunci awal sudah ada. Ini adalah masalah karena utilitas mysqldump membuang tabel dalam urutan abjad. Mari kita ambil contoh untuk menunjukkan hal ini.
Pada database sumber, kami memiliki dua tabel:
CREATE TABLE `solution_table` ( `num1` int(11) NOT NULL, `num2` int(11) DEFAULT NULL, PRIMARY KEY (`num1`)); CREATE TABLE `ref_table` ( `key` int(11) DEFAULT NULL, `ref_num` int(11) DEFAULT NULL, KEY `ref_num` (`ref_num`), CONSTRAINT `ref_num_ibfk_1` FOREIGN KEY (`ref_num`) REFERENCES `solution_table` (`num1`) )
Tabel ref_table memiliki batasan kunci asing yang mereferensikan solution_table . Berdasarkan urutan abjad, mysqldump pertama-tama membuang konten ref_table . Ketika ini diputar ulang pada saat pemulihan, itu akan gagal dengan kesalahan:
ERROR 1215 (HY000) at line 50: Cannot add foreign key constraint -
Yang terjadi saat menjalankan pernyataan buat tabel untuk ‘ref_table’ .
Ringkasnya, waspadai masalah yang mungkin Anda alami, jika Anda menentukan --compact pilihan saat menjalankan mysqldump.
4. Hak istimewa diperlukan untuk menjalankan mysqldump
Hak istimewa minimum yang diperlukan oleh mysqldump untuk membuang database adalah SELECT pada basis data itu.
Namun, jika database Anda memiliki tampilan, Anda juga memerlukan izin SHOW VIEW, karena mysqldump selalu membuang tampilan bersama dengan tabel database. Misalkan Anda tidak memiliki SHOW VIEW izin, maka mysqldump akan gagal dengan:
mysqldump: Couldn't execute 'show create table `ivew`': SHOW VIEW command denied to user ‘dumpuser’@'172.31.18.79' for table 'iview' (1142)
Hal menarik lainnya adalah jika dumpuser Anda memiliki SELECT izin hanya pada tabel tertentu dari database, mysqldump akan membuang data hanya untuk tabel tertentu dan secara otomatis mengabaikan tabel atau tampilan lainnya.
Jadi, harap pastikan bahwa pengguna yang menjalankan mysqldump memiliki semua hak istimewa yang sesuai di awal untuk menghindari kejutan atau kegagalan di lain waktu.
|
5. Max_allowed_packet
Paket komunikasi terbesar yang ditangani oleh mysql ditentukan oleh pengaturan max_allowed_packet . Dalam konteks impor, paket komunikasi adalah pernyataan SQL tunggal yang dikirim ke server MySQL selama pemulihan ATAU satu baris yang dikirim ke klien selama dump.
Nilai default max_allowed_packet untuk mysqldump adalah 24MB. jika mysqldump menerima paket yang lebih besar dari ini, maka Anda mungkin mengalami kesalahan:
mysqldump: Error 2020: Got packet bigger than 'max_allowed_packet' bytes when dumping table `huge1` at row: 2.
Jadi pastikan mysqldump menggunakan nilai max_allowed_packet yang sama atau lebih besar yang dikonfigurasi pada instance MySQL sumber.
Opsi dapat ditentukan dengan tanda --max-allowed-packet=value saat menjalankan mysqldump.
Saat memulihkan dump, pastikan max_allowed_packet ukuran server tujuan Anda cukup besar untuk menerima paket dari file dump.
Jika tidak, selama pemulihan dump, Anda akan melihat pesan kesalahan:
ERROR 2006 (HY000) at line 70: MySQL server has gone away
Kesalahan ini dapat sedikit menyesatkan karena Anda mungkin berpikir bahwa server MySQL telah dimatikan atau macet. Tapi, itu hanya berarti bahwa server telah menerima paket berukuran lebih besar dari ukuran yang dikonfigurasi max_allowed_packet . Sekali lagi, praktik terbaik adalah memastikan bahwa max_allowed_packet nilai untuk server tujuan Anda sama dengan nilai di server sumber. Ini juga merupakan pengaturan penting yang dapat diperiksa dan disetel dengan tepat di awal, daripada menghadapi kesalahan di lain waktu.
Di bagian pertama dari seri mysqldump ini, kita membahas prasyarat untuk operasi dump dan restore yang sukses untuk database MySQL besar untuk membantu Anda menghindari beberapa upaya dan menghabiskan waktu yang tidak produktif.
Pada bagian selanjutnya, kita akan membahas praktik terbaik untuk mengimpor program dan tampilan yang tersimpan dari database MySQL Anda.
