Клъстерите на последователите са функция на ScaleGrid, която ви позволява да поддържате две независими системи за бази данни (от един и същи тип) в синхрон. За разлика от клонирането или репликацията, това ви позволява да поддържате активно копие на производствените си данни в даден момент. Този допълнителен клъстер, известен като последователен клъстер, може да се използва за множество случаи на употреба, включително за анализиране, оптимизиране и тестване на производителността на вашето приложение за MongoDB, MySQL и PostgreSQL. В тази публикация в блога ще разгледаме трите най-добри сценария за използване на клъстери от последователи за вашето приложение.
Как се различават клъстерите от последователи от репликацията?
За разлика от статичен клонинг, тези данни се импортират по зададен график, така че вашият клъстер от последователи винаги е в синхрон с вашия производствен клъстер. Ето няколко критични начина, по които се различава от репликацията:
- Можете да контролирате колко често целевата система се синхронизира от източника – веднъж седмично, веднъж на ден или дори по-рядко. Това помага за намаляване на натоварването на изходната система.
- Тъй като са две независими системи, имате много по-голяма гъвкавост по отношение на данните, които се синхронизират. Можете да имате различни потребителски идентификационни данни и дори да премахнете някои данни от местоназначението въз основа на изискванията за сигурност (забележка:Това изисква скриптове от страна на потребителя – това не е вградена функция на клъстерите от последователи).
- Системата „последовател“ може да се записва, така че можете да я използвате като промеждуваща среда, за да тествате промените в приложението си. Това не е нещо, което можете да направите на възел-реплика.
Забележка:ScaleGrid прилага клъстери от последователи, използвайки моментни снимки за съхранение. Не е налично за нашите предложения за база данни в паметта, като хостинг за Redis™*.
1. Настройка за разработка/тест на база данни
Всички сме били там – предполагаемо добре тестван код се внедрява в производството и след това целият ад избухва. Производствените работни потоци се провалят или са толкова бавни, че по принцип са неизползваеми. Инженерите са събудени от леглата си, за да започнат пълна операция по гасене на пожар. Няколко безсънни нощи по-късно се появява тази страшна основна причина.
Приложението се държи различно при производствени и инженерни настройки.
С други думи, тествахме го върху „тестови данни“. Което, както се оказва, не прилича на производствените данни. Изобщо.
Очевидният начин да избегнете тази ситуация е да стартирате тестове на вашите производствени данни. Разбира се, не реално производство - това ще бъде флирт с бедствие. На клонирано копие на производствените данни. Въпреки че опасенията относно поверителността и сигурността на данните правят това неосъществимо в много сценарии, ако изискванията за поверителност позволяват, това е най-доброто решение. Вече не е необходимо да разчитаме на инженери, които генерират подходящи набори от данни – ако предават тестови данни, ще предават производствени данни.
Тоест, докато тестовите данни не изпаднат толкова далеч от синхрон с производството, че вече не са добро приближение. И ние се завръщаме на първо място.
Тук идват клъстерите от последователи.
Като използвате клъстери от последователи, можете периодично да импортирате данни от вашата производствена база данни в базата данни dev/test. И тъй като целият импорт се извършва с помощта на моментни снимки за съхранение, а не чрез логическо изхвърляне, процесът е почти мигновен. Можете да планирате импортирането си веднъж на всеки 24 часа, веднъж седмично или каквато честота отговаря на конкретния ви сценарий.
С клъстерите ви за разработка и QA, настроени да следват производствения клъстер, можете да сте спокойни. Ако приложението ви предава тестовия набор от данни, определено е подходящо за внедряване в производството!
2. Анализ на данни
Ако сте работили като администратор на база данни, вероятно сте водили разговор с екипа си за „мистериозно“ забавяне на производителността на системата в определени моменти. В повечето случаи виновникът се оказва аналитична работа, която има достъп до тонове данни и в крайна сметка забавя цялата система.
Като доставчик на DBaaS сме водили този разговор няколко пъти с нашите клиенти. Ето двете опции, които обикновено предлагаме:
- Ако заданието за анализ се изпълнява на основния/главния сървър, преместете го на вторичен/реплика сървър.
- Ако заданието за анализ вече се изпълнява на вторичен възел и влошаването на производителността е неприемливо, препоръчваме да преместите заданията в специален клъстер за анализ.
С помощта на нашата функция за клъстер от последователи е много лесно да поддържате клъстер за анализ актуален с действителните производствени данни. Можете да създадете график за последователи, за да синхронизирате най-новите данни от производството точно преди да започне работата ви по анализ.
Най-добрата част? Синхронизирането на последователя не извършва никакви операции на ниво база данни – просто възстановява най-новата моментна снимка! Така че няма никакво въздействие върху вашия производствен клъстер.
3. Отчитане
Друг често срещан случай на използване, при който нашите клиенти използват функцията за последователни клъстери, е за генериране на отчети. Процесите на отчитане обикновено се изпълняват рядко, но имат достъп до големи количества данни и заемат по-голямата част от ресурсите на клъстера от база данни. Когато влошаването на производителността е неприемливо, препоръчваме на нашите клиенти да преместят работното натоварване за отчитане в нов клъстер.
Тъй като операциите за отчитане са редки, много от нашите клиенти предпочитат да използват нашата функция за пауза/възобновяване, за да „поставят на пауза“ клъстери за отчитане, когато не се използват. Това помага да се спестят значително от разходи за инфраструктура. Обикновено клъстерите за отчитане също са много „по-малки“ (по-малко CPU/RAM), за да помогнат за намаляване на разходите.
След като създадете клъстер от последователи от нашия потребителски интерфейс, можете да използвате този работен процес, за да автоматизирате своя поток на отчитане:
- Използвайте нашия API за възобновяване, за да възобновите клъстера.
- Изчакайте, докато клъстерът се върне в работно състояние (за тази цел можете да използвате вашия API за get-status).
- Задействайте резервно копие на производствения си клъстер, ако е необходимо (обикновено, ако редовното архивиране е насрочено за вашата продукция, можете да пропуснете тази стъпка. Ако обаче искате отчетите ви да се изпълняват с най-новите данни, това е от съществено значение).
- Изчакайте архивирането да завърши.
- Задействайте задание за синхронизиране на последователя – това намира най-новата моментна снимка на изходния клъстер и се възстановява до местоназначението.
- Изчакайте задачата за синхронизиране да завърши.
- Изпълнете задачите си за отчитане.
- Използвайте нашия API за пауза, за да поставите на пауза клъстера до следващата си задача за отчитане!
Мислите ли, че клъстерите от последователи са подходящи за вашия конкретен потребителски случай? Можете да научите всичко за това как да внедрите и управлявате клъстери от последователи за MongoDB, MySQL и PostgreSQL в нашите помощни документи!
Ако не сте сигурни дали клъстерите от последователи са правилното решение за вашия случай на употреба, оставете коментар или се свържете с нас на [email protected] – ние с удоволствие ще обсъдим коя функция най-добре отговаря на вашите изисквания.
