Советы по переходу на Galera

Эти темы будут обсуждаться более подробно ниже.

Уважаемый разработчик схем:

• Используйте только InnoDB, всегда имейте первичный ключ.

Уважаемый разработчик:

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

Уважаемый DBA:

• Настройка машин отличается. (Здесь не рассматривается)
• ALTER обрабатываются по-другому.
• Возможно, потребуются проверки TRIGGER и EVENT.
• Трюки с репликацией (например, BLACKHOLE) могут не работать.
• Необходимо изменить несколько переменных.

Galera доступен во многих местах

Репликация Galera с высокой доступностью доступна через:

• MariaDB 10.1 и более поздние версии
• Percona XtraDB Cluster
• Galera Cluster for MySQL от Codership

Обзор кросс-коло-записи

(Этот обзор действителен даже для узлов в одном дата-центре, но проблемы с задержкой исчезают.)

Задержка кросс-коло отличается от традиционной репликации, но не обязательно лучше или хуже с Galera. Задержка возникает в разное время для Galera.

В «традиционной» репликации эти шаги происходят:

• Клиент взаимодействует с Master. Если клиент и Master находятся в разных коло, это приводит к задержке.
• Каждый SQL-запрос к Master — это дополнительная задержка, включая(?) COMMIT (если не используется autocommit).
• Репликация к Slave(s) асинхронна, поэтому это не влияет на запись клиента в Master.
• Поскольку репликация асинхронна, клиент (текущий или последующий) не может гарантированно увидеть данные на Slave. Это «критическое чтение». Асинхронная задержка репликации заставляет приложения принимать какие-то обходные меры.

В репликации, основанной на Galera:

• Клиент взаимодействует с любым Master — возможно, с задержкой кросс-коло. Или можно расположить узлы Galera рядом с клиентами, чтобы избежать этой задержки.
• В момент COMMIT (или в конце оператора в случае autocommit=1) galera выполняет один запрос к другим узлам.
• COMMIT обычно выполняется успешно, но может завершиться неудачно, если другой узел изменяет те же строки. (Galera повторяет попытку при сбое autocommit).
• Неудачный COMMIT сообщается клиенту, который должен просто повторить SQL-операции с начала.
• Позже вся транзакция будет применена (с возможным конфликтом) на других узлах.
• Критическое чтение — подробности ниже

Для N-операционной транзакции: В типичной настройке «традиционной» репликации:

• 0 или N (N+2?) задержек, в зависимости от того, находится ли клиент в одном коло с Master.
• Задержки и временные отставания репликации приводят к проблемам с «критическими чтениями».

В Galera:

• 0 задержек (при условии, что клиент находится «рядом» с каким-либо узлом)
• 1 задержка для COMMIT.
• 0 (обычно) для критического чтения (подробности ниже)

Итог: В зависимости от расположения клиентов и того, объединяете ли вы операторы в транзакции BEGIN...COMMIT, Galera может быть быстрее или медленнее, чем традиционная репликация в топологии WAN.

AUTO_INCREMENT

Используя wsrep_auto_increment_control = ON, значения auto_increment_increment и auto_increment_offset будут автоматически скорректированы при добавлении/удалении узлов.

Если вы создаёте кластер Galera, начав с одного узла как Slave существующей системы без Galera и у вас есть многострочные INSERT, зависящие от AUTO_INCREMENT, прочитайте этот блог Percona

Итог: Возможно, будут пробелы в значениях AUTO_INCREMENT. Последовательные строки, даже в одном соединении, не будут иметь последовательных идентификаторов.

Будьте осторожны с прокси, которые пытаются реализовать «разделение чтений и записей». В некоторых ситуациях ссылка на LAST_INSERT_ID() будет отправлена в «Slave».

Только InnoDB

Для эффективной репликации данных необходимо использовать только InnoDB. Это исключает

• FULLTEXT-индекс (до 5.6)
• SPATIAL-индекс
• PK MyISAM в качестве второго столбца

Можно использовать MyISAM и MEMORY для данных, которые не нужно реплицировать.

Также следует использовать «START TRANSACTION READONLY» там, где это уместно.

Проверка после COMMIT

Проверяйте ошибки после выполнения COMMIT. Возможна ситуация «тупик» из-за записи на других узлах.

Возможная исключительная ситуация (может быть полезна для устаревшего кода без таких проверок): Обращайтесь к системе как к одному Master плюс Slaves. Запись только в один узел, COMMIT должен всегда выполняться успешно(?)

Что насчёт autocommit = 1? wsrep_retry_autocommit сообщает Galera перепробовать, если одиночный оператор, который autocommited N раз. Поэтому есть всё ещё шанс (очень небольшой) попасть в тупик на таком операторе. Значение по умолчанию «1» для повторений, вероятно, хорошо.

Всегда используйте первичный ключ

Будет использоваться «репликация на основе строк»; это требует первичного ключа в каждой таблице.

Таблица без репликации (например, MyISAM) не должна иметь первичного ключа.

Размер транзакции

(Этот раздел предполагает наличие узлов Galera в нескольких коло.) Из-за некоторых проблем, о которых говорилось ранее, рекомендуется группировать ваши операторы записи в транзакции умеренного размера BEGIN...COMMIT. Есть одна задержка на каждый COMMIT или autocommit. Поэтому объединение операторов уменьшит эти задержки. С другой стороны, не следует создавать слишком большие транзакции, такие как вставка/модификация миллионов строк в одной транзакции.

Для обработки ошибок при COMMIT разработайте код, позволяющий повторить SQL-операции в транзакции без нарушения других данных. Например, переместите «нормализационные» операторы из основной транзакции; нет веских причин отменять их, если отменяется основной код.

В любом случае, выполнение того, что «правильно» для бизнес-логики, имеет приоритет над другими соображениями.

tx_isolation Galera находится между Serializable и Repeatable Read. Переменная tx_isolation игнорируется.

Установите wsrep_log_conflicts, чтобы получить ошибки в обычном файле журнала MySQL mysqld.err.

Транзакции XA не поддерживаются. (Galera уже выполняет форму XA для своей работы.)

Критические чтения

Вот простой (но не бесплатный) способ гарантировать, что чтение после записи, даже с другого подключения, увидит обновлённые данные.

SET SESSION wsrep_sync_wait = 1; SELECT ... SET SESSION wsrep_sync_wait = 0;

Для операций, не являющихся SELECT, используйте другой набор битов для первого SELECT. (Н/Д: Будет ли 0xffff всегда работать?) (До Galera 3.6, это было wsrep_causal_reads = ON.) Документация по wsrep_sync_wait

Это значение приостанавливает SELECT до тех пор, пока все текущие обновления не будут применены к узлу. Это достаточно для гарантии того, что предыдущая запись будет видна. Время затрат обычно равно нулю. Однако большая операция UPDATE может привести к задержке. Благодаря RBR и параллельному применению, задержки, скорее всего, будут меньше, чем при традиционной репликации. Блог Зайцева

Для веб-приложения может быть более практичным просто установить wsrep_sync_wait сразу после подключения.

MyISAM и MEMORY

Как уже говорилось, используйте только InnoDB. Однако здесь приводится дополнительная информация о проблемах MyISAM (и, следовательно, FULLTEXT, SPATIAL и т. д.).

Таблицы MyISAM и MEMORY не реплицируются.

Отсутствие репликации таблиц MyISAM может быть большим преимуществом — вы можете «CREATE TEMPORARY TABLE ... ENGINE=MyISAM» и заставить её существовать только на одном узле. RBR гарантирует, что любые данные, переданные из этой временной таблицы в «реальную» таблицу, всё ещё могут быть реплицированы.

Репликация GRANT

GRANT и связанные операции действуют на MyISAM-таблицах в базе данных `mysql`. Операции GRANT будут (?) реплицироваться, но основополагающие таблицы — нет.

ALTER

Многие изменения DDL в Galera могут быть выполнены без простоя, даже если они занимают много времени.

RSU против TOI:

• Поэтапное обновление схемы (RSU): вручную выполните DDL на каждом узле в кластере. Узел будет несинхронизирован во время выполнения DDL.
• Изоляция в полном порядке (TOI): Galera автоматически реплицирует DDL на каждый узел в кластере и синхронизирует каждый узел таким образом, что оператор выполняется одновременно (в последовательности репликации) на всех узлах.

Внимание: Поскольку нет способа синхронизировать клиентов с DDL, необходимо убедиться, что клиенты удовлетворены как старой, так и новой схемой. В противном случае, вероятно, придётся остановить весь кластер, одновременно переключившись и на схему, и на клиентский код.

Быстрые операции DDL обычно могут выполняться в режиме TOI:

• Операции DDL, поддерживающие алгоритмы NOCOPY и INSTANT, обычно очень быстрые.
• Операции DDL, поддерживающие алгоритм INPLACE, могут быть быстрыми или медленными, в зависимости от необходимости перестроения таблицы.
• Операции DDL, поддерживающие только алгоритм COPY, обычно очень медленные.

Список операций, поддерживающих различные алгоритмы, см. в InnoDB Online DDL.

Если нужно использовать режим RSU, выполните следующие действия отдельно для каждого узла:

SET SESSION wsrep_OSU_method='RSU';
ALTER TABLE tab <alter options here>;
SET SESSION wsrep_OSU_method='TOI';

Дополнительное обсуждение процедур RSU

Конфигурация с одним «Master»

Можно «симулировать» Master + Slaves, заставив клиентов записывать данные только на один узел.

• Не нужно проверять ошибки после COMMIT.
• Потеряны преимущества задержек.

Трюки DBA

• Удалить узел из кластера; создать резервную копию; вернуть узел в кластер. Синхронизация происходит автоматически.
• Удалить узел из кластера; использовать его для тестирования и т. д.; вернуть узел в кластер. Синхронизация происходит автоматически.
• Поэтапное обновление аппаратного/программного обеспечения: Удалить; обновить; вернуть. Повторить.

Переменные, которые могут потребовать изменения

• auto_increment_increment - Если вы записываете на несколько узлов и используете AUTO_INCREMENT, то auto_increment_increment автоматически будет равен текущему количеству узлов.
• binlog-do/ignore-db - Не использовать.
• binlog_format - ROW требуется для Galera.
• innodb_autoinc_lock_mode - 2
• innodb_doublewrite - ON: Если происходит IST, нужно, чтобы не было поврежденных страниц? (С FusionIO или другими накопителями, гарантирующими атомарность, лучше OFF.)
• innodb_flush_log_at_trx_commit - 2 или 0. IST или SST восстановится из потери, если у вас 1.
• query_cache_size - 0
• query_cache_type - 0: Кэш запросов нельзя использовать в контексте Galera.
• wsrep_auto_increment_control - Обычно нужно включить ON
• wsrep_on - ON
• wsrep_provider_options - Возможно, потребуется настройка различных параметров, если вы используете WAN.
• wsrep_slave_threads - использовать для параллельной репликации
• wsrep_sync_wait (ранее wsrep_causal_reads) - используется временно для обработки «критических чтений».

Разное

В последнее время FOREIGN KEY были с ошибками.

LOAD DATA автоматически разделяется на части. То есть он передается другим узлам по частям, а не все сразу.

Известные проблемы MariaDB с Galera

DROP USER может не реплицироваться?

Небольшая разница в ROLLBACK для конфликта: InnoDB откатывает меньшую транзакцию; Galera откатывает последнюю.

Презентация по Galera

SET GLOBAL wsrep_debug = 1; приводит к многому debug-информации в журнале ошибок.

Большие UPDATE / DELETE следует разбивать. Это правило справедливо для всех баз данных, но в Galera есть дополнительные проблемы.

WAN: Возможно, потребуется увеличить (от значений по умолчанию) wsrep_provider_options = evs...

MySQL/Percona 5.6 или MariaDB 10 рекомендуется при переходе к Galera.

Ограничения кластера Презентация

GTID

См. Использование MariaDB GTID с MariaDB Galera Cluster.

Количество узлов в кластере

Если все серверы находятся в одной «зоне уязвимости» — например, стойке или дата-центре — иметь нечетное число (как минимум 3) узлов.

При охвате нескольких дата-центров вам нужно 3 (или более) дата-центров, чтобы быть «всегда» активным, даже при отказе дата-центра. При наличии только 2 дата-центров Galera может автоматически восстановиться после отказа одного дата-центра, но не другого. (Вы выбираете, какой.)

Если вы используете 3 или 4 дата-центра, эти количества узлов на каждый дата-центр являются безопасными:

• 3 узла: 1+1+1 (1 узел в каждом из 3 дата-центров)
• 4 узла: 1+1+1+1 (4 узла не будут работать в 3 дата-центрах)
• 5 узлов: 2+2+1, 2+1+1+1 (5 узлов распределены «равномерно» по дата-центрам)
• 6 узлов: 2+2+2, 2+2+1+1
• 7 узлов: 3+2+2, 3+3+1, 2+2+2+1, 3+2+1+1 Возможно, есть способ «взвесить» узлы по-разному; это позволило бы нескольким дополнительным конфигурациям. При «взвешивании» присвойте каждому дата-центру одинаковый вес; затем разделите вес в каждом дата-центре равномерно. Четыре узла в 3 дата-центрах: (1/6+1/6) + 1/3 + 1/3 Таким образом, отказ любого одного дата-центра не может привести к «расщепленному мозгу».

Postlog

Опубликовано в 2013 году; ПЕРЕМЕННЫЕ: 2015; Обновлено в феврале 2016 года

См. также

Рик Джеймс любезно разрешил нам использовать эту статью в базе знаний.

Сайт Рика Джеймса содержит другие полезные советы, руководства, оптимизации и советы по отладке.

Исходный источник: http://mysql.rjweb.org/doc.php/galera