Praktik Terbaik mysqldump:Bagian 2 – Panduan Migrasi

Di bagian kedua dan terakhir dari praktik terbaik mysqldump, kita akan berbicara tentang cara menangani migrasi dan impor untuk objek dan tampilan program yang tersimpan dari database MySQL Anda. Untuk membaca lebih lanjut tentang prasyarat untuk operasi dump dan restore yang sukses untuk database MySQL besar, lihat bagian pertama dari seri blog 2 bagian ini.

Mengimpor prosedur, fungsi, dan pemicu Anda yang tersimpan

Secara default, mysqldump mengimpor tampilan dan pemicu. Namun itu tidak mengimpor prosedur, fungsi, dan acara. Untuk mengimpor prosedur dan fungsi, --routines opsi harus ditentukan, dan untuk mengimpor acara, --events opsi harus ditentukan.

1. Mengimpor pemicu

Mysqldump akan mencoba membuang semua pemicu di database Anda secara default. Untuk dapat membuang triggers tabel , Anda harus memiliki TRIGGER hak istimewa untuk tabel. Jika pengguna dump tidak memiliki hak istimewa ini, pemicu akan dilewati dan mysqldump tidak akan menimbulkan kesalahan apa pun. Jadi, jangan kaget jika Anda tidak melihat pemicu apa pun yang diimpor ke database tujuan Anda.

2. Mengimpor acara

Untuk mengimpor acara, Anda perlu menentukan --events opsi saat menjalankan utilitas mysqldump. Opsi ini memerlukan EVENT hak istimewa untuk database tersebut. Sekali lagi, mysqldump akan melewatkan event secara diam-diam jika pengguna dump tidak memiliki hak istimewa ini, bahkan jika Anda telah menentukan opsi –event saat menjalankan mysqldump.

3. Mengimpor fungsi dan prosedur tersimpan

Untuk mengimpor rutinitas, Anda perlu menentukan --routines opsi saat menjalankan utilitas mysqldump. Opsi ini memerlukan global select hak istimewa. Bahkan dalam kasus ini, mysqldump diam-diam akan melewatkan fungsi dan prosedur jika pengguna dump tidak memiliki hak istimewa ini, bahkan jika Anda telah menentukan --routines pilihan saat menjalankan mysqldump.

3.1 Mengimpor fungsi non-deterministik

Program tersimpan yang mengubah data disebut non-deterministik jika tidak menghasilkan hasil yang dapat diulang. Contoh fungsi rand(). Sangat menantang untuk menggunakan fungsi tersebut dalam pengaturan yang direplikasi, karena dapat menghasilkan data yang berbeda pada sumber dan replika. Untuk mengontrol kemungkinan tersebut, MySQL memberlakukan batasan tertentu pada pembuatan fungsi jika log biner diaktifkan.

Secara default, untuk CREATE FUNCTION pernyataan yang akan diterima, setidaknya satu dari DETERMINISTIC , NO SQL , atau READS SQL DATA harus ditentukan secara eksplisit. Jika tidak, akan terjadi kesalahan:

ERROR 1418 (HY000) pada baris 181:Fungsi ini tidak memiliki DETERMINISTIC, NO SQL, atau READS SQL DATA dalam deklarasinya dan logging biner diaktifkan (Anda *mungkin* ingin menggunakan log_bin_trust_funable yang kurang aman)

Jadi, jika fungsi Anda tidak dideklarasikan sebagai deterministik pada sumbernya, dan pencatatan log biner diaktifkan di tujuan Anda, Anda akan melihat kesalahan di atas selama pemulihan dump. Oleh karena itu, penting untuk memahami sifat deterministik dari fungsi Anda di muka. Jika Anda yakin bahwa fungsi Anda bersifat deterministik, Anda perlu mengaktifkan log_bin_trust_function_creators konfigurasi di tujuan Anda sebelum operasi pemulihan. Saat diaktifkan, MySQL memungkinkan pembuatan fungsi tersebut bahkan ketika pencatatan log biner diaktifkan.

4. Karakteristik SQL SECURITY dari rutinitas dan tampilan yang disimpan.

MySQL mengizinkan SQL SECURITY konteks yang akan ditentukan saat membuat program atau tampilan toko. SQL SECURITY karakteristik dapat ditentukan sebagai DEFINER atau INVOKER . Jika SQL_SECURITY konteksnya adalah DEFINER , rutinitas dijalankan menggunakan hak istimewa akun yang disebutkan dalam DEFINER routine rutin ayat. Jika konteksnya adalah INVOKER , rutin dijalankan menggunakan hak istimewa pengguna yang memanggilnya. Nilai defaultnya adalah DEFINER .

Jika Anda memulihkan rutinitas atau tampilan yang disimpan, Anda perlu memastikan akun pengguna penentu ada di database tujuan Anda dengan pemberian yang sesuai. Jika tidak, Anda akan mengalami kegagalan selama pemulihan.

Mari kita tunjukkan ini dengan contoh yang terkait dengan tampilan.

Misalkan Anda memiliki definisi Tampilan V1 dan V2 seperti di bawah ini:

CREATE definer=admin@'%' VIEW mydb.V1 AS SELECT * FROM solution_table;CREATE definer=admin@'%' VIEW mydb.V2 AS SELECT * FROM V1 where num1=10;

Perhatikan bahwa tampilan dibuang secara default oleh mysqldump dan jika Anda tidak memiliki pengguna 'admin' di tujuan Anda, Anda akan menemukan kesalahan di bawah ini selama operasi pemulihan:

Perintah gagal dengan kesalahan - ERROR 1449 (HY000) pada baris 206 dalam file:'/mysql_data/mysqldump/sqldump_1582457155758.sql':Pengguna yang ditentukan sebagai penentu ('admin'@'%') tidak ada. 
Perhatikan bahwa tidak hanya cukup untuk memastikan keberadaan pengguna, tetapi pengguna harus memiliki hak istimewa yang sesuai untuk menjalankan tampilan. Misalnya jika pengguna admin@'%' ada di tujuan, tetapi tidak memiliki SELECT hak istimewa pada database mydb, Anda akan melihat pesan kesalahan:
 
'/mysql_data/mysqldump/sqldump_1582456858033.sql':Lihat referensi 'mydb.V2' tabel atau kolom atau fungsi yang tidak valid atau definisi/pemanggil tampilan tidak memiliki hak untuk menggunakannya. 
 
 
 
Tertarik dengan solusi MySQL yang terkelola sepenuhnya?
 

 Untuk mempelajari lebih lanjut tentang bagaimana penyedia DBaaS seperti ScaleGrid dapat membantu Anda mengelola database MySQL Anda, lihat halaman MySQL kami. Lihat bagaimana ScaleGrid dapat membuat Anda lebih fokus mengembangkan produk, dan lebih sedikit mengelola database.
 

 
 
 
 
 
 
 
 
 
Ringkasan
 

 Dalam seri blog 2 bagian ini, kami membahas prasyarat penting yang perlu Anda tangani untuk memastikan migrasi data dan program tersimpan Anda berhasil. ScaleGrid MySQL hosting menangani panduan ini untuk memberikan pengalaman yang lancar saat mengimpor data Anda ke platform ScaleGrid. Silakan bagikan kepada kami pengalaman dan praktik terbaik yang Anda terapkan untuk migrasi data MySQL!