[TMI]

Введение

Форум Vazooka изначально работал на MariaDB 11. Всё было хорошо до тех пор, пока не возникла потребность в кластеризации и повышении отказоустойчивости. Для этого было решено мигрировать на Percona XtraDB Cluster 8.4 (PXC 8.4).

Но миграция оказалась не тривиальной: различия между MariaDB и MySQL 8/Percona затронули многие таблицы и SQL-запросы. В статье мы разберём, с какими проблемами мы столкнулись, и как их решили.

---

Основные различия между MariaDB 11 и Percona 8.4

1. Строгий режим (STRICT_MODE)
   В Percona XtraDB по умолчанию включён pxc_strict_mode=ENFORCING, который запрещает:

   • DML-операции (INSERT/UPDATE/REPLACE) без PK

   • использование NULL в PRIMARY KEY

   • вставки в NOT NULL без DEFAULT

2. Обязательный PRIMARY KEY
   В MariaDB можно было спокойно иметь таблицы без PK и использовать REPLACE INTO. В PXC это запрещено.

3. DEFAULT значения
   MariaDB часто молча подставляла 0 или '' в NOT NULL поля. MySQL 8/Percona требует явного DEFAULT или передачи значения.

---

Этапы миграции

1. Подготовка дампа

Сначала сделали полный дамп MariaDB:

mysqldump --single-transaction --routines --triggers --events \
  --default-character-set=utf8mb4 \
  -u root -p vazooka > vazooka_mariadb11.sql

---

2. Загрузка в Percona

При загрузке дампа сразу вылезли ошибки:

• Percona-XtraDB-Cluster prohibits use of DML command ... without an explicit primary key

• Field 'xxx' doesn't have a default value

• Incorrect default value for 'map_latest_date'

---

3. Исправление проблем с PK

Проблема: часть таблиц (***_count_cache, sessions, кеши) не имели PRIMARY KEY.

Решение:

• Добавили PK там, где реально есть уникальные ID:

ALTER TABLE ***_count_cache 
  ADD PRIMARY KEY (`id`);

 - В таблицах, где ID повторялись, сделали составной PK:

ALTER TABLE ***_member_map
  ADD PRIMARY KEY (`***_class`, `***_item_id`, `***_member_id`);

4. Исправление NOT NULL без DEFAULT

Проблема: поля вроде ***_latest_date INT UNSIGNED NOT NULL ломали вставки.

Решения:

    Если дата может быть неопределена → разрешили NULL:

ALTER TABLE ***_item_member_map
  MODIFY ***_latest_date INT UNSIGNED NULL;

Если всегда должен быть fallback → задали DEFAULT 0:

    ALTER TABLE ***_item_member_map
      MODIFY ***_latest_date INT UNSIGNED NOT NULL DEFAULT 0;

    В коде (там, где это реально дата) заменили REPLACE INTO на явную вставку с UNIX_TIMESTAMP().

5. Очистка дублей

Когда пытались добавить PK в таблицы без уникальных значений, выскакивала ошибка:

#1062 - Duplicate entry '25' for key 'PRIMARY'

Решение: перед добавлением PK находили и удаляли дубликаты:

DELETE t1 FROM ***_count_cache t1
JOIN ***_count_cache t2
ON t1.id = t2.id AND t1.added < t2.added;

После этого можно было спокойно добавить PRIMARY KEY.

---

6. Финальная оптимизация

• Прогнали ANALYZE TABLE и OPTIMIZE TABLE для пересчёта статистики.

• Включили innodb_strict_mode=ON и протестировали весь функционал форума.

• Проверили работу кластеризации PXC (wsrep).

---

Итог

После миграции база форума Vazooka полностью заработала на Percona XtraDB Cluster 8.4.

✅ Все таблицы получили явные PRIMARY KEY
✅ У всех NOT NULL полей появились DEFAULT или разрешены NULL
✅ Код был поправлен для явной записи map_latest_date
✅ Удалены дубликаты, мешавшие добавлению PK
✅ Теперь база готова к горизонтальному масштабированию и высокой нагрузке

---

Вывод

Миграция с MariaDB на Percona XtraDB — это не просто «загрузить дамп». Нужно:

• проверять схему на наличие PK,

• убирать неявные значения NULL,

• править DEFAULT,

• чистить дубликаты.

Но результат стоит того: форум Vazooka теперь работает в кластерной конфигурации с высокой отказоустойчивостью и готов к росту.