Cara Melakukan Perubahan Skema di MySQL &MariaDB dengan Cara yang Aman

Sebelum Anda mencoba untuk melakukan perubahan skema pada database produksi Anda, Anda harus memastikan bahwa Anda memiliki rencana rollback yang solid; dan bahwa prosedur perubahan Anda telah berhasil diuji dan divalidasi di lingkungan yang terpisah. Pada saat yang sama, Anda bertanggung jawab untuk memastikan bahwa perubahan tersebut tidak menimbulkan dampak apa pun atau sesedikit mungkin yang dapat diterima oleh bisnis. Ini jelas bukan tugas yang mudah.

Pada artikel ini, kita akan melihat bagaimana melakukan perubahan database pada MySQL dan MariaDB secara terkontrol. Kami akan berbicara tentang beberapa kebiasaan baik dalam pekerjaan DBA Anda sehari-hari. Kami akan fokus pada pra-persyaratan dan tugas selama operasi aktual dan masalah yang mungkin Anda hadapi saat menangani perubahan skema database. Kami juga akan berbicara tentang alat sumber terbuka yang dapat membantu Anda dalam prosesnya.

Skenario Uji dan Kembalikan

Cadangan

Ada banyak cara untuk kehilangan data Anda. Kegagalan upgrade skema adalah salah satunya. Tidak seperti kode aplikasi, Anda tidak dapat menjatuhkan bundel file dan menyatakan bahwa versi baru telah berhasil digunakan. Anda juga tidak bisa begitu saja mengembalikan kumpulan file lama untuk mengembalikan perubahan Anda. Tentu saja, Anda dapat menjalankan skrip SQL lain untuk mengubah database lagi, tetapi ada kasus ketika satu-satunya cara akurat untuk mengembalikan perubahan adalah dengan memulihkan seluruh database dari cadangan.

Namun, bagaimana jika Anda tidak mampu mengembalikan basis data ke cadangan terbaru, atau periode pemeliharaan Anda tidak cukup besar (mengingat kinerja sistem), sehingga Anda tidak dapat melakukan pencadangan basis data lengkap sebelum perubahan?

Seseorang mungkin memiliki lingkungan yang canggih dan berlebihan, tetapi selama data dimodifikasi baik di lokasi utama maupun lokasi siaga, tidak banyak yang bisa dilakukan tentang hal itu. Banyak skrip hanya dapat dijalankan sekali, atau perubahan tidak mungkin dibatalkan. Sebagian besar kode perubahan SQL dibagi menjadi dua kelompok:

• Jalankan sekali – Anda tidak dapat menambahkan kolom yang sama ke tabel dua kali.
• Tidak mungkin untuk diurungkan – setelah Anda menjatuhkan kolom itu, kolom itu akan hilang. Anda pasti dapat memulihkan basis data Anda, tetapi itu bukan pembatalan.

Anda dapat mengatasi masalah ini setidaknya dalam dua cara yang mungkin. Salah satunya adalah mengaktifkan log biner dan mengambil cadangan, yang kompatibel dengan PITR. Cadangan tersebut harus lengkap, lengkap, dan konsisten. Untuk xtrabackup, selama berisi kumpulan data lengkap, itu akan kompatibel dengan PITR. Untuk mysqldump, ada opsi untuk membuatnya kompatibel dengan PITR juga. Untuk perubahan yang lebih kecil, variasi cadangan mysqldump adalah dengan mengambil hanya sebagian data untuk diubah. Ini dapat dilakukan dengan opsi --where. Cadangan harus menjadi bagian dari pemeliharaan yang direncanakan.

mysqldump -u -p --lock-all-tables --where="WHERE employee_id=100" mydb employees> backup_table_tmp_change_07132018.sql

Kemungkinan lain adalah menggunakan CREATE TABLE AS SELECT.

Anda dapat menyimpan data atau perubahan struktur sederhana dalam bentuk tabel sementara tetap. Dengan pendekatan ini Anda akan mendapatkan sumber jika Anda perlu mengembalikan perubahan Anda. Ini mungkin sangat berguna jika Anda tidak mengubah banyak data. Rollback dapat dilakukan dengan mengambil data darinya. Jika ada kegagalan yang terjadi saat menyalin data ke tabel, data tersebut akan dihapus secara otomatis dan tidak dibuat, jadi pastikan pernyataan Anda membuat salinan yang Anda butuhkan.

Jelas, ada beberapa batasan juga.

Karena urutan baris dalam pernyataan SELECT yang mendasarinya tidak selalu dapat ditentukan, CREATE TABLE ... IGNORE SELECT dan CREATE TABLE ... REPLACE SELECT ditandai sebagai tidak aman untuk replikasi berbasis pernyataan. Pernyataan tersebut menghasilkan peringatan di log kesalahan saat menggunakan mode berbasis pernyataan dan ditulis ke log biner menggunakan format berbasis baris saat menggunakan mode CAMPURAN.

Contoh yang sangat sederhana dari metode tersebut adalah:

CREATE TABLE tmp_employees_change_07132018 AS SELECT * FROM employees where employee_id=100;
UPDATE employees SET salary=120000 WHERE employee_id=100;
COMMMIT;

Opsi menarik lainnya mungkin database kilas balik MariaDB. Ketika pembaruan atau penghapusan yang salah terjadi, dan Anda ingin kembali ke keadaan database (atau hanya tabel) pada titik waktu tertentu, Anda dapat menggunakan fitur kilas balik.

Rollback point-in-time memungkinkan DBA untuk memulihkan data lebih cepat dengan memutar kembali transaksi ke titik waktu sebelumnya daripada melakukan pemulihan dari cadangan. Berdasarkan peristiwa DML berbasis ROW, kilas balik dapat mengubah log biner dan tujuan sebaliknya. Itu berarti dapat membantu membatalkan perubahan baris yang diberikan dengan cepat. Misalnya, itu dapat mengubah acara DELETE menjadi INSERT dan sebaliknya, dan itu akan menukar bagian WHERE dan SET dari acara UPDATE. Ide sederhana ini dapat secara dramatis mempercepat pemulihan dari jenis kesalahan atau bencana tertentu. Bagi mereka yang akrab dengan database Oracle, ini adalah fitur yang terkenal. Keterbatasan kilas balik MariaDB adalah kurangnya dukungan DDL.

Buat Budak Replikasi Tertunda

Sejak versi 5.6, MySQL mendukung replikasi tertunda. Server budak dapat tertinggal dari master setidaknya dalam jangka waktu tertentu. Penundaan default adalah 0 detik. Gunakan opsi MASTER_DELAY untuk CHANGE MASTER TO untuk menyetel penundaan ke N detik:

CHANGE MASTER TO MASTER_DELAY = N;

Ini akan menjadi pilihan yang baik jika Anda tidak punya waktu untuk mempersiapkan skenario pemulihan yang tepat. Anda harus memiliki penundaan yang cukup untuk melihat perubahan yang bermasalah. Keuntungan dari pendekatan ini adalah Anda tidak perlu memulihkan database Anda untuk mengambil data yang diperlukan untuk memperbaiki perubahan Anda. Standby DB aktif dan berjalan, siap untuk mengambil data yang meminimalkan waktu yang dibutuhkan.

Buat Asynchronous Slave Yang Bukan Bagian dari Cluster

Untuk klaster Galera, menguji perubahan bukanlah hal yang mudah. Semua node menjalankan data yang sama, dan beban berat dapat merusak kontrol aliran. Jadi, Anda tidak hanya perlu memeriksa apakah perubahan berhasil diterapkan, tetapi juga apa dampaknya terhadap status cluster. Untuk membuat prosedur pengujian Anda sedekat mungkin dengan beban kerja produksi, Anda mungkin ingin menambahkan slave asinkron ke cluster Anda dan menjalankan pengujian Anda di sana. Pengujian tidak akan memengaruhi sinkronisasi antar node cluster, karena secara teknis ini bukan bagian dari cluster, tetapi Anda akan memiliki opsi untuk memeriksanya dengan data nyata. Budak tersebut dapat dengan mudah ditambahkan dari ClusterControl.

Seperti yang ditunjukkan pada tangkapan layar di atas, ClusterControl dapat mengotomatiskan proses penambahan budak asinkron dalam beberapa cara. Anda dapat menambahkan node ke cluster, menunda budak. Untuk mengurangi dampak pada master, Anda dapat menggunakan cadangan yang ada alih-alih master sebagai sumber data saat membuat slave.

Basis Data Klon dan Waktu Ukur

Pengujian yang baik harus sedekat mungkin dengan perubahan produksi. Cara terbaik untuk melakukannya adalah dengan mengkloning lingkungan Anda yang ada.

Lakukan Perubahan melalui Replikasi

Untuk memiliki kontrol yang lebih baik atas perubahan Anda, Anda dapat menerapkannya di server budak sebelumnya dan kemudian melakukan peralihan. Untuk replikasi berbasis pernyataan, ini berfungsi dengan baik, tetapi untuk replikasi berbasis baris, ini dapat bekerja hingga tingkat tertentu. Replikasi berbasis baris memungkinkan kolom tambahan ada di akhir tabel, jadi selama itu bisa menulis kolom pertama, itu akan baik-baik saja. Pertama-tama terapkan pengaturan ini ke semua budak, lalu failover ke salah satu budak dan kemudian terapkan perubahan ke master dan lampirkan itu sebagai budak. Jika modifikasi Anda melibatkan penyisipan atau penghapusan kolom di tengah tabel, itu akan berfungsi dengan replikasi berbasis baris.

Operasi

Selama jendela pemeliharaan, kami tidak ingin memiliki lalu lintas aplikasi di database. Terkadang sulit untuk mematikan semua aplikasi yang tersebar di seluruh perusahaan. Atau, kami ingin mengizinkan hanya beberapa host tertentu untuk mengakses MySQL dari jarak jauh (misalnya sistem pemantauan atau server cadangan). Untuk tujuan ini, kita dapat menggunakan filter paket Linux. Untuk melihat aturan packet filtering yang tersedia, kita dapat menjalankan perintah berikut:

iptables -L INPUT -v

Untuk menutup port MySQL pada semua antarmuka yang kami gunakan:

iptables -A INPUT -p tcp --dport mysql -j DROP

dan untuk membuka kembali port MySQL setelah jendela pemeliharaan:

iptables -D INPUT -p tcp --dport mysql -j DROP

Bagi mereka yang tidak memiliki akses root, Anda dapat mengubah max_connection menjadi 1 atau 'lewati jaringan'.

Log

Untuk memulai proses logging, gunakan perintah tee pada prompt klien MySQL, seperti ini:

mysql> tee /tmp/my.out;

Perintah itu memberitahu MySQL untuk mencatat input dan output dari sesi login MySQL Anda saat ini ke file bernama /tmp/my.out. Kemudian jalankan file skrip Anda dengan perintah sumber.

Untuk mendapatkan gambaran yang lebih baik tentang waktu eksekusi Anda, Anda dapat menggabungkannya dengan fitur profiler. Mulai profiler dengan

SET profiling = 1;

Kemudian jalankan Query Anda dengan

SHOW PROFILES;

Anda melihat daftar kueri yang statistiknya dimiliki oleh profiler. Jadi akhirnya, Anda memilih kueri mana yang akan diperiksa

SHOW PROFILE FOR QUERY 1;

Alat Migrasi Skema

Sering kali, ALTER lurus pada master tidak dimungkinkan - sebagian besar kasus menyebabkan kelambatan pada slave, dan ini mungkin tidak dapat diterima oleh aplikasi. Namun, apa yang bisa dilakukan adalah menjalankan perubahan dalam mode bergulir. Anda dapat memulai dengan slave dan, setelah perubahan diterapkan ke slave, migrasikan salah satu slave sebagai master baru, turunkan master lama menjadi slave, dan jalankan perubahan di atasnya.

Alat yang dapat membantu tugas tersebut adalah pt-online-schema-change milik Percona. Pt-online-schema-change sangat mudah - ini membuat tabel sementara dengan skema baru yang diinginkan (misalnya, jika kita menambahkan indeks, atau menghapus kolom dari tabel). Kemudian, itu membuat pemicu di tabel lama. Pemicu itu ada untuk mencerminkan perubahan yang terjadi pada tabel asli ke tabel baru. Perubahan dicerminkan selama proses perubahan skema. Jika baris ditambahkan ke tabel asli, itu juga ditambahkan ke yang baru. Ini mengemulasi cara MySQL mengubah tabel secara internal, tetapi bekerja pada salinan tabel yang ingin Anda ubah. Artinya tabel asli tidak terkunci, dan klien dapat terus membaca dan mengubah data di dalamnya.

Demikian juga, jika sebuah baris diubah atau dihapus pada tabel lama, itu juga diterapkan pada tabel baru. Kemudian, proses latar belakang penyalinan data (menggunakan LOW_PRIORITY INSERT) antara tabel lama dan baru dimulai. Setelah data disalin, RENAME TABLE dijalankan.

Alat menarik lainnya adalah gh-ost. Gh-ost membuat tabel sementara dengan skema yang diubah, seperti yang dilakukan pt-online-schema-change. Ini mengeksekusi kueri INSERT, yang menggunakan pola berikut untuk menyalin data dari tabel lama ke tabel baru. Namun demikian itu tidak menggunakan pemicu. Sayangnya pemicu mungkin menjadi sumber dari banyak keterbatasan. gh-ost menggunakan aliran log biner untuk menangkap perubahan tabel dan menerapkannya secara asinkron ke tabel hantu. Setelah kami memverifikasi bahwa gh-ost dapat menjalankan perubahan skema kami dengan benar, saatnya untuk benar-benar menjalankannya. Ingatlah bahwa Anda mungkin perlu secara manual menghapus tabel lama yang dibuat oleh gh-ost selama proses pengujian migrasi. Anda juga dapat menggunakan flag --initial-drop-ghost-table dan --initial-drop-old-table untuk meminta gh-ost melakukannya untuk Anda. Perintah terakhir untuk dieksekusi sama persis dengan yang kita gunakan untuk menguji perubahan kita, kita baru saja menambahkan --execute ke dalamnya.

pt-online-schema-change dan gh-ost sangat populer di kalangan pengguna Galera. Namun demikian, Galera memiliki beberapa opsi tambahan. Kedua metode Total Order Isolation (TOI) dan Rolling Schema Upgrade (RSU) memiliki pro dan kontra.

TOI - Ini adalah metode replikasi DDL default. Node yang memulai writeset mendeteksi DDL pada waktu parsing dan mengirimkan peristiwa replikasi untuk pernyataan SQL bahkan sebelum memulai pemrosesan DDL. Upgrade skema berjalan pada semua node cluster dalam urutan urutan total yang sama, mencegah transaksi lain dari melakukan selama operasi. Metode ini bagus jika Anda ingin upgrade skema online Anda direplikasi melalui cluster dan tidak keberatan mengunci seluruh tabel (mirip dengan bagaimana perubahan skema default terjadi di MySQL).

SET GLOBAL wsrep_OSU_method='TOI';

RSU - melakukan upgrade skema secara lokal. Dalam metode ini, penulisan Anda hanya memengaruhi node tempat mereka dijalankan. Perubahan tidak mereplikasi ke cluster lainnya. Metode ini bagus untuk operasi yang tidak bertentangan dan tidak akan memperlambat cluster.

SET GLOBAL wsrep_OSU_method='RSU';

Saat node memproses upgrade skema, node tersebut melakukan desinkronisasi dengan cluster. Ketika selesai memproses upgrade skema, itu menerapkan peristiwa replikasi tertunda dan menyinkronkan dirinya dengan cluster. Ini bisa menjadi pilihan yang baik untuk menjalankan kreasi indeks berat.

Kesimpulan

Kami menyajikan di sini beberapa metode berbeda yang dapat membantu Anda merencanakan perubahan skema Anda. Tentu saja itu semua tergantung pada aplikasi dan kebutuhan bisnis Anda. Anda dapat merancang rencana perubahan Anda, melakukan tes yang diperlukan, tetapi masih ada kemungkinan kecil bahwa ada sesuatu yang salah. Menurut hukum Murphy - "segala sesuatunya akan salah dalam situasi tertentu, jika Anda memberi mereka kesempatan". Jadi, pastikan Anda mencoba berbagai cara untuk melakukan perubahan ini, dan pilih salah satu yang paling nyaman bagi Anda.