Големи организации, които използват MySQL или MariaDB платформи за бази данни, често се сблъскват с необходимостта да извършат миграция на база данни от едно място на друго. Независимо от платформата, типа софтуер за база данни (като от RDBMS към NoSQL или NoSQL, връщайки се към RDBMS), или ако това е просто миграция на данни, извършването на миграция е огромно количество работа и разходи.
Миграцията на база данни винаги ще включва процеса на мигриране на данни от една или повече бази данни източник към една или повече целеви бази данни. Това може да включва услуга за миграция на база данни или набор от инструменти, които инженерите са изградили за създаване на услуга и приспособяване към този вид проблем.
Очаква се, че миграцията на база данни не означава, че платформата на базата данни източник ще завърши своята целева платформа да бъде точно като източника на произход. След като миграцията приключи, наборът от данни от целевите бази данни може да бъде преструктуриран. Най-важното, след като миграцията е напълно извършена, е клиентите, които имат достъп до базата данни, да бъдат пренасочени към новоизходните бази данни. Новата изходна база данни трябва да предоставя точното копие на данните от източника и без въздействие върху производителността, което може да повлияе на цялостното потребителско изживяване.
Преместването на вашите данни от една платформа към целевата дестинационна платформа е огромна задача. Това обхваща миграцията на база данни, когато организация или компания реши да изключи светлината си към текущата платформа по множество причини. Често срещаните причини за мигриране на данни се дължат на рентабилността към целевата дестинационна платформа или на нейната гъвкавост при внедряване и мащабируемост. Въпреки че настоящата платформа, хостваща текущите производствени данни, причинява повече разходи за нейните надстройки и мащабируемост, тя е просто обременителна при внедряването на малки промени, които действително могат да бъдат внедрени в платформа за микросервизи.
В този блог ще се съсредоточим върху най-добрите инструменти с отворен код, които можете да използвате за миграции на MySQL и MariaDB при по-хомогенна миграция на база данни.
Инструменти за архивиране за миграция на данни
Най-лесният път за използване при извършване на миграция е използването на инструменти за архивиране на база данни. Ще разгледаме какви са тези инструменти и как можете да ги използвате по време на миграция.
mysqldump/mysqlpump
Този инструмент е една от най-известните помощни програми за MySQL или MariaDB, която администратор на база данни или системен администратор ще закачи този инструмент, за да мигрира или пълна база данни, или частично копие на базата данни. За администратори на база данни, които не са запознати с MySQL/MariaDB, този инструмент ще ви позволи да създадете копие на резервно копие, което ще генерира логическо копие на данни, което можете да изхвърлите в целевата база данни.
Честа настройка при използването на този инструмент е, когато целевата база данни се намира някъде другаде и се хоства на различна платформа от източника, целта действа като подчинена или реплика. Използването на mysqldump, което обикновено се извиква с --single-transaction в натоварена система и с --master-data, ще ви предостави координатите за настройване на подчинен в целевата база данни, който ще се използва като хост за миграция на данни. Алтернатива на mysqldump също е mysqlpump, но с по-малка функция, но може да извършва паралелна обработка на бази данни и на обекти в базите данни, за да ускори процеса на изхвърляне. Недостатъкът е, че с mysqlpump няма опция, която можете да използвате, като --master-data, което е много полезно, ако искате да създадете реплика, която ще се използва като целева дестинация за миграция на база данни.
mysqlpump е изгодно, ако вашите данни са по-скоро неактивни или са поставени в режим на поддръжка, така че да не се извършват обработени записи или промени в изходната база данни. Той е по-бърз и по-бърз в сравнение с mysqldump.
mydumper/myloader
mydumper/myloader е много изящен и ефективен инструмент, който можете да използвате за логическо архивиране, особено за импортиране на групови данни с по-бърза скорост на обработка, тъй като предлага паралелизъм, възможност за изпращане на данни на парчета, поддържа праг и контрол оценявайте броя на нишките, редовете, размера на изявлението и компресирайте резултата. Той генерира или включва двоичен регистрационен файл и позиции на регистрационни файлове, което е много полезно, ако настроите целевата дестинационна платформа да действа като реплика на текущата изходна и производствена среда.
По принцип mydumper е двоичният файл и командата, която трябва да извикате чрез командния ред за създаване на логическото архивиране. Докато myloader е двоичният файл и командата, която трябва да използвате, когато зареждате данни до желаната целева дестинация. Неговата гъвкавост ви позволява да управлявате желаната скорост при обработка на действията, независимо дали създавате резервно копие или зареждате данните. С помощта на mydumper можете също да създадете пълно архивно копие или само частично архивно копие на вашата изходна база данни. Това е много полезно в случай, че имате нужда от големи данни или схема, които искате да отдалечите от текущия хост на базата данни и леко да я преместите към друга целева дестинация, докато започнете да настройвате нова част от базата данни. Това също може да бъде един от начините за мигриране на големи данни, като издърпате огромен сегмент от набора от данни, след което го преместите, но като нов възел на фрагмента.
mydumper/myloader също има своите ограничения. Той е спрян от актуализации от оригиналните автори, но е запазен от Макс Бубе, но инструментът все още се използва широко дори за производствени среди.
Percona XtraBackup/MariaDB Backup
XtraBackup на Percona е подарък за администратори на бази данни, които не искат да използват и харчат пари за корпоративния Oracle MySQL Enterprise Backup. Докато MariaDB Backup е разклонен и произлиза от Percona XtraBackup, те също имат MariaDB Enterprise Backup.
И двата инструмента споделят едни и същи концепции при извършване или правене на резервно копие. Това е двоично архивиране, което предлага горещо онлайн архивиране, PITR, инкрементално и пълно архивиране, частично архивиране, също полезно за възстановяване на данни, тъй като разбира възстановяването, което създава двоичен лог файл и позиция, поддържа GTID и много повече. Въпреки че MariaDB Backup и Percona XtraBackup са два различни типа софтуер в днешно време, тъй като те са проектирани по-нататък, за да поддържат базата данни, насочена към осигуряване на архивиране. MariaDB Backup определено е приложим, ако възнамерявате да използвате или да правите резервни копия от източник на база данни на MariaDB. Докато Percona XtraBackup е приложим за Oracle MySQL, а също и за Percona Server или някои производни MySQL сървъри, като Percona XtraDB Server или версията на Codership на Galera Cluster за MySQL.
И двете резервни копия са много полезни за миграции на база данни. Извършването на горещо онлайн архивиране е по-бързо и по-бързо и създава резервно копие, което можете да използвате директно, за да го заредите в целевата си база данни. По-често поточно архивирането е удобно, както и като можете да извършите онлайн архивиране и да предавате поточно двоичните данни към целевата база данни, като използвате socat или netcat. Това ви позволява да съкратите времето на миграция, тъй като преместването на данни до целевата дестинация се предава директно.
Най-често срещаният подход за миграция на данни, докато използвате този инструмент, е да копирате данните от източника, след което да предавате данните към целевата дестинация. Веднъж в дестинацията на целевата база данни, можете просто да подготвите двоичното архивиране с опция --prepare, където тя прилага регистрационните файлове, записани по време на създаването на архива, така че ще копира пълните данни както са и точно от момента където бе взето резервното копие. След това задайте дестинацията на целевата база данни като реплика, която да действа като реплика или подчинен на съществуващия изходен клъстер и да репликирате всички онези промени и транзакции, които са настъпили от главния клъстер.
Разбира се, има и ограничение за използването на този инструмент, но администраторите на бази данни трябва да знаят как да използват този инструмент, както и как да регулират и персонализират използването в съответствие с желаната употреба. Може да не искате да заглушавате вашата база данни с източник, ако вашият източник отнема твърде много трафик или голяма обработка от това време. Неговото ограничение също така гарантира, че е хомогенна настройка, при която целевият източник е от съвместима с Linux система, а не в среда от тип Windows, тъй като Percona XtraBackup и MariaDB Backup работят само в средата на Linux.
Инструменти за мигриране на схема на база данни
Миграцията на база данни не говори сама за конкретен инструмент и конкретна задача, тогава миграцията може да се случи. Има много съображения и основни последващи задачи, които трябва да бъдат извършени, за да се извърши пълна миграция на база данни. Едно от тях е миграцията на схема или база данни. Схемата в MySQL/MariaDB е колекция от данни, която се състои от група таблици с нейните колони и редове, събития, тригери, съхранени процедури или рутинни процедури и функции. Има случаи, когато може да искате да мигрирате само схема или само таблица. Да кажем, че конкретна таблица в схема изисква промяна в структурата на таблицата и това изисква DDL израз. Проблемът е, че изпълняването на директен DDL израз като ALTER TABLE ...ENGINE=InnoDB блокира всички входящи транзакции или връзки, които също ще препращат или използват към целевата таблица. За някои огромни таблици, които включват дълга дефиниция на данни и структура на таблицата, това добавя повече истинско предизвикателство и също така усложнява повече, особено ако таблицата е гореща маса. Докато при миграция на база данни може да е трудно да се копира точното пълно копие на пълната таблица без прекъсване от източника. Така че нека видим какви са тези.
pt-online-schema-change
Това е част от известния инструментариум на Percona, който първоначално произлиза от Maatkit и Aspersa. Този инструмент е много полезен при извършване на промяна на дефиницията на таблица, особено за гореща таблица, състояща се от огромно количество данни. За някои често срещани, но наивни подходи за извършване на промяна на дефиницията на таблица, изпълнението на ALTER TABLE може да свърши работа. Въпреки че случаят е достатъчен, ALTER TABLE без използване на ALGORITHM=INPLACE причинява пълно копие на таблицата, което придобива пълно заключване на метаданни и това означава, че вашата база данни може да се натрупа и заключи за дълъг период от време, особено ако таблицата е огромен. В този случай този инструмент е създаден, за да реши този проблем. Този инструмент е много полезен за миграция на база данни по такъв начин, че да се открие непоследователно копие на гореща таблица с много огромни данни от вашата вече настроена целева база данни. Вместо да се извършва архивиране с помощта на логическо или двоично/физическо копие, може да се използва pt-online-schema-change, който копира редовете от таблицата източник в таблицата-приемник парче по парче. Можете дори да персонализирате командата с подходящи извиквания към нейните параметри в зависимост от вашите изисквания.
Освен използването, pt-online-schema-change също използва тригери. Чрез използване на тригери всеки последващ или текущ трафик, който се опитва да приложи промени в тази референтна таблица, също ще бъде копиран в целевата база данни, която действа като реплика на текущия клъстер от база данни източник. Това копира всички данни точно какви данни има изходната база данни до вашата целева база данни, която лежи на различна платформа, например. Използването на тригери е приложимо, за да се използва за MySQL и MariaDB, стига механизмът му да е InnoDB и да има първичен ключ в тази таблица, което е изискване. Може би знаете, че InnoDB използва механизъм за заключване на редове, който позволява, че за определен брой парчета (група от избрани записи), pt-online-schema-change ще се опита да копира това и след това ще приложи израза INSERT към целевата таблица . Целевата таблица е фиктивна таблица, която действа като целево копие на предстоящата подмяна на съществуващата таблица източник. pt-online-schema-change обаче позволява на потребителя или да премахне фиктивната таблица, или просто да остави фиктивната таблица на място, докато администраторът е готов да премахне тази таблица. Обърнете внимание, че пускането или премахването на таблица придобива заключване на метадани. Тъй като получава тригери, всички последващи промени трябва да бъдат копирани точно в целевата таблица, като не оставят несъответствия в целевата или фиктивната таблица.
gh-ost
Споделя същата концепция като pt-online-schema-change. Този инструмент подхожда по различен начин в сравнение с pt-online-schema-change. Ще кажа, че тази миграция на инструмента на схемата се доближава до онези базирани на производството пречки, които могат да доведат до забавяне на вашата база данни и евентуално блокиране, което води до падане на клъстера ви от база данни в режим на поддръжка или неизправност за неизвестен период от време, докато проблемът не бъде решен. Този проблем обикновено се причинява от тригери. Ако имате натоварена или гореща таблица, която е подложена на промяна на схемата или дефиницията на таблицата, тригерите могат да доведат до натрупване на база данни поради спор за заключване. MySQL/MariaDB тригери позволяват на вашата база данни да дефинира тригери за INSERT, UPDATE и DELETE. Ако целевата таблица е на гореща точка, тогава може да се окаже гадно. Вашата база данни започва да става по-бавна, докато не се блокира, освен ако не успеете да убиете тези входящи заявки или най-добре да премахнете тригерите, но идеалният подход не е това.
Поради тези проблеми gh-ost решава този проблем. Той действа така, сякаш има двоичен лог сървър, където входящите събития или транзакции се записват в двоичен дневник, по-специално използвайки RBR (Репликация, базирана на редове). Всъщност това е много безопасно и по-малко притеснения по отношение на въздействието, с което трябва да се сблъскате. Всъщност вие също имате възможност да направите тест или сухо изпълнение (същото като при pt-online-schema-change), но да го тествате директно в репликата или подчинен възел. Това е идеално, ако искате да поиграете и да проверите точното копие в целевата си база данни по време на миграция.
Този инструмент е много гъвкав в съответствие с вашите нужди и предполага гаранция, че вашият клъстер няма да блокира или вероятно в крайна сметка да извърши отказ или възстановяване на данни, ако се влоши. За повече информация и искате да научите този инструмент, предлагам да прочетете тази публикация от Github от Shlomi Noach.
Други OSC инструменти
Мога да кажа, че тези два инструмента са по-скоро препоръчителен подход, но можете да опитате и други алтернативи. Най-вече тези инструменти прилагат MySQL/MariaDB тригери, така че по някакъв начин споделя същата концепция като pt-online-schema-change. Ето следния списък:
- LHM – Миграциите на база данни в стил Rails са полезен начин за развитие на вашата схема на данни по гъвкав начин. Повечето проекти на Rails започват така и в началото правенето на промени е бързо и лесно.
- OnlineSchemaChange – Създаден и иницииран от Facebook. Този инструмент се използва за извършване на промени в схемата за MySQL таблици по неблокиращ начин
- TableMigrator – Иницииран от Serious Business и бивши служители на Twitter. Този инструмент споделя същия принцип с миграции с нулев престой на големи таблици в MySQL. Реализиран е с помощта на Rails, така че може да бъде полезен, ако имате среда на приложение Ruby-on-Rails.
- oak-online-alter-table - това е стар инструмент, създаден от Shlomi Noach, въпреки че по някакъв начин се доближава до същия подход като pt-online-schema-change и изпълнява неблокираща операция ALTER TABLE
Съветник за миграция на база данни
Има няколко инструмента за миграция, които предлагат безплатно използване, което е много полезно до известна степен. Това, което е по-изгодно при използването на инструменти на съветника за миграция, е, че те имат GUI, за който можете да имате удобството да видите текущата структура или просто да следвате стъпките, които потребителският интерфейс предоставя по време на миграцията. Може да има много услуги или съветници, но не е с отворен код и не е достъпен безплатно. Разбира се, миграцията на база данни е много сложен, но систематичен процес, но в някои случаи изисква голяма работа и усилия. Нека да разгледаме тези безплатни инструменти.
MySQL Workbench
Както подсказва името, това е за MySQL и производни бази данни като Percona Server например, могат да бъдат полезни, когато става въпрос за миграция на база данни. Тъй като MariaDB напълно премина към различен маршрут, особено след версията 10.2, има някои проблеми с несъвместимост, които може да срещнете, ако се опитате да използвате това от източник или цел на MariaDB. Workbench може да се използва за хетерогенни типове бази данни, като тези, идващи от различни бази данни източник и иска да изхвърли данните в MySQL.
MySQL Workbench се състои от общностни и корпоративни версии. И все пак версията на общността е свободно достъпна като GPL, която можете да намерите тук https://github.com/mysql/mysql-workbench. Както се посочва в документацията, MySQL Workbench ви позволява да мигрирате от Microsoft SQL Server, Microsoft Access, Sybase ASE, SQLite, SQL Anywhere, PostreSQL и други RDBMS таблици, обекти и данни към MySQL. Миграцията също така поддържа мигриране от по-ранни версии на MySQL към най-новите версии.
phpMyAdmin
За тези, които работят като уеб разработчици, използващи стека LAMP, този инструмент не е изненада, че е един от техните швейцарски армейски ножове, когато се занимават със задачи на база данни. phpMyAdmin е безплатен софтуерен инструмент, написан на PHP, предназначен да обработва администрирането на MySQL през мрежата. phpMyAdmin поддържа широк спектър от операции на MySQL и MariaDB. Често използваните операции (управление на бази данни, таблици, колони, релации, индекси, потребители, разрешения и т.н.) могат да се извършват чрез потребителския интерфейс, като все още имате възможността да изпълнявате директно всеки SQL израз.
Въпреки че е доста лесно, когато става въпрос за импортиране и експортиране, важното е, че свършва работата. Въпреки че за по-голяма и по-сложна миграция, това може да не е достатъчно за справяне с желаните от вас нужди.
HeidiSQL
HeidiSQL е безплатен софтуер и има за цел да бъде лесен за научаване. "Heidi" ви позволява да виждате и редактирате данни и структури от компютри, работещи с една от системите за бази данни MariaDB, MySQL, Microsoft SQL, PostgreSQL и SQLite. Изобретен през 2002 г. от Ansgar, HeidiSQL принадлежи към най-популярните инструменти за MariaDB и MySQL в световен мащаб.
За целите на миграцията ви позволява да експортирате от един сървър/база данни директно към друг сървър/база данни. Той също така има функции за импортиране, които позволяват текстови полета като CSV, както и експортиране на редове на таблицата също в широк спектър от поддържани типове файлове като CSV, HTML, XML, SQL, LaTeX, Wiki Markup и PHP Array. Въпреки че е създаден за управление на бази данни за администриране на db сървър, все пак можете да го използвате за прости неща за миграция.
Percona Toolkit като вашето швейцарско армейско ножче
Percona Toolkit е забележителен софтуер, който се разпространява като софтуер с отворен код под гаранцията на GPL. Percona Toolkit е колекция от усъвършенствани инструменти за команден ред, които обикновено се използват вътрешно от Percona, но е приложим и за всяка работа с база данни, особено за MySQL/MariaDB сървъри.
И така, как и защо е полезно и за миграция на данни, особено при миграции на MySQL/MariaDB? Те имат редица инструменти тук, които е полезно да се използват при миграция и след миграция.
Както беше споменато по-рано, често срещаният подход за миграция на данни е целевият дестинационен сървър да бъде копие на основния изходен клъстер от база данни, но в хомогенна настройка. Това означава, че ако ситуацията се движи от on-prem към доставчик на публичен облак, можете да настроите избран възел от тази платформа и този възел ще репликира всички транзакции от основния клъстер. С помощта на инструменти за архивиране може да успеете да постигнете този тип настройка за миграция. Но това не свършва дотук. Percona Toolkit има инструменти за pt-table-checksum/pt-table-sync, например, за да ви помогне да идентифицирате несъответствията на данните между on-prem спрямо целевия сървър на база данни дестинация. С pt-table-checksum можете да извършвате изчисления на контролна сума въз основа на серия от парчета за всички бази данни или просто избирателно контролна сума за определени бази данни, или конкретни таблици, или дори набор от записи на таблицата. pt-table-sync ще се използва за извършване на синхронизиране на данни, така че вашите целеви бази данни ще бъдат обновени отново с ново копие на точните данни от основния източник на клъстер.
От друга страна, pt-upgrade е много полезен след извършване на миграцията от инструменти за архивиране. С pt-upgrade можете да използвате този инструмент за извършване на анализ, като стартирате набор от заявки, например от бавен регистрационен файл на заявки. Тези резултати могат да се използват за сравняване от изходната база данни и спрямо целевия сървър на база данни.
Резюме
Миграцията на база данни, особено от хетерогенна настройка, може да бъде много сложна. И все пак при хомогенна настройка може да бъде доста просто; независимо дали данните са големи или малки, стига да сте оборудвани с подходящи инструменти и, разбира се, правилния систематичен подход, за да се определи, че миграцията е завършена, като данните са последователни. Може да има моменти, когато миграцията изисква консултация с експерти, но винаги е чудесно начало да излезете и да опитате с тези инструменти с отворен код, за да постигнете желаната задача за мигриране на база данни.
