Использование MariaDB MaxScale в качестве прокси-сервера базы данных

Настроить MaxScale в качестве прокси-уровня

MariaDB MaxScale представляет собой автономный прокси-уровень между приложением и серверами MariaDB. Для обеспечения стабильной работы конфигурация, доступные функции и известные ограничения должны всегда соответствовать фактически установленной версии. Серия MaxScale 25.10 представлена в официальной документации с отдельными примечаниями к выпуску.

Приложение подключается к прослушивателю MaxScale, а не напрямую к серверу базы данных. При этом сервис объединяет логику доступа, маршрутизатор определяет бэкэнд, а фильтры могут дополнительно обрабатывать запросы перед их перенаправлением. Данные остаются на бэкендах MariaDB; MaxScale сам по себе не становится базой данных.

Такое разделение особенно полезно, если приложение не должно само знать, какой сервер в данный момент выполняет какую роль. Основные сведения о модели данных, SQL и работе базы данных приведены в статье MariaDB как база данных с открытым исходным кодом подходящее дополнение. Прокси дополняет архитектуру сервера, но не заменяет ни прав доступа к базе данных, ни концепции репликации и обеспечения отказоустойчивости.

На сайте Маршрутизация соединений При установлении сеанса MaxScale выбирает целевой бэкенд; этот бэкенд остается ответственным за данный сеанс. При маршрутизации операторов маршрутизатор может по-разному распределять отдельные SQL-операторы в зависимости от их содержания. Поэтому выбор подходящего варианта зависит от транзакций, состояния сеанса и способности приложения самостоятельно четко разделять пути чтения и записи.

A Прокси базы данных не является универсальным обещанием производительности. Он может централизовать маршрутизацию, развязать смену ролей приложений или распределять соответствующие запросы на чтение. Однако дополнительные сетевые узлы, анализ SQL и конкретная топология бэкэнда влияют на поведение системы. Поэтому отказоустойчивость и пропускная способность должны проверяться с учетом конкретной версии, конфигурации и нагрузки.

Правильный мониторинг топологии «первичный-реплика»

Типичная целевая архитектура состоит из основного сервера (Primary), на который записываются данные, и одной или нескольких реплик (Replicas) для чтения. MaxScale является единственным конечным пунктом доступа к базе данных для приложения, например, за фиксированным DNS-именем. Следовательно, приложение не подключается напрямую к отдельным хостам; выбор доступного и подходящего бэкэнда происходит на уровне прокси-слоя.

Для топологии «первичный сервер — реплика» монитор определяет mariadbmon состояние бэкендов и определяет их роли — «Primary» или «Replica». Маршрутизаторы могут использовать эту информацию для выбора адреса назначения. Поэтому монитор должен иметь возможность видеть реальную топологию репликации; неверные сопоставления, нереплицированные данные или неясные роли не являются проблемами маршрутизации, а представляют собой операционные риски.

Распознавание роли следует отделять от её изменения. При соответствующей настройке и правах доступ mariadbmon может управлять переключением на резервный сервер, плановым переключением и повторным присоединением. Переключение — это заранее подготовленная смена роли для целей технического обслуживания или эксплуатации; отработка отказа — это реакция на сбой. Оба процесса требуют чёткой топологии, мониторинга, системы оповещения и документированного процесса реагирования на инциденты или восстановления работоспособности.

Для задач, связанных исключительно с мониторингом, учетная запись мониторинга должна быть настроена по принципу Наименьшие привилегии получают только необходимые права. В актуальной документации для этого используется термин REPLICA MONITOR. Дополнительные права требуются в зависимости от активированных функций, например, право FILE при проверке дискового пространства или другие специально проверяемые права для сканирования топологии и работы с кластерами. Общие полные права не могут служить заменой для этого.

Перед внедрением автоматизации команда должна определить, кто утверждает смену ролей, как будет проверяться состояние реплик и как приложения будут получать уведомления о сбоях. MaxScale может настраивать цели маршрутизации на основе распознанных ролей. Однако решение о том, допустимо ли переключение с технической точки зрения, принимается в рамках концепции высокой доступности с учётом ограничений, связанных с данными, временем и ответственностью.

Понимание маршрутизации SQL и границ согласованности

Маршрутизатор readwritesplit направляет SQL-операторы записи на основной сервер и распределяет соответствующие запросы на чтение по репликам. Таким образом, кластер из основного сервера и реплик может более целенаправленно использовать свою пропускную способность по чтению, при этом приложению не нужно самостоятельно сопоставлять каждый запрос с конкретным сервером. Информация о ролях, получаемая монитором, служит основой для выбора.

В стандартной реализации такое разделение не гарантирует, что после каждой записи операция чтения сразу же увидит новое состояние. causal_reads по умолчанию установлено на none. Например, если приложение записывает статус заказа, а затем считывает его посредством независимого запроса, реплика может предоставить предыдущее значение. Намеренно выбранный путь чтения с первичного сервера или общий контекст транзакции — это возможные стратегии, но не единственные.

Для «Читай свои записи» При включенной функции Causal Reads readwritesplit может учитывать предшествующие операции записи, несмотря на задержку репликации. Режим local обеспечивает видимость для этого же соединения. global отслеживает значение GTID, сохраненное сервисом, по всем своим соединениям; при этом глобальный порядок «происходит до» для операций чтения гарантируется только в том случае, если все транзакции находятся в пределах одного домена GTID. universal учитывает состояние транзакций кластера, наблюдаемое на сервере Primary. Однако более широкие области действия увеличивают нагрузку на синхронизацию и, следовательно, потенциально увеличивают задержку.

Каузальные чтения используют данные GTID и в режимах, не предполагающих высокую скорость, ожидают завершения репликации. Если синхронизация длится дольше, чем causal_reads_timeout – по умолчанию 10 секунд — функция readwritesplit пытается выполнить запрос на первичном сервере. В транзакции, защищённой от записи, вместо этого может быть возвращён таймаут в качестве ошибки, поскольку запрос не может быть перенаправлен на первичный сервер.

Быстрые режимы fast, fast_global и fast_universal не ждут реплику и при необходимости используют основной сервер; там таймаут не действует. Поэтому они подходят, прежде всего, для рабочих нагрузок, в которых преобладают операции чтения и мало операций записи. Начиная с версии MaxScale 24.02, MaxScale самостоятельно настраивает необходимое отслеживание для новых подключений к бэкенду; в более старых версиях для этого требуется last_gtid на сайте session_track_system_variables на всех бэкендах.

В рамках открытой транзакции чтения-записи функция readwritesplit направляет запросы на чтение на первичный сервер. Это позволяет избежать выполнения инструкций одной и той же транзакции на бэкэндах с разным состоянием репликации. Это консервативное правило не освобождает от необходимости правильно устанавливать границы транзакций с точки зрения бизнес-логики и рассматривать задержку репликации как отдельное архитектурное ограничение.

Даже в случае хранимых процедур, вызовов UDF и мульти-операторов решение принимается сознательно более осторожно: в задокументированных случаях такие запросы направляются в Primary. Причина заключается в том, что их последствия или контекст не следует рассматривать как простой запрос на чтение. Таким образом, маршрутизация SQL — это не просто поиск слова SELECT, а следование правилам безопасной обработки сеансов и семантики.

Специально выбранное предельное значение для Реплика-лаг может исключить реплики, связанные с определенными решениями о чтении, но не заменяет требование к согласованности. Допустимое отставание зависит, например, от того, допустима ли устаревшая запись в каталоге или же только что подтверждённый статус платежа должен быть обязательно виден. Это решение относится к логике приложения и соглашению об эксплуатации, а не к общей настройке прокси.

Безопасная настройка Readwritesplit

Конфигурация с разделением чтения и записи состоит из отдельных определений объектов для бэкендов, монитора, службы и прослушивателя. Приведённый ниже фрагмент демонстрирует структуру файла, а не готовый к использованию в производственной среде шаблон. Значения в острых скобках явно не являются паролями, а представляют собой ссылки на учетные записи и секреты, которые должны быть предоставлены через систему управления секретами производственной среды. При этом монитор и сервис требуют собственных учетных данных для выполнения своих различных задач.

[db-primary]
type=server
address=db-primary.example.invalid
port=3306

[db-replica-1]
type=server
address=db-replica-1.example.invalid
port=3306

[db-replica-2]
type=server
address=db-replica-2.example.invalid
port=3306

[cluster-monitor]
type=monitor
module=mariadbmon
servers=db-primary,db-replica-1,db-replica-2
user=<monitor-account-from-secret-management>
password=<monitor-secret-reference>

[RW-Service]
type=service
router=readwritesplit
servers=db-primary,db-replica-1,db-replica-2
user=<service-account-from-secret-management>
password=<service-secret-reference>

[RW-Listener]
type=listener
service=RW-Service
protocol=MariaDBClient
port=3306

Объекты сервера обозначают лишь доступные бэкэнды MariaDB; монитор определяет, какой экземпляр является первичным (Primary), а какой — репликой (Replica), на основе топологии. Учётная запись монитора используется для запросов о состоянии и ролях. Отдельная служебная учётная запись служит для получения от бэкендов информации о пользователях и правах, необходимой для аутентификации и авторизации клиентов. Обе учётные записи нуждаются только в правах, задокументированных для выполнения их соответствующих задач. Распознавание ролей Загрузка данных и информации о пользователе — это отдельные задачи.

Заполнители в примере должны быть заполнены при развертывании с помощью защищённого канала; они не предназначены для использования в качестве конфигурационных значений в исходном виде. Пароли в открытом виде, реальные пути к сертификатам или непроверенные наборы прав не должны храниться в файлах или репозиториях, доступных для свободного чтения. MaxScale внутренне управляет соответствующими учётными записями пользователей и правами из системных таблиц для соединений по протоколу MariaDB. В случае изменения учётных записей или прав устаревшая информация может повлиять на процесс входа в систему или авторизации.

Поэтому перед запуском необходимо отдельно проверить порт прослушивания, сетевые пути, сопоставление пользователей и фактическое назначение маршрутизаторов. Кроме того, автоматические действия монитора не входят по умолчанию в эту минимальную конфигурацию: функции отказоустойчивости, переключения или повторного присоединения требуют дополнительной настройки и проверенной концепции эксплуатации. Кажущаяся краткой конфигурация не заменяет ни управление секретными ключами, ни проверку топологии бэкэнда.

Сравнить модели маршрутизаторов по области применения

Выбор маршрутизатора зависит от поведения приложения, а не только от количества имеющихся реплик. Прямые соединения упрощают настройку, но переключение между целями и определение ролей остаются в ведении приложения. Две отдельные конечные точки с readconnroute подходят в тех случаях, когда приложение самостоятельно управляет соединениями для чтения и записи. Маршрутизация заявлений Использование параметра `readwritesplit` целесообразно, если необходимо направлять сеанс в зависимости от запросов SQL либо на основной сервер, либо на реплики.

readconnroute оценивает целевой сервер при установке соединения и не анализирует каждый последующий SQL-запрос. В случае сбоя выбранного бэкэнда сеанс завершается; маршрутизатор не подключает пользователя к другому серверу автоматически. Такой подход часто оправдан для четко разграниченных, кратковременных соединений для чтения, но может оказаться неподходящим для приложений с управлением состоянием.

Особую осторожность следует проявлять в отношении службы, предназначенной для использования в качестве конечной точки чтения, с router_options=slave. Данная опция отдаёт предпочтение серверам с ролью реплики; однако, если все реплики вышли из строя, а первичный сервер доступен, readconnroute может переключиться на первичный сервер. Кроме того, эта опция не обеспечивает защиту от записи. Приложение должно отправлять исключительно запросы SQL на чтение, либо дополнительный фильтр ReadOnly должен блокировать попытки записи. Таким образом, цель маршрутизации и предпочтение ролей не являются ни ограничением прав доступа, ни заменой ограничительных прав доступа к базе данных.

В свою очередь, подход «readwritesplit» сокращает количество решений о выборе целевого сервера в коде приложения, но требует тщательной проверки семантики. Подходящие операции чтения могут распределяться между репликами, тогда как операции записи направляются на первичный сервер. Для процессов со строгими требованиями к актуальности решающим фактором остаётся то, может ли запрос после записи ожидать реплицированных данных или должен сознательно использовать первичный сервер.

Планирование заседаний, запасов и перехода на новый режим работы

Сеанс работы с базой данных включает в себя не только один запрос. SET, USE, CHANGE USER а операции с подготовленными запросами изменяют свой контекст. readwritesplit реплицирует соответствующие команды сеанса на возможные целевые серверы, чтобы впоследствии можно было выполнять маршрутизированные запросы с соответствующим состоянием сеанса. Это отличает маршрутизатор от простой балансировки нагрузки по протоколу TCP, однако не устраняет все ограничения, связанные с особыми случаями.

В случае подготовленных запросов для временных таблиц это ограничение имеет особое значение. Если такой запрос подготовлен на основном сервере, реплики не всегда смогут его выполнить. Поэтому приложение должно тестировать временные объекты, подготовленные запросы и ход транзакций с учетом предусмотренной модели маршрутизации. Состояние сессии это не второстепенное условие, а фактор, определяющий, подходит ли распределение SQL с функциональной и технической точек зрения.

Для приложений с интенсивным чтением команда может определить установленное в соответствии с техническими требованиями пороговое значение задержки в качестве критерия исключения для реплик. Только max_replication_lag однако не гарантирует, что предыдущая запись на реплике уже видна. Для критически важных последующих чтений, в зависимости от сценария, могут рассматриваться целенаправленный путь к первичному серверу, общий контекст записи или активированные причинно-следственные чтения.

При использовании метода «Causal Reads» необходимо сознательно выбирать область применения. local сохраняет причинно-следственную связь внутри одного союза. global использует значение GTID, сохраненное на уровне всего сервиса, но гарантирует глобальный порядок «Happens-before» для операций чтения только в том случае, если все транзакции находятся в одном домене GTID. universal учитывает состояние транзакций кластера, наблюдаемое на первичном сервере. Небыстрые режимы синхронизируются с помощью GTID; если реплика не успевает синхронизироваться в течение настроенного таймаута, запрос всегда повторяется на первичном сервере, если это допускает режим транзакций.

Функция зависит от версии. Начиная с версии MaxScale 24.02, MaxScale дополняет last_gtid для новых подключений к бэкенду самостоятельно; в более старых версиях приходилось session_track_system_variables должны быть соответствующим образом настроены на бэкэндах MariaDB. Быстрые режимы позволяют избежать ожидания, однако в случае, если реплики ещё не успели синхронизироваться, они могут перенаправлять запросы на чтение к первичному серверу, поэтому не подходят для всех нагрузок с интенсивной записью.

Планируемый переход на резервный сервер и автоматическое переключение на резервный сервер также следует рассматривать отдельно. При переходе на резервный сервер смена ролей готовится контролируемым образом, тогда как при переключении на резервный сервер система реагирует на возникновение сбоя. mariadbmon может отслеживать роли и состояния бэкэнда и, при соответствующей настройке, поддерживать эти процессы. При этом обязательными условиями остаются реплицированное состояние данных, однозначная топология, система оповещения и процесс обработки инцидентов.

В MaxScale 25.10 можно discover-replicas Обнаружить серверы, которые реплицируются непосредственно на текущий первичный сервер, и добавить их в Monitor и MaxScale. Эта функция несовместима с синхронизацией конфигурации. Поэтому перед её использованием команда должна определить, будут ли изменения топологии обнаруживаться автоматически или управляться посредством синхронизированной конфигурации; одновременное использование обоих подходов в данном контексте недопустимо.

TLS, защита прав и фильтров

В MaxScale протокол TLS необходимо настраивать на двух отдельных участках: от приложения к прослушивателю и от прокси к бэкэндам MariaDB. Для обоих соединений требуются собственные настройки шифрования и проверки сертификатов; защищенный клиентский участок не обеспечивает автоматическое шифрование последующего трафика. Поэтому конфигурация должна учитывать требования к безопасности и цепочку доверия для обоих участков.

TLS включен ssl=true шифрование в соответствующей конфигурации прослушивателя или сервера. Если клиент ожидает получение сертификата сервера, прослушивателю потребуются сертификат и закрытый ключ. Учетная запись с REQUIRE SSL не может подключиться через слушатель без TLS. Файлы сертификатов и ключи должны храниться в защищённой производственной среде, а не в открытых для чтения примерах конфигураций или конфигурациях репозиториев.

Также Концепция прав На бэкендах остается важным следующее: MaxScale обеспечивает соединения, но не заменяет точные учетные записи базы данных. Учетные записи служб получают только те права доступа, которые необходимы для выполнения их задач. Для входа в систему и авторизации MaxScale опирается на учетные записи пользователей и права из системных таблиц MariaDB; поэтому изменения в этих учетных записях должны своевременно отражаться во внутренней системе управления пользователями.

Фильтр брандмауэра может проверять SQL-запросы перед их пропусканием на основе выученных или заданных правил. Он поддерживает режимы простоя, обучения, мониторинга и принудительного контроля; в режиме принудительного контроля на недопустимые шаблоны операторов, в зависимости от настроек, выдается сообщение об ошибке или разрывается соединение. Фаза обучения должна охватывать репрезентативные, разрешённые сценарии работы приложений, чтобы фильтр не блокировал обычные запросы.

Фильтр представляет собой дополнительный уровень контроля ожидаемых шаблонов SQL, а не замену прав доступа. Ограничительные права доступа к базе данных, защищённые учётные данные и проверенный код приложения по-прежнему необходимы, поскольку фильтр оценивает только те запросы, которые поступают к нему, на основе своих правил. Заявления о других фильтрах следует проверять отдельно, опираясь на соответствующую документацию.

Систематически проверять конфигурацию и ошибки

При ошибках подключения или маршрутизации лучше следовать четкому порядку проверки, а не вносить изменения наобум. Сначала проверьте состояние мониторинга: доступны ли все бэкэнды и правильно ли распознаны роли «Primary» и «Replica»? Только после этого можно адекватно оценить решения маршрутизатора. Неправильно распознанный или недоступный узел — это не просто проблема прослушивателя.

Далее следует проверка прослушивателя и TLS: порт, протокол, сертификат, ключ и требования используемых учетных записей должны совпадать. Затем проверьте, знает ли система управления учетными записями пользователей актуальные учетные записи бэкэнда и права доступа. Особенно после изменений, касающихся пользователей или прав доступа, устаревшие данные учетных записей могут препятствовать входу в систему, даже если сама учетная запись в MariaDB настроена правильно.

Далее тебе нужно назначить сервис, маршрутизатор и предусмотренные серверы. При разделении чтения и записи также необходимо учитывать задержку реплики, causal_reads и ограничения транзакций приложения в контрольный список. Если функция «Causal Reads» не активирована, чтение вне требуемого контекста записи на реплике может предоставить более старую версию данных; одно лишь значение порога задержки не гарантирует видимость предыдущей записи.

Кроме того, добавьте одну Источник конфигурации фиксированная. MaxScale может сохранять изменения во время выполнения; при перезапуске сохраненная конфигурация может перезаписать статические файлы. Если команда частично редактирует файлы, а частично maxctrl при использовании данной конфигурации среды выполнения необходимо в обязательном порядке задокументировать путь внесения изменений, процесс проверки и резервное копирование этой конфигурации.

Окна обслуживания для изменений схемы следует рассматривать как отдельную область эксплуатации: зависимости, поведение блокировок и репликацию необходимо проверять заранее, не возлагая ответственность на прокси. Для планирования контролируемых изменений в больших таблицах MariaDB в статье, посвященной Изменение схемы без простоев дополнительный контекст. После этого MaxScale может вновь управлять соединениями и маршрутизацией на основе ролей бэкэнда, но не выполняет стратегию DDL базы данных.

Предупреждение: изменения, касающиеся ролей, сертификатов, прав пользователей и маршрутизации, следует сначала протестировать в аналогичной среде. При выполнении операций в производственной среде необходимо предусмотреть процедуру отката, мониторинг ошибок приложения и четкое распределение ответственности. Это позволит определить, связано ли сбой с настройками прокси, бэкендом или поведением клиента.

Правильно использовать MaxScale или отказаться от него

В случае отдельного сервера MariaDB, не требующего маршрутизации, переключения или фильтрации SQL, прямые соединения, как правило, являются более простым способом работы. Однако в таком случае приложение должно самостоятельно обрабатывать последующую смену адреса назначения. Использование MaxScale оправдано, если дополнительный конечный узел выполняет конкретную задачу, например, перехват смены ролей, фильтрацию запросов или контролируемое распределение чтений между репликами.

Если приложение может самостоятельно выбирать пути чтения и записи, отдельные конечные точки обозначаются с помощью readconnroute часто понятно. Этот маршрутизатор при установке соединения выбирает бэкенд, однако не анализирует каждый SQL-запрос и не перенаправляет прерванную сессию на другой сервер. При router_options=slave предпочтение отдается репликам; если все реплики вышли из строя, а первичный сервер по-прежнему доступен, маршрутизатор может использовать первичный сервер. Кроме того, эта опция не делает конечную точку защищенной от записи. Для этого необходимы соответствующий фильтр ReadOnly, ограничительные права бэкэнда или строго контролируемый SQL приложения.

Для рабочих нагрузок типа «первичный сервер — реплика», ORM и модель транзакций которых подходят для этого, используется readwritesplit приложение выполняет выбор цели SQL для каждого оператора. При стандартной настройке causal_reads=none однако задержка репликации по-прежнему остается заметной. После критических операций записи приложение может использовать основной путь чтения или подходящий общий контекст транзакции; в качестве альтернативы можно целенаправленно настроить причинно-следственные чтения для необходимой области видимости.

Causal Reads различают видимость в пределах одного сеанса, глобальный счетчик GTID, управляемый сервисом, и состояние кластера, наблюдаемое на первичном узле. local применимо к тому же соединению. В случае global Глобальный порядок «Happens-before» для операций чтения гарантируется только в том случае, если все транзакции принадлежат к одному домену GTID; поэтому этот режим не следует воспринимать как безусловную гарантию согласованности на уровне всей службы. universal перед операциями чтения проверяет текущее состояние на первичном сервере. Режимы синхронизации могут приводить к дополнительному времени ожидания; быстрые варианты не ожидают, но при операциях записи могут в большей степени переносить нагрузку на первичный сервер.

Предельные случаи требуют проведения целенаправленных тестов с использованием реального драйвера и модели данных перед внедрением. Временные таблицы и подготовленные на их основе операторы могут быть недоступны на репликах, если подготовка осуществляется на первичном сервере. Кроме того, хранимые процедуры, вызовы пользовательских функций (UDF), мультиоператоры и состояние сеанса влияют на то, будет ли маршрутизатор консервативно направлять запросы на первичный сервер.

Функция «Transaction Replay» не гарантирует отсутствие потерь при проведении транзакций. Если соединение прерывается во время COMMIT Можно не учитывать, был ли коммит уже успешно выполнен. Рискованные конфигурации повторного воспроизведения могут привести к двойному выполнению операций записи; результаты, зависящие от сервера, такие как NOW() или @@server_id Кроме того, они могут вызывать расхождения в контрольных суммах. Поэтому оценивайте применение данного решения, исходя из требований к согласованности, сценариев возникновения ошибок и повторяемости операций записи, а не на основе общих обещаний о производительности.