MariaDB Galera Cluster — Известные Ограничения

В этой статье содержится информация о известных проблемах и ограничениях MariaDB Galera Cluster.

Ограничения, предоставленные codership.com:

• В настоящее время репликация работает только с движком InnoDB. Любые записи в таблицы других типов, включая системные (mysql.*) таблицы, не реплицируются (это ограничение не включает операторы DDL, такие как CREATE USER, которые неявно изменяют таблицы mysql.* — они реплицируются). Однако существует экспериментальная поддержка MyISAM — см. системную переменную wsrep_replicate_myisam)

• Неподдерживаются явные блокировки, включая LOCK TABLES, FLUSH TABLES {explicit table list} WITH READ LOCK, (GET_LOCK(), RELEASE_LOCK(),…). Правильное использование транзакций должно позволить преодолеть эти ограничения. Глобальные операторы блокировки, такие как FLUSH TABLES WITH READ LOCK, поддерживаются.

• Все таблицы должны иметь первичный ключ (поддерживаются многоколоночные первичные ключи). Операции DELETE не поддерживаются для таблиц без первичного ключа. Кроме того, строки в таблицах без первичного ключа могут отображаться в разном порядке на разных узлах.

• Журнал общих запросов (general query log) и журнал медленных запросов (slow query log) не могут быть направлены в таблицу. Если вы включите эти журналы, вам нужно направить журнал в файл, установив log_output=FILE.

• XA-транзакции не поддерживаются.

• Размер транзакции. Хотя Galera явно не ограничивает размер транзакции, набор изменений обрабатывается как один буфер в оперативной памяти, и в результате крайне большие транзакции (например, LOAD DATA) могут отрицательно повлиять на производительность узла. Чтобы избежать этого, системные переменные wsrep_max_ws_rows и wsrep_max_ws_size по умолчанию ограничивают количество строк в транзакции 128K, а размер транзакции — 2 Гб. При необходимости пользователи могут увеличить эти ограничения. Будущие версии добавят поддержку фрагментации транзакций.

Другие замечания (в произвольном порядке):

• Если вы используете mysqldump для переноса состояния, и он потерпел неудачу по какой-либо причине (например, у вас нет учетной записи базы данных, с которой он пытается подключиться, или у неё нет необходимых разрешений), вы увидите ошибку синтаксиса SQL в журнале ошибок сервера (error log). Не позволяйте этому обмануть вас, это просто элегантный способ передачи сообщения (псевдо-выражение внутри ложной SQL-записи фактически содержит сообщение об ошибке).

• Не используйте транзакции существенного размера. Только для вставки 100K строк серверу может потребоваться дополнительный объём памяти 200-300 Мб. В менее благоприятной ситуации это может быть 1,5 Гб для 500K строк или 3,5 Гб для 1 млн строк. См. MDEV-466 для некоторых чисел (вы увидите, что оно закрыто, но не потому, что проблема была решена).

• Блокировки имеют слабую работу при операциях DDL. Например, если ваша транзакция DML использует таблицу, а параллельно запускается оператор DDL, в обычной настройке MySQL он ожидал бы блокировки метаданных, но в контексте Galera он будет выполнен сразу. Это происходит даже если вы работаете на одном узле, если вы настроили его как узел кластера. См. также MDEV-468. Это поведение может вызвать различные побочные эффекты, последствия пока не изучены. Постарайтесь избегать такого параллелизма.

• Не полагайтесь на то, что значения автоинкремента будут последовательными. Galera использует механизм, основанный на автоинкременте, для генерации уникальных неконфликтующих последовательностей, поэтому на каждом узле последовательность будет иметь пробелы. См. http://codership.blogspot.com/2009/02/managing-auto-increments-with-multi.html

• Команда может завершиться ошибкой с ER_UNKNOWN_COM_ERROR выдавая сообщение об ошибке «WSREP ещё не подготовил узел для использования» (или «Неизвестная команда» в более старых версиях). Это происходит, когда предполагается разделение кластера, и узел находится в меньшей части — например, во время сбоя сети, когда узлы временно теряют связь друг с другом. Это также может произойти во время передачи состояния. Узел принимает это меру для предотвращения несоответствия данных. Обычно это временное состояние, которое можно определить, проверив значение wsrep_ready. Тем не менее, узел позволяет использовать команды SHOW и SET в течение этого периода.

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

• Хотя binlog_format проверяется при запуске и может быть только ROW (см. Форматы двоичных журналов), его можно изменить во время выполнения. НЕ изменяйте binlog_format во время выполнения, это, вероятно, не только приведёт к сбою репликации, но и к падению всех других узлов.

• Если вы используете rsync для передачи состояния, и узел выходит из строя до завершения передачи состояния, процесс rsync может зависнуть навсегда, занимая порт и не позволяя перезапустить узел. Проблема проявится в журнале ошибок сервера как «порт в использовании». Найдите процесс rsync-орфан и завершите его вручную.

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

• Windows не поддерживается.

• Фильтры репликации: при использовании кластера Galera фильтры репликации следует использовать с осторожностью. Более подробную информацию см. в разделе «Настройка кластера MariaDB Galera: фильтры репликации» (Configuring MariaDB Galera Cluster: Replication Filters). См. также MDEV-421 и MDEV-6229.

• Восстановление состояния (Flashback) не поддерживается в Galera из-за несовместимого формата двоичного журнала.

• FLUSH PRIVILEGES не реплицируется.

• Кэш запросов (query cache) необходимо было отключить, установив query_cache_size=0 до MariaDB Galera Cluster 5.5.40, MariaDB Galera Cluster 10.0.14 и MariaDB 10.1.2.

• В конфигурации асинхронной репликации, где мастер реплицирует данные на узел Galera, работающий в качестве ведомого, параллельная репликация (slave-parallel-threads > 1) на ведомом в настоящее время не поддерживается (см. MDEV-6860).

• Базированный на диске Galera gcache не шифруется (MDEV-8072).

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