MySQL 8.0 е наличен от известно време, а Percona XtraDB Cluster 8.0 също е наличен от известно време. Също така MySQL 5.6 идва към своя край на живота и хората, които използват PXC 5.6, също ще искат да мигрират към по-нова версия скоро. Нека да разгледаме процеса и да споделим някои съвети около него.
Не забравяйте, че отдолу е MySQL...
За начало трябва да имате предвид, че Galera е просто плъгин, който работи с MySQL, така че трябва да сте сигурни, че се придържате към правилата и процесите за миграция за вашата конкретна версия на MySQL, която се използва във вашия PXC. Ако работим с PXC 5.7 и искате да надстроите до PXC 8.0, първо трябва да поставите отметка във всички квадратчета в контролния списък за надграждане на MySQL. Част от това разгледахме в нашия блог, описвайки процеса на надграждане между MySQL 5.7 и MySQL 8.0. Това също означава, че само пътищата за надстройка, поддържани от MySQL, са жизнеспособни - например не можете да надстроите PXC 5.6 директно до PXC 8.0, тъй като директното надграждане на MySQL от 5.6 до 8.0 не се поддържа.
Прочетете документацията за надстройка
Както обикновено, когато планирате надстройка, трябва да се запознаете с документацията, изготвена от доставчика. Percona има уеб страница, посветена на обяснението на процеса на надстройка и предупрежденията около него. Ще разгледаме някои от тези точки в тази публикация в блога.
Промени в конфигурацията
Има няколко промени в настройките за конфигурация по подразбиране, които могат да предизвикат проблеми в процеса на надстройка - pxc_strict_mode е настроен на ENFORCING по подразбиране. Този режим блокира всякакъв вид конфигурация, която е експериментална и може да повлияе на стабилността на клъстера. Проверките обхващат, наред с други неща, използвани машини за съхранение, двоичен формат на дневника, наличието на първични ключове и някои други неща. Когато надграждате, може да искате да го зададете на РАЗРЕШЕНО, за да проследявате несъвместимостите в регистъра на грешките, но в противен случай оставете PXC да работи дори ако някои неща не са в най-добрата форма.
Друга настройка, pxc_encrypt_cluster_traffic, също е активирана по подразбиране, като налага криптиране на комуникацията на Galera между възлите. Не е възможно да се смесват възли с криптирани и некриптирани възли в един и същ клъстер, поради което трябва или да го настроите на всички възли, или да се уверите, че деактивирате pxc_encrypt_cluster_traffic на новите, PXC 8.0 възли.
Промяна в приставката за удостоверяване по подразбиране
Споменахме това в нашата публикация в блога относно миграцията към MySQL 8.0, но промяната е толкова важна, че искаме да я повторим и тук - с MySQL 8.0 приставката за удостоверяване по подразбиране се променя на caching_sha2_password - това може направи някои от по-старите приложения несъвместими с MySQL 8.0. Разбира се, можете да промените тази настройка, но ако не я вземете под внимание, тя може да има обратен ефект след завършване на надстройката.
Процеси за надстройка
За начало, моля, имайте предвид, че макар и да не се препоръчва, при някои е възможно да имате и PXC 5.7, и PXC 8.0 възли, работещи в един и същ клъстер. Това отваря възможност за надграждане на място на място. Процесът би бил доста прост - спрете PXC 5.7 възел, надстройте го до PXC 8.0, като инсталирате нова версия и го стартирате. В процесната директория с данни ще бъде надстроена до новата версия и новият PXC 8.0 възел трябва да може да стартира правилно и да се присъедини към клъстера. След това продължавате с възлите един по един, като ги мигрирате от PXC 5.7 към PXC 8.0. Моля, имайте предвид, че трябва да избягвате SST, тъй като директория с данни от PXC 8.0 възел не може да се използва на 5.7. Обратното трябва да работи добре. За да предотвратите възникването на SST, уверете се, че размерът на gcache е достатъчно голям, за да побере записи и позволи на IST да се случи. Самият IST ще работи добре.
Ако имате повече безплатни възли, винаги можете да извършите надстройката с два клъстера на различни основни версии, работещи паралелно и свързани чрез асинхронна репликация. Важното е, че такъв подход ще ви позволи да тествате PXC 8.0 по-задълбочено, тъй като ще го поддържате и работи за известно време (по принцип толкова дълго, колкото ви е необходимо) и можете да тествате приложението си в този клъстер - по всяко време в време можете да преместите част от работното натоварване само за четене към PXC 8.0, за да видите как се обработват заявките, ако има грешки или проблеми с производителността.
Ако използвате ClusterControl, това може да се постигне с помощта на заданието „Създаване на подчинен клъстер“.
Ще бъдете помолени да решите откъде трябва да идват първоначалните данни, господарю PXC възел или от резервното копие.
Ще трябва също да предадете подробностите за свързване като SSH потребител и ключов път .
След това ще бъдете помолени да изберете доставчика и версията - вероятно искате за да използвате PXC 5.7 засега, ще надстроите възлите по-късно, тествайки самия процес на надстройка.
Накрая трябва да предадете имената на хостове или IP адресите на възела за ClusterControl на свържете се и започнете да настройвате възлите.
В резултат на това ще имате втори Percona XtraDB Cluster, работещ във версия 5.7 , репликиращ се от оригиналния клъстер. Този клъстер може да бъде надстроен до новата версия и в крайна сметка можете да превключите трафика си към него. Обяснихме този процес подробно в предишната ни публикация в блога.
Надяваме се, че тази кратка публикация в блога ще ви помогне да се подготвите по-добре за надграждане на вашия Percona XtraDB Cluster до версия 8.0.
