Рекомендации по использованию
In this article:
Рекомендации по использованию#
В этом разделе приводятся рекомендации по использованию сервисов баз данных в К2 Облаке.
MySQL#
Варианты запуска сервиса#
Одиночный экземпляр СУБД, развёрнутый на виртуальной машине в одной зоне доступности.
Отказоустойчивая СУБД, развёрнутая в кластере из трёх виртуальных машин в одной или (при наличии в регионе) трёх зонах доступности. Кластер может содержать:
Три полнофункциональных узла. Данные распределяются по трём самостоятельным копиям, с каждой из которой можно работать независимо.
Два полнофункциональных узла + кластерный арбитр. Этот вариант более экономичен с точки зрения количества задействованных ресурсов. Только два узла СУБД являются рабочими, а третий узел используется для поддержания кластерного кворума. Экземпляр с кластерным арбитром запускается с минимальным набором ресурсов: 2 vCPU, 4 ГиБ RAM, 16 ГиБ дискового пространства.
Архитектура отказоустойчивого решения#
Для кластеризации MySQL мы используем Galera. Все узлы такого кластера активны одновременно и позволяют выполнять любые операции на чтение и запись. Однако используемое приложение должно уметь работать с конфигурацией СУБД с несколькими мастерами. Несогласованные (нетранзакционные) действия со стороны множества экземпляров приложения по отношения к конфигурации СУБД с несколькими мастерами могут приводить, например, к увеличению числа блокировок (deadlock).
Если вы не уверены, что ваше приложение будет корректно работать на чтение и запись со всеми узлами одновременно, лучше использовать следующие сценарии:
Работать единовременно только с одним узлом кластера СУБД, а на остальных узлах хранить копию данных, чтобы они могли принять на себя нагрузку в случае отказа первого узла.
Производить запись только на один узел кластера СУБД, тогда как остальные узлы использовать только на чтение данных.
Для реализации описанных сценариев удобно использовать ProxySQL. Этот инструмент принимает запросы от приложения и перенаправляет к узлам СУБД. При этом он может по заданным правилам распределять операции по конкретным узлам, а также кешировать ответы СУБД, модифицировать запросы и т.д. ProxySQL автоматически детектирует выход из строя узлов кластера СУБД и мгновенно переключается на использование работающих узлов.
Подробнее о возможностях ProxySQL и его настройке читайте в официальной документации ProxySQL и в wiki проекта. Для добавления сервера СУБД в ваш ProxySQL в качестве бэкенда воспользуйтесь инструкцией.
Распределение запросов с помощью HAProxy#
Для простоты и удобства использования отказоустойчивого сервиса MySQL мы встроили в него инсталляцию HAProxy, которая отслеживает статус и роли узлов и автоматически распределяет запросы. Запросы направляются либо на первый узел кластера, либо на следующий работоспособный узел, если первый узел стал недоступен.
Сервис HAProxy работает на каждом из узлов кластера на порту tcp/5000.
Таким образом, вы можете просто отправить запрос на этот порт на любом из узлов — механизм HAProxy направит его на верный узел.
Чтобы максимально использовать преимущества отказоустойчивого сервиса, необходимо при подключении к MySQL задействовать порты HAProxy всех узлов. Удобнее всего для этого настроить ещё один сервис балансировки на стороне вашего приложения. Вы можете использовать облачный балансировщик нагрузки или развернуть свой собственный.
Подключиться к СУБД#
После успешного запуска адреса и порты, которые прослушивает СУБД, можно найти на странице базы данных MySQL.
Экземпляры MySQL прослушивают порт tcp/3306.
Используйте этот порт для подключения и дальнейшей работы с СУБД.
Важно
Кластер позволяет сохранить доступность базы данных при отказе одного из узлов, но только если вы используете не одну, а все точки приёма запросов кластера (endpoints).
СУБД можно управлять как через стандартный консольный клиент mysql в Linux, так и с помощью графических инструментов, таких как dbForge Studio, MySQL Workbench, phpMyAdmin и т.д.
Если вы хотите подключаться к сервису MySQL удалённо, не забудьте назначить Elastic IP экземпляру с развёрнутым сервисом и разрешить подключения к порту tcp/3306 в соответствующей группе безопасности.
Важно
Будьте осторожны, открывая доступ к MySQL из интернета. Рекомендуем ограничить доступ конкретными IP-адресами, а также использовать сложные пароли.
PostgreSQL#
Варианты запуска сервиса#
Одиночный экземпляр СУБД, развёрнутый на виртуальной машине в одной зоне доступности.
Отказоустойчивая СУБД, развёрнутая в кластере из трёх или шести виртуальных машин в одной или (при наличии в регионе) трёх зонах доступности. Кластер может содержать:
Три полнофункциональных узла. Данные распределяются по трём самостоятельным копиям, с каждой из которой можно работать независимо.
Два полнофункциональных узла + кластерный арбитр. Этот вариант более экономичен с точки зрения количества задействованных ресурсов. Только два узла СУБД являются рабочими, а третий узел используется для поддержания кластерного кворума. Экземпляр с кластерным арбитром запускается с минимальным набором ресурсов: 2 vCPU, 4 ГиБ RAM, 16 ГиБ дискового пространства.
Шесть полнофункциональных узлов. Данные распределяются по шести самостоятельным копиям, с каждой из которой можно работать независимо.
Архитектура отказоустойчивого решения#
Существует много способов настроить и управлять репликацией в PostgreSQL. Для организации отказоустойчивого кластера PostgreSQL в К2 Облаке используется Patroni. Этот инструмент автоматически отслеживает состояние узлов, управляет репликацией и переключает её в случае отказа одного из узлов кластера.
В каждый момент времени только один узел кластера может быть мастером, остальные являются репликами. На мастере можно производить операции чтения и записи, на репликах — только чтение.
Узнать роль конкретного узла можно с помощью запроса к Patroni RestAPI, который доступен на каждом узле на сервисном порту tcp/8008.
С подробной инструкцией можно ознакомиться здесь.
Для простоты и удобства использования отказоустойчивого сервиса PostgreSQL мы встроили в него инсталляцию HAProxy, которая отслеживает роли узлов и автоматически направляет запросы на мастер.
HAProxy работает на всех узлах кластера (кроме арбитра) на порту tcp/5000.
Таким образом, к этому порту можно обратиться с любого узла и механизм HAProxy направит запрос на мастер.
Чтобы максимально использовать преимущества отказоустойчивого сервиса, необходимо при подключении к PostgreSQL задействовать порты HAProxy всех узлов. Удобнее всего для этого настроить ещё один сервис балансировки на стороне вашего приложения. Вы можете использовать облачный балансировщик нагрузки или развернуть свой собственный.
Схематично архитектура решения изображена ниже.
Подключиться к СУБД#
После успешного запуска адреса и порты, которые прослушивает СУБД, можно найти на странице базы данных PostgreSQL.
Экземпляры PostgreSQL прослушивают порт tcp/5432.
Patroni Rest API доступен на этих же узлах на порту tcp/8008.
Используйте эти порты для подключения и дальнейшей работы с СУБД.
Важно
Кластер позволяет сохранить доступность базы данных при отказе одного из узлов, но только если вы используете не одну, а все точки приёма запросов кластера.
СУБД можно управлять как через стандартный консольный клиент psql в Linux, так и с помощью графических инструментов, например, pgAdmin.
Если вы хотите подключаться к сервису PostgreSQL удалённо, не забудьте назначить Elastic IP экземпляру с развёрнутым сервисом и разрешить подключение к порту tcp/5432 в соответствующей группе безопасности.
Важно
Будьте осторожны, открывая доступ к PostgreSQL из интернета. Рекомендуем ограничить доступ конкретными IP-адресами, а также использовать сложные пароли.
Логическая репликация для PostgreSQL#
Репликация между базами данных PostgreSQL позволяет автоматически передавать изменения данных между разными экземплярами.
Основные сценарии использования репликации:
построение отказоустойчивых решений;
создание резервной площадки хранения;
миграция между кластерами;
миграция между версиями СУБД PostgreSQL.
Логическая репликация позволяет:
реплицировать как отдельные базы данных, так и отдельные таблицы;
выбирать реплицируемые операции;
выполнять репликацию между разными версиями PostgreSQL.
Подробное описание логической репликации можно найти в документации PostgreSQL.
Основные понятия#
Для описания логической репликации PostgreSQL использует следующие понятия:
Публикация (publication) — определяет, какие именно данные публикуются.
Подписка (subscription) — определяет целевую базу данных, которая получает изменения из публикации.
Настройка репликации#
Репликация настраивается в два этапа — на источнике (исходная база данных, которую необходимо реплицировать) и реплике (целевая база данных, которая будет являться репликой исходной).
Настроить источник#
Примечание
В инструкции предполагается, что база данных, для которой требуется настроить репликацию, уже создана. Если база данных ещё не создана, следует сначала создать её.
Создайте отдельного пользователя базы данных. При создании пользователя отметьте возле поля Разрешить репликацию для предоставления пользователю прав на репликацию данных.
Создайте публикацию в исходной базе данных, выполнив SQL-запрос:
CREATE PUBLICATION <publication_name> FOR TABLE <table_name>;
где:
<publication_name>— имя публикации;<table_name>— имя таблицы.
Создайте дамп реплицируемой базы данных с помощью утилиты
pg_dump:pg_dump \ "host=<host> \ port=<port> \ dbname=<database_name> \ user=<user_name>" \ --schema-only \ --no-privileges \ --no-subscriptions \ --no-publications \ -Fd -f <dump_directory>
где:
<host>— IP-адрес или DNS-имя кластера, в котором находится источник;<port>— порт;<database_name>— имя исходной базы данных;<user_name>— имя пользователя-владельца базы данных;<dump_directory>— каталог, содержащий дамп.
Параметры:
--schema-only— сохранять только структуру (таблицы, индексы, представления), но не копировать сами данные;--no-privileges— не сохранять права доступа (GRANT/REVOKE);--no-subscriptionsи--no-publications— не сохранять настройки логической репликации;-Fd— формат дампа — Directory (директория, или каталог);-f <dump_directory>— путь к этому каталогу.
Настроить реплику#
Создайте базу данных PostgreSQL, которая будет являться репликой для исходной.
Восстановите схему данных из дампа в принимающей базе данных с помощью утилиты
pg_restore:pg_restore \ -Fd -v \ --single-transaction -s \ --no-privileges -O \ -h <host> \ -U <user_name> \ -p <port> \ -d <database_name> \ <dump_directory>
где:
<host>— IP-адрес или DNS-имя кластера, в котором находится принимающая база данных;<user_name>— имя пользователя-владельца базы данных;<port>— порт;<database_name>— имя созданной при настройке источника базы данных;<dump_directory>— каталог, содержащий дамп.
Параметры:
-Fd (directory format)— указывает, что исходный дамп был создан в формате каталога;-v(Verbose) — подробный режим;--single-transaction— весь процесс восстановления производится за одну транзакцию;-s(Schema only) — восстановить только схему (структуру);--no-privileges— не восстанавливать права доступа (GRANT/REVOKE);-O(No Owner) — не восстанавливать информацию о владельце объектов.
Создайте подписку в реплике, выполнив SQL-запрос:
CREATE SUBSCRIPTION <subscription_name> CONNECTION host=<host> port=<port> dbname=<database_name> user=<user_name> password=<password> PUBLICATION <publication_name>;
где:
<subscription_name>— имя подписки;<publication_name>— имя публикации;<host>— IP-адрес или DNS-имя кластера, в котором находится принимающая база данных;<port>— порт;<database_name>— имя исходной базы данных;<user_name>— имя пользователя исходной базы данных;<password>— пароль пользователя.
При создании подписки PostgreSQL по умолчанию использует параметр copy_data = true, который инициирует начальную синхронизацию: все существующие данные из опубликованных таблиц автоматически копируются в принимающую базу данных.
После завершения этого этапа активируется потоковая репликация, а любые новые изменения, вносимые в исходную базу данных, будут передаваться на принимающую сторону в реальном времени.
Важно
Рекомендуется не вносить изменения в данные на стороне принимающей базы данных, чтобы избежать конфликтов при репликации. Несоблюдение этой рекомендации может привести к рассинхронизации данных между узлами.
Отключить репликацию#
Для отключения репликации выполните следующие действия:
Отключите подписку на реплике, выполнив SQL-запрос:
DROP SUBSCRIPTION <subscription_name>;
Удалите подписку на источнике, выполнив SQL-запрос:
SELECT pg_drop_replication_slot('<subscription_name>');
где:
<subscription_name>— имя подписки;
Ограничения логической репликации#
Изменения структуры баз данных (DDL-операции, такие как ALTER TABLE, CREATE INDEX и др.) автоматически не реплицируются.
Таблицы, индексы, ограничения и другие объекты схемы базы данных необходимо создавать/изменять отдельно в исходной и принимающей базах данных.
При этом схемы таблиц должны оставаться полностью совместимыми.
Последовательности (SEQUENCE) автоматически не реплицируются.
При переключении приложения на реплику значения последовательностей необходимо синхронизировать отдельно, иначе возможны ошибки уникальности при выполнении новых запросов INSERT.
Для корректной репликации операций UPDATE и DELETE таблицы должны иметь определённый идентификатор репликации (Replica Identity).
Он необходим для того, чтобы в принимающей базе данных можно было однозначно найти строку, которую требуется обновить или удалить.
По умолчанию в качестве идентификатора используется первичный ключ таблицы (PRIMARY KEY).
Если в таблице отсутствует первичный ключ, необходимо настроить идентификатор репликации вручную, например, используя уникальный индекс или установив значение FULL, чтобы реплицировались все столбцы строки.
Логическая репликация ограничена отдельной базой данных. Публикация создаётся в рамках конкретной базы данных и не может охватывать все базы данных в составе одного сервиса PostgreSQL.
Добавление таблицы в публикацию не приводит к её созданию на реплике. В этом случае следует сначала:
Создать совместимую таблицу в принимающей базе данных.
Обновить подписку, например, с использованием SQL-запросов
ALTER SUBSCRIPTION…REFRESH PUBLICATION.
Рекомендуется контролировать доступность принимающей базы данных. Недоступность может привести к накоплению журналов предзаписи (Write-Ahead Logs, WAL) и последующему исчерпанию дискового пространства.
Логическая репликация не способна полностью заменить физическую репликацию, если рабочим процессам требуется высокая доступность (High Availability, HA) и возможность аварийного восстановления (Disaster Recovery, DR). Для реализации отказоустойчивых сервисов с минимальным временем восстановления рекомендуется использовать физическую репликацию. Логическая репликация не обеспечивает идентичную копию всего экземпляра PostgreSQL.
Redis#
Варианты запуска сервиса#
Одиночный экземпляр СУБД, развёрнутый на одной виртуальной машине в одной зоне доступности.
Отказоустойчивая СУБД, развёрнутая в кластере из трёх или шести виртуальных машин в одной или (при наличии в регионе) трёх зонах доступности.
Архитектура отказоустойчивого решения#
Для Redis доступны два варианта отказоустойчивой архитектуры — с использованием мониторингового сервиса Sentinel и, начиная с версии Redis 3.0, со встроенной кластеризацией (native clustering в терминологии Redis). Первый позволяет реализовать высокую доступность для небольших инсталляций. Второй обеспечивает лучшую масштабируемость и производительность для крупных инсталляций.
Redis Sentinel#
В К2 Облаке реализована конфигурация с Sentinel из трёх узлов, на одном из которых работает мастер, а на двух других — реплики (для кластера с шестью узлами данный вариант кластеризации не поддерживается). На каждом узле помимо сервера Redis запущен также процесс Redis Sentinel. При сбоях и других неполадках сервис Sentinel запускает процедуру автоматического переключения (failover). Подробнее о функциональности Sentinel можно прочитать в официальной документации.
Процессы Sentinel взаимодействуют друг с другом и следят за работоспособностью узлов Redis. При сбое узла, сервера Redis или сервиса Sentinel доступные процессы Sentinel устраивают перевыборы, чтобы определить, какому из узлов будет назначена роль мастера. Далее запускается процедура автоматического переключения: выбранная реплика становится новым мастером, оставшаяся реплика переконфигурируется для работы с этим мастером, а приложения, использующие сервер Redis, информируются о новом адресе для подключения.
Примечание
Redis использует асинхронную репликацию, поэтому такая распределённая система из узлов Redis и процессов Sentinel не гарантирует, что подтверждённые операции записи будут действительно сохранены при сбое.
Отказоустойчивый сервис Redis#
Отказоустойчивый сервис Redis развёртывается в кластере из трёх (или шести) экземпляров виртуальных машин, и на каждом узле работают по одному мастеру и реплике, причём реплика взаимодействует с мастером на другом узле (кросс-репликация).
Высокая производительность и линейная масштабируемость кластера обеспечивается благодаря нескольким мастер-узлам, а высокая доступность — наличием как минимум одной реплики для каждого мастера. С подробной информацией можно ознакомиться в официальной документации Redis.
Все мастер-узлы делят между собой единое пространство для данных, которое разделено на слоты. Таким образом, каждый мастер содержит часть слотов (sharding).
При работе с отказоустойчивым сервисом Redis обращения обрабатываются мастерами. Для операций чтения и записи можно обращаться к любому мастеру. Если при чтении искомые данные находятся в слоте на другом мастере, то Redis сам перенаправит клиента к нужному экземпляру.
В случае сбоя мастер-экземпляра или всего узла, на котором работает экземпляр, происходит автоматическое переключение (failover) на соответствующую реплику, которая берёт на себя роль мастера.
Распределение запросов с помощью HAProxy#
Для простоты и удобства использования отказоустойчивого сервиса Redis мы встроили в него инсталляцию HAProxy, которая отслеживает статус и роли узлов и автоматически распределяет запросы только на экземпляры виртуальных машин в роли мастера.
HAProxy работает на всех узлах кластера на порту tcp/5000.
Таким образом, к этому порту можно обратиться с любого узла и механизм HAProxy направит запрос на один из мастеров.
Чтобы максимально использовать преимущества отказоустойчивого сервиса, необходимо при подключении к Redis задействовать порты HAProxy всех узлов. Удобнее всего для этого настроить ещё один сервис балансировки на стороне вашего приложения. Вы можете использовать облачный балансировщик нагрузки или развернуть свой собственный.
Архитектура решения с HAProxy для отказоустойчивого сервиса Redis#
Подключиться к СУБД#
После успешного запуска адреса и порты, которые прослушивает СУБД, можно найти на странице базы данных Redis. В случае одиночного сервиса для подключения доступна всего одна точка приёма запросов (endpoint), в случае же отказоустойчивого сервиса их несколько (точное количество зависит от выбранной архитектуры).
Мастер-экземпляры Redis прослушивают порт tcp/6379, реплики — tcp/6380.
При сбое мастер-экземпляра или всего узла, на котором работает экземпляр, происходит автоматическое переключение: реплика становится мастером, но продолжает работать на порту tcp/6380.
Поэтому одного номера порта недостаточно, чтобы понять, является ли экземпляр мастером или репликой в работающем продолжительное время кластере.
Важно
Кластер позволяет сохранить доступность базы данных при отказе одного из узлов, но только если вы используете не одну, а все точки приёма запросов кластера (endpoints).
Аутентификация в Redis#
При работе в закрытых контурах нет необходимости включать аутентификацию в Redis, но в недоверенной среде может потребоваться защитить вашу инсталляцию паролем.
Пароль можно задать при создании сервиса БД.
После того как сервис был запущен с заданным паролем, обратиться к нему можно после аутентификации (команда AUTH).
Вы можете управлять развёрнутым сервисом Redis как через стандартный консольный клиент redis-cli в Linux, так и использовать для этого графические инструменты. Хороший обзор графических инструментов можно найти в блоге.
Если вы хотите подключаться к сервису Redis удалённо, не забудьте назначить Elastic IP экземпляру с развёрнутым сервисом и разрешить подключение к портам tcp/6379-6380 в соответствующей группе безопасности.
Важно
Будьте осторожны, открывая доступ к Redis из интернета. Рекомендуем ограничить доступ конкретными IP-адресами, а также использовать сложные пароли.
MongoDB#
Варианты запуска сервиса#
Одиночный экземпляр СУБД, развёрнутый на одной виртуальной машине в одной зоне доступности.
Отказоустойчивая СУБД, развёрнутая в кластере из трёх виртуальных машин в одной или (при наличии в регионе) трёх зонах доступности. Кластер может содержать:
Три полнофункциональных узла. Данные распределяются по трём самостоятельным копиям, с каждой из которой можно работать независимо.
Два полнофункциональных узла + кластерный арбитр. Этот вариант более экономичен с точки зрения количества задействованных ресурсов. Только два узла СУБД (primary и secondary) являются рабочими, а третий узел (arbiter) используется для поддержания кластерного кворума. Экземпляр с кластерным арбитром запускается с минимальным набором ресурсов: 2 vCPU, 4 ГиБ RAM, 16 ГиБ дискового пространства.
Архитектура отказоустойчивого решения#
Отказоустойчивый сервис MongoDB в облаке представляет собой набор реплик (Replica Set) — группу экземпляров MongoDB, которые поддерживают один и тот же набор данных путём репликации.
В наборе реплик существуют несколько ролей:
первичный узел (primary) — производит операции чтения и записи;
вторичный узел (secondary) — выполняет только чтение;
арбитр — не реплицирует данные и не участвует в пользовательских операциях.
Репликация данных является асинхронной: первичный узел выполняет все операции записи, после чего вторичный — считывает описание этих операций и асинхронно применяет их у себя.
Если первичный узел становится недоступным, например, в случае аварии, то оставшиеся узлы кластера используют правило кворума и определяют, кто примет на себя его роль. После возвращения недоступного узла в работу он становится вторичным и копирует себе актуальный набор данных с нового первичного узла. Таким образом, роль первичного узла может перемещаться между узлами в процессе жизни кластера.
Подробнее про организацию работы набора реплик можно почитать в официальной документации MongoDB.
Распределение запросов с помощью HAProxy#
Для повышения удобства работы с отказоустойчивым сервисом MongoDB в него интегрирован HAProxy. Этот компонент отслеживает роли узлов и направляет трафик на актуальный первичный узел кластера. В случае смены роли или недоступности первичного узла кластера, HAProxy автоматически перенаправит запросы на новый первичный узел.
Сервис HAProxy работает на всех узлах кластера (кроме арбитра) на порту tcp/5000.
Это позволяет отправлять запросы на любой узел — механизм HAProxy автоматически выберет корректную конечную точку.
Чтобы использовать все преимущества отказоустойчивого сервиса, при подключении к MongoDB рекомендуем задействовать порты HAProxy на всех узлах. Для этого потребуется настроить ещё один балансировщик нагрузки на стороне вашего приложения. Вы можете использовать облачный сервис балансировки нагрузки или развернуть свой собственный.
Подключиться к СУБД#
После успешного запуска адреса и порты, которые прослушивает СУБД, можно найти на странице базы данных MongoDB.
Экземпляры MongoDB прослушивают порт tcp/27017.
Важно
Кластер позволяет сохранить доступность базы данных при отказе одного из узлов, но только если вы используете не одну, а все точки приёма запросов кластера (endpoints).
Клиенты и драйверы MongoDB поддерживают строку подключения (connection string), где можно указать точки приёма запросов для набора реплик, чтобы определение текущего первичного узла и переключение на новый узел выполнялись автоматически.
В общем виде подключение может выглядеть так:
mongodb://mongo1,mongo2,mongo3/?replicaSet="rsmain"
Для подключения достаточно указать несколько узлов, остальные будут определены автоматически.
replicaSet в таких автоматически развёрнутых кластерах всегда называется rsmain.
Вы можете управлять развёрнутым сервисом MongoDB как через стандартный консольный клиент mongo shell в Linux, так и использовать для этого графические инструменты, такие как TablePlus или Robo 3T.
Если вы хотите подключиться к сервису MongoDB удалённо, выполните следующие действия:
Откройте страницу экземпляра c развёрнутым сервисом MongoDB, перейдите на вкладку Сеть и безопасность и нажмите на идентификатор той группы безопасности, которую вы планируете использовать для регулирования доступа извне.
На странице группы безопасности перейдите на вкладку Входящие правила.
Добавьте разрешающее правило для протокола tcp и порта
27017.Назначьте Elastic IP сетевому интерфейсу этого экземпляра.
Важно
Будьте осторожны, открывая доступ к MongoDB из интернета. Рекомендуем ограничить доступ конкретными IP-адресами, а также использовать сложные пароли.
ClickHouse#
Варианты запуска сервиса#
Одиночный экземпляр СУБД, развёрнутый на одной виртуальной машине в одной зоне доступности.
Отказоустойчивая СУБД, развёрнутая в кластере из трёх или шести виртуальных машин в одной или (при наличии в регионе) нескольких зонах доступности. В кластере из трёх узлов все узлы совмещают роли координатора и сервера. Отказоустойчивая конфигурация
три совмещённых узла и до двенадцати серверовпредставляет собой три узла с ролью Координатор+Сервер и от нуля до двенадцати узлов с ролью Сервер. Отказоустойчивая конфигурациятри координатора и от трёх до двенадцати серверовпредставляет собой три узла с ролью Координатор и от трёх до двенадцати узлов с ролью Сервер.
Архитектура отказоустойчивого решения#
Для обеспечения отказоустойчивости и высокой доступности данных СУБД ClickHouse развёртывается в виде кластера. Архитектура отказоустойчивого решения предусматривает разделение функций управления и хранения данных. Архитектура кластера разделена на два уровня:
Координаторы (Keeper nodes) — управляют метаданными, репликацией и поддерживают консенсус внутри кластера. В нашем сервисе используется оптимизированный компонент ClickHouse Keeper.
Серверы (Server nodes) — отвечают за хранение и обработку данных.
Для продуктивных нагрузок совмещать роли координатора и сервера с данными на одном узле не рекомендуется.
В зависимости от целевой нагрузки и сценариев использования рекомендуется использовать один из двух вариантов архитектуры кластера:
Совмещённая архитектура#
Данная конфигурация является более экономичной и подходит для относительно небольших нагрузок или тестирования кластерного режима. В такой конфигурации одни и те же узлы одновременно выполняют функции координаторов и серверов.
Состав: Минимум три узла.
Особенности: При увеличении нагрузки рекомендуется переходить к разделённой архитектуре.
Примечание
Если сервис изначально развёрнут на трёх узлах, его дальнейшее масштабирование может происходить только за счёт добавления дополнительных серверов. Количество координаторов постоянно и всегда равно трём. В случае высокой нагрузки настоятельно рекомендуем включать в кластер дополнительные узлы-координаторы.
Разделённая архитектура#
Данная конфигурация более подходит для продуктивных систем. В кластерах с разделённой архитектурой роли координатора и сервера разнесены на разные виртуальные машины. Отказоустойчивый кластер содержит минимум два сервера, что позволяет создать шард с двумя репликами для обеспечения отказоустойчивости. При развёртывании сервиса, состоящего из шести и более узлов, создаются три отдельных узла-координатора и три и более сервера. Координаторы взаимодействуют между собой по протоколу консенсуса Raft, а также обеспечивают работу непосредственно серверов. Сервис поддерживает горизонтальное масштабирование: к трём узлам-координаторам можно добавить от двух до двенадцати узлов с ролью сервера.
Состав: три выделенных узла-координатора и два или более сервера.
Отказоустойчивость: Обеспечивается за счёт кворума координаторов и создания шардов с репликами на серверах.
Примечание
При создании сервиса следует задавать параметры узлов-координаторов и брокеров отдельно.
Рекомендации по конфигурации узлов#
Роль узла |
vCPU |
RAM |
Дисковая подсистема |
|---|---|---|---|
Выделенный координатор |
От 2 vCPU |
4 ГиБ |
Диск для данных от 64 ГиБ SSD |
Сервер (рекомендовано) |
От 8–16 vCPU |
32–64 ГиБ |
Диск для данных от 256 ГиБ |
Совмещённый узел |
От 4 vCPU |
От 32 ГиБ |
Диск для данных от 128 ГиБ |
Подключиться к СУБД#
После развёртывания PaaS-сервис ClickHouse принимает клиентские подключения на каждой виртуальной машине с ролью Сервер. Координаторы не отвечают на клиентские подключения.
Экземпляры ClickHouse (в составе отказоустойчивых и неотказоустойчивых сервисов) принимают подключения на портах tcp/8123, tcp/9000, tcp/9004 и tcp/9005.