Основните цели на настройката с множество центрове за данни (или мулти-DC) - независимо дали екосистемата на базата данни е SQL (PostgreSQL, MySQL) или NoSQL (MongoDB, Cassandra), за да назовем само няколко - са ниска латентност за крайните потребители, Висока наличност и аварийно възстановяване. В основата на такава среда лежи способността за репликиране на данни по начини, които гарантират тяхната издръжливост (като странична бележка, параметрите на конфигурацията за издръжливост на Cassandra са подобни на тези, използвани от PostgreSQL). Различните изисквания за репликация ще бъдат обсъдени по-долу, но крайните случаи ще бъдат оставени на любопитните за по-нататъшно изследване.
Репликацията с помощта на асинхронна доставка на регистрационни файлове е налична в PostgreSQL от дълго време, а синхронната репликация, въведена във версия 9.1, отвори изцяло нов набор от опции за разработчиците на инструменти за управление на PostgreSQL.
Неща, които трябва да имате предвид
Един от начините за разбиране на сложността на внедряването на PostgreSQL с множество DC е чрез учене от решенията, внедрени за други системи за бази данни, като същевременно се има предвид, че PostgreSQL настоява да бъде съвместим с ACID.
Настройката с няколко DC включва в повечето случаи поне един център за данни в облака. Докато доставчиците на облак поемат тежестта на управлението на репликацията на базата данни от името на своите клиенти, те обикновено не отговарят на функциите, налични в специализираните инструменти за управление. Например с много предприятия, които приемат хибридни облачни и/или мултиоблачни решения, в допълнение към съществуващата им инфраструктура, мулти-DC инструмент трябва да може да се справи с такава смесена среда.
Освен това, за да се сведе до минимум времето за престой по време на отказ, системата за управление на PostgreSQL трябва да може да поиска (чрез повикване на API) актуализация на DNS, така че заявките за база данни да се насочват към новия главен клъстер.
Мрежите, обхващащи големи географски области, са връзки с висока латентност и всички решения трябва да бъдат компромиси:забравете за синхронната репликация и използвайте една основна с много реплики за четене. Вижте проучванията на AWS MongoDB и Severalnines/Galera Cluster за задълбочен анализ на мрежовите ефекти върху репликацията. От друга страна, чудесен инструмент за тестване на латентността между местоположенията е Wonder Network Ping Statistics.
Въпреки че естеството на високата латентност на WAN не може да бъде променено, потребителското изживяване може да бъде драстично подобрено, като се гарантира, че четенията се обслужват от реплика за четене близо до местоположението на потребителя, но с някои предупреждения. Чрез преместване на репликите далеч от първичното, записите се забавят и по този начин трябва да премахнем синхронната репликация. Решението трябва също да може да заобикаля други проблеми, като последователност на четене след запис и застояли вторични четения поради загуба на връзка.
За да се сведе до минимум RTO, данните трябва да бъдат репликирани в трайно съхранение, което също е в състояние да осигури висока производителност на четене, а според Citus Data една опция, която отговаря на тези изисквания, е AWS S3.
Самата идея за множество центрове за данни предполага, че системата за управление на базата данни трябва да може да представи на DBA глобален изглед на всички центрове за данни и различните PostgreSQL клъстери в тях, да управлява множество версии на PostgreSQL и да конфигурира репликацията между тях.
Когато се репликират записи към регионални центрове за данни, трябва да се следи забавянето на разпространението. Ако закъснението надхвърли праг, трябва да се задейства аларма, показваща, че репликата съдържа остарели данни. Същият принцип важи и за асинхронната многоглавна репликация.
При синхронна настройка голямото забавяне или прекъсванията на мрежата могат да доведат до забавяне на обслужването на клиентски заявки, докато се чака завършването на ангажимента, докато при асинхронни конфигурации съществуват рискове от разделяне на мозъка или влошаване на производителността за продължителен период от време. Разделянето на мозъка и закъсненията при синхронни комитации са неизбежни дори при добре установени решения за репликация, както е обяснено в статията Гео-разпределени клъстери от бази данни с Galera.
Друго съображение е поддръжката на доставчици — към момента на писане AWS не поддържа реплики на PostgreSQL между региони.
Интелигентните системи за управление трябва да наблюдават латентността на мрежата между центровете за данни и да препоръчват или коригират промени, напр. синхронната репликация е идеална между зоните за достъпност на AWS, където центровете за данни са свързани чрез оптични мрежи. По този начин едно решение може да постигне нулева загуба на данни и също така може да приложи репликация главен-главен заедно с балансиране на натоварването. Имайте предвид, че AWS Aurora PostgreSQL в момента не предоставя опция за репликация главен-главен.
Решете нивото на репликация:клъстер, база данни, таблица. Критериите за решение трябва да включват разходи за честотна лента.
Внедрете каскадна репликация, за да заобиколите прекъсвания на мрежата, които могат да попречат на репликите да получават актуализации от главен източник поради географско разстояние.
Решения
Като се вземат предвид всички изисквания, се идентифицират продуктите, които са най-подходящи за работата. Внимание обаче:всяко решение идва със свои собствени предупреждения, с които трябва да се справите, като следвате препоръките в документацията на продукта. Вижте например изискването за наблюдение на BDR.
Официалната документация на PostgreSQL съдържа списък с некомерсиални приложения с отворен код, а разширен списък, включващ търговски решения със затворен код, може да бъде намерен на wiki страницата за репликация, клъстериране и пулиране на връзки. Някои от тези инструменти са разгледани по-подробно в статията Top PG Clustering HA Solutions за PostgreSQL.
Няма решение до ключ, но някои продукти могат да предоставят повечето от функциите, особено при работа с доставчика.
Ето един неизчерпателен списък:
- Citus Data предоставят собствена версия на PostgreSQL, подобрена с впечатляващи корпоративни функции и дълбока интеграция с AWS.
- EnterpriseDB предлага голям набор от услуги, които могат да се комбинират, за да отговорят на повечето изисквания. Повечето информация е в документацията на продукта.
- Postgres-BDR е мощен инструмент за репликация, създаден специално за географски разпределени клъстери, но не се интегрира с нито един доставчик на облак.
- ClusterControl идва с впечатляващ набор от функции - за управление на PostgreSQL. Освен това има ограничена интеграция в облак.
- ElephantSQL работи в много облачни доставчици. Въпреки това, няма опция за локална настройка.
- Crunchy PostgreSQL за Kubernetes е продукт, независим от облака, изграден върху PostgreSQL нагоре по веригата.
Заключение
Както видяхме, когато става въпрос за избор на PostgreSQL решение с множество центрове за данни, няма универсално решение за всички. Често компромисът е задължителен. Въпреки това, доброто разбиране на изискванията и последиците може да помогне за вземането на информирано решение.
В сравнение със статичните (само за четене) данни, решението за бази данни трябва да вземе предвид репликацията на актуализации (записвания). Литературата, описваща решенията за репликация на SQL и NoSQL, настоява за използване на единен източник на истина за запис с много реплики, за да се избегнат проблеми като разделяне на мозъка и последователност при четене след запис.
И накрая, оперативната съвместимост е ключово изискване, като се има предвид, че настройките с няколко DC могат да обхващат центрове за данни, разположени на място, и различни доставчици на облак.
