По-често, отколкото не, репликите се разполагат за висока наличност и/или мащабиране на четене. Ако първичният се провали, една от репликите се повишава до основна. Ако има много четения и това е почти винаги така, се добавят реплики за мащабиране. В идеалния случай записите се насочват към основния и четенията са балансирани на натоварването в репликите. Това е най-ефективният начин за използване на наличните ресурси.
RDS, Azure Database и Cloud SQL ви предоставят индивидуални крайни точки за екземпляри на база данни, една за основната и една за всяка реплика. Ако искате да четете баланса на натоварването, трябва да създадете множество връзки (по една за всяка реплика) и да го направите сами. Ако искате да изпълните записи на първичния и четене на репликите (т.е. разделяне на четене/запис), трябва да създадете допълнителна връзка към основния и да го направите сами.
Не е смешно. Не е готино.
С MaxScale, усъвършенствано прокси сървър на база данни за MariaDB Enterprise Server, не е нужно да се притеснявате за това. MaxScale извършва балансиране на натоварването при четене и разделяне на четене/запис вместо вас – това е, което наричаме прозрачно маршрутизиране на заявки. Разработчиците не трябва да се притесняват за физическата инфраструктура (т.е. топологията на базата данни). Защо трябва? Може би има една реплика, може би са пет. Може би DBA са добавили реплика снощи, може би са премахнали две. Това не трябва да има значение и приложенията не трябва да го отчитат.
Това е страхотното нещо на MaxScale. Той абстрахира основната инфраструктура на базата данни и топологията на разполагане. Може би това е самостоятелна база данни. Може би това е репликирана база данни. Може би това е клъстерирана база данни. На кого му пука? Особено в облака.
И така, защо можете да се възползвате от прозрачното маршрутизиране на заявки на място, но не и в облака? Тъй като RDS, Azure Database и Google Cloud SQL нямат MaxScale. Само ако имаше DBaaS с MaxScale и прозрачно маршрутизиране на заявки. Само ако можехме да се издигнем по-високо с най-добрия облак MariaDB. Чакай, здравей SkySQL!
Да, донесохме силата на MaxScale в SkySQL.
След като създадете репликирана база данни, получавате име на хост и два порта, един за четене и един за четене/запис. Нуждаете се само от порта за четене/запис, тъй като той също прави балансиране на натоварването за четене. Но ако имате приложения само за четене (например BI/отчитане), портът за четене може да ви бъде полезен. Лесно.
Може би се питате дали Шейн току-що сподели името на хоста и порта на своята база данни?
Защо да, да, направих го. По подразбиране SkySQL бази данни не са достъпни. Трябва да поставите в белия списък IP адресите (или диапазоните) на всички клиенти и сървъри на приложения, които изискват достъп. И единственият IP адрес, който поставих в белия списък, е този за моя лаптоп у дома. Късмет. 😉
Обратно към разглежданата тема, ще видите двата порта:5001 за разделяне на четене/запис (записва към основното, четене балансирано между реплики) и 5002 за балансиране на натоварването само за четене. Моята база данни има две реплики, но приложенията, които се свързват с нея, не трябва да се притесняват за това. Мога да добавя още две реплики утре и няма да са необходими промени в приложението, за да се възползвам от тях. MaxScale просто и автоматично ще започне да насочва четенията към тях.
И ако първичният се провали, нищо страшно. MaxScale автоматично ще популяризира реплика и ще започне да насочва записите към нея (и четенията за балансиране на натоварването в останалите реплики). Ако някога сте страдали от непредсказуемото време на отказ на RDS, знаете защо. RDS отказът се базира на разпространението на DNS, така че не е нужно да променяте името на хоста на крайната точка. Почти е прозрачен, но отнема време. С MaxScale, от друга страна, това е незабавно – не се изисква DNS разпространение.
Но не искам да се отклонявам твърде далеч от темата. Имам предвид нещо друго, планирано за HA. Останете на линия.
