Мигрирането на вашата база данни към нов център за данни може да бъде високорисков и отнемащ време процес. Базата данни съдържа състояние и може да бъде много по-трудна за мигриране в сравнение с уеб сървъри, опашки или кеш сървъри.
В тази публикация в блога ще ви дадем няколко съвета как да мигрирате данните си от един доставчик на услуги към друг. Процесът е донякъде подобен на предишната ни публикация за това как да надстроите MySQL, но има няколко важни разлики.
Репликация на MySQL или клъстер Galera?
Преминаването към друг доставчик на услуги (например преминаване от AWS към Rackspace или от локализирани сървъри към облак) много често означава, че човек ще изгради чисто нова инфраструктура паралелно, ще я синхронизира със старата инфраструктура и след това ще премине към нея. За да ги свържете и синхронизирате, може да искате да използвате MySQL репликация.
Ако използвате Galera Cluster, може да е по-лесно да преместите своите възли на Galera в друг център за данни. Имайте предвид обаче, че целият клъстер все още трябва да се третира като единна база данни. Това означава, че вашият производствен сайт може да страда от допълнителната латентност, въведена при разтягане на Galera Cluster върху WAN. Възможно е да се сведе до минимум въздействието чрез настройка на мрежовите настройки както в Galera, така и в операционната система, но въздействието не може да бъде напълно елиминирано. Възможно е също така вместо това да се настрои асинхронна MySQL репликация между стария и новия клъстер, ако въздействието на латентността не е приемливо.
Настройване на защитена връзка
MySQL репликацията е некриптирана и следователно не е безопасна за използване през WAN. Има много начини да се гарантира, че вашите данни ще бъдат прехвърлени безопасно. Трябва да проучите дали е възможно да се установи VPN връзка между текущата ви инфраструктура и новия ви доставчик на услуги. Повечето от доставчиците (например както Rackspace, така и AWS) предоставят такава услуга – можете да свържете своята „облачна“ част към съществуващия си център за данни чрез виртуална частна мрежа.
Ако по някаква причина това решение не работи за вас (може би изисква хардуер, до който нямате достъп), можете да използвате софтуер за изграждане на VPN - един от тях ще бъде OpenVPN. Този инструмент ще работи добре за настройка на криптирани връзки между вашите центрове за данни.
Ако OpenVPN не е опция, има повече начини да се гарантира, че репликацията ще бъде криптирана. Например, можете да използвате SSH, за да създадете тунел между стари и нови центрове за данни и да препратите порта 3306 от текущия подчинен (или главен) MySQL към новия възел. Може да се направи по много прост начин, стига да имате SSH връзка между хостовете:
$ ssh -L local_port:old_dc_host:mysql_port_in_old_dc [email protected]_dc_host -N &Например:
$ ssh -L 3307:10.0.0.201:3306 [email protected] -N &Сега можете да се свържете с отдалечения сървър, като използвате 127.0.0.1:3307
$ mysql -P3307 -h 127.0.0.1Ще работи по подобен начин за репликацията, просто не забравяйте да използвате 127.0.0.1 за master_host и 3307 за master_port
Не на последно място можете да шифровате вашата репликация с помощта на SSL. Тази предишна публикация в блога обяснява как може да се направи и какъв вид въздействие може да има върху производителността на репликацията.
Ако сте решили да използвате репликация на Galera в двата центъра за данни, горните предложения се прилагат и тук. Що се отнася до SSL, по-рано писахме в блог за това как да криптираме трафика за репликация на Galera. За по-пълно решение може да искате да шифровате всички връзки към базата данни от клиентски приложения и всяка инфраструктура за управление/мониторинг.
Настройване на новата инфраструктура
След като имате свързаност, трябва да започнете да изграждате новата инфраструктура. За това вероятно ще използвате xtrabackup или mariabackup. Може да е изкушаващо да комбинирате миграцията с надграждането на MySQL, в края на краищата вие настройвате изцяло нова среда на новото място. Не бихме препоръчали да правите това. Мигрирането към нова инфраструктура е достатъчно важно само по себе си, така че комбинирането му с друга голяма промяна увеличава сложността и риска. Това важи и за други неща - искате да предприемете стъпка по стъпка подход към промените. Само като променяте нещата едно по едно, можете да разберете резултатите от промените и как те влияят на работното ви натоварване – ако сте направили повече от една промяна в даден момент, не можете да сте сигурни коя е отговорна за дадена (нова ) поведение, което сте наблюдавали.
Когато имате нов екземпляр на MySQL и работи в новия център за данни, трябва да го изключите от възела в стария център за данни - за да сте сигурни, че данните в двата центъра за данни ще останат в синхрон. Това ще ви бъде удобно, докато се подготвяте за последното преминаване. Също така е приятен начин да се гарантира, че новата среда може да се справи с натоварването ви при запис.
Следващата стъпка ще бъде изграждането на цялостна инфраструктура на новото място и извършване на тестове и сравнителни показатели. Това е много важна стъпка, която не бива да се пропуска - проблемът тук е, че вие, като DBA, трябва да разберете капацитета на вашата инфраструктура. Когато смените доставчика, нещата също се променят. Новият хардуер/VM са по-бързи или по-бавни. Има повече или по-малко памет за екземпляр. Трябва отново да разберете как вашето работно натоварване ще се побере в хардуера, който ще използвате. За това вероятно ще използвате Percona Playback или pt-log-player, за да възпроизведете някои от заявките от реалния живот в системата за сцениране. Ще искате да тествате производителността и да се уверите, че е на ниво, което е приемливо за вас. Вие също искате да извършите всички стандартни тестове за приемане, които изпълнявате на новите си издания - само за да потвърдите, че всичко е готово и работи. Като цяло всички приложения трябва да бъдат изградени по начин, който да не разчита на хардуерната конфигурация и на текущата настройка. Но нещо може да се е промъкнало и приложението ви може да зависи от някои от настройките на конфигурацията или хардуерните решения, които нямате в новата среда.
И накрая, след като сте доволни от тестовете си, ще искате да изградите готова за производство инфраструктура. След като това е направено, може да искате да изпълните някои тестове само за четене за окончателна проверка. Това ще бъде последната стъпка преди преминаването.
Преход
След като всички тези тестове са били извършени и след като инфраструктурата е била счетена за готова за производство, последната стъпка е прекратяването на трафика от старата инфраструктура.
В световен мащаб това е сложен процес, но когато разглеждаме нивото на базата данни, това е повече или по-малко същото нещо като стандартното преминаване на отказ – нещо, което може да сте правили няколко пъти в миналото. Разгледахме го подробно в по-ранна публикация, накратко стъпките са:спрете трафика, уверете се, че е спрян, изчакайте, докато приложението се премести в новия център за данни (промяна на DNS записите или какво ли още не), направете някои тестове за дим, за да се уверите всичко изглежда добре, пуснете на живо, наблюдавайте внимателно за известно време.
Това превключване ще изисква известно време на престой, както виждаме. Проблемът е да се уверим, че имаме последователно състояние в стария и новия сайт. Ако искаме да го направим без прекъсване, тогава ще трябва да настроим главен-главен репликация. Причината е, че докато обновяваме DNS и преместваме сесиите от стария сайт към новия, двете системи ще се използват едновременно - докато всички сесии не бъдат пренасочени към новия сайт. Междувременно всички промени в новия сайт трябва да бъдат отразени на стария сайт.
Използването на Galera Cluster, както е описано в тази публикация в блога, също може да бъде начин за синхронизиране на данните между двата сайта.
Наясно сме, че това е много кратко описание на процеса на миграция на данни. Надяваме се, че това ще бъде достатъчно, за да ви насочи към добра посока и да ви помогне да определите каква допълнителна информация трябва да търсите.
