Как установить mariadb поверх mysql?

Question

[Алёна]

Добрый день. Назрел вопрос об оптимизации наших веб серверов. Ещё колеблемся между percona и mariadb.
Суть вопроса - у нас в инфраструктуре устроено так, что само приложение лежит рядышком с бд. Сейчас связка томкат7 и мускул 5.5 и ночной дамп бд. Для оптимизации - планируем настроить репликацию master-slave. Но чтобы было совсем хорошо - ещё и вместо мускула - его форк.
Как без лишних манипуляций - сделать из мускула - марию (или перкону)
Гугл не понимает моих запросов)

Comments

[landergate]

А объём данных у действующей базы данных большой?

Answer 1

[Николай Турнавиотов]

снести мускуль, поставить марию. вообще в центось 7 юм инсталл мускуль помнится ставит марию уже, или ставит марию, но #mysql запускает клиент марии по алиасу

Comments

[Алёна]

У нас все на убунте 14.04 ,
Если сносить - то долгое время недоступности сервиса (

[Николай Турнавиотов]

Алёна: а зачем вообще что-то менять? работает - не трожь. мария - это чуть чуть перепиленный мускуль. это первое. второе - почему простой? в нормальном режиме это несколько серверов с репликацией. обновлять по порядку

[Николай Турнавиотов]

Я правда уже оставил мускуль исключительно для жумл-вордпрессов на хостингах - все остальное все нормальные люди пишут с использованием postgresql

[Алёна]

Николай Турнавиотов: у нас руководство каждую минуту простоя - считает за колапс. Лет 7 назад как кто то поставил мускуль - так больше никто ничего и не хотел. Сейчас кол-во пользователей приложения разрослось. База выросла до 150 гигов. В момент ночных дампов - все отваливается по таймауту (( Селект по всем пользователям - выполняется минуты по 3. При том, что перевели все приложения в цод и это немного ускорило работу. И не дай бог - что то купить. Все нужно open sourse

[landergate]

Николай Турнавиотов:
> все остальное все нормальные люди пишут с использованием postgresql
Но это не всегда так.
Вряд ли идея "переходите на postgresql" вообще как-либо относится к описанной ситуации. А коммент читается именно как "переходите".

[Николай Турнавиотов]

landergate: за последние 6 лет админства/девопства/хостмастеринга в 2х хостинг операторах мускуль вижу исключительно для жумлы/битрикса/вордпресса, всё остальное - исключительно кластера потсгреса + 100+ гигабайтные базы

[Николай Турнавиотов]

Алёна: ну вот я и говорю - что сервера должны быть в кластере, и переход тут поможет мало, потому что архитектура "так себе". у меня на проектах бекапы обычно делаются со слейв серверов

[landergate]

Николай Турнавиотов: Я не ввязываюсь в холивар MySQL vs PostgreSQL, оба решения достаточно хорошие, у PostgreSQL есть несколько некритичных фич вдобавок, но пояснил, скорее даже для автора, чтобы он не увидел в "переходе на PostgreSQL" решение своей ситуации с оптимизацией работы имеющегося приложения. У них нет возможности всё мигрировать за одну секунду, как и потребности именно в PostgreSQL.

Answer 2

[qasdfwe]

Docker

Comments

[Алёна]

вещь хорошая, вот только у нас болеют за все бесплатное

[qasdfwe]

Алёна: Он бесплатен, вообще-то.
И огромная инфраструктура бесплатного ПО вокруг него сложилась.

[Алёна]

qasdfwe: видимо я слишком поверхностно погуглила. Да - цены на облака стоят.

[qasdfwe]

Алёна: Вы наверное о каких-то платных сервисах, предоставляемых фирмой, изготавливающей Docker... И предоставляющей эти сервисы при помощи самого же Докера и для него же. Это создает иллюзию платности.

Сам же Docker и куча дополнительного ПО для него - совершенно бесплатны.
Вместо платного online-registry вы можете использовать бесплатное локальное частное свое собственное docker-registry

[qasdfwe]

Алёна: Это странно. Сейчас вокруг Докера идет такой бум-шум, что сложно не найти кучу статей о бесплатном использовании Докера.

Я так вообще был удивлен, когда узнал о том, что за Докер где-то что-то нужно платить.

Ибо все основные вещи - совершенно бесплатны. И исходники доступны.

Answer 3

[safenoob]

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

Answer 4

[landergate]

Касательно миграции:

В общей ситуации, может быть достаточно следующего:

1. Выделить внерабочее время, когда можно будет провести профилактику.
   
2. Сделать резервную копию БД (как приложения, так и information_scheme)
   
3. Остановить MySQL
   
4. Сделать резервную копию файлов данных (/var/lib/mysql)
   
5. Сделать резервную копию конфигов из /etc/mysql
   
6. Удалить пакет: 'sudo apt-get remove mysql-server'
   
7. Подключить репозиторий MariaDB:
   https://downloads.mariadb.org/mariadb/repositories/
   
8. Выполнить sudo apt-get update
   
9. Установить пакет: sudo apt-get install mariadb-server
   
10. Убедиться, что приложение работает, как ожидается.
    

Всё.

Что может пойти не так:
- Слишком существенная разница в конфигах гипотетически может привести к проблеме чтения имеющихся файлов данных новым сервером, препятствуя запуску службы. Причину при этом скорее всего напишет в /var/log/mysql.log или /var/log/mysql.err.
Я с таким прежде не сталкивался, но если это случится, то будет быстрее: удалить MariaDB, затем отключить репозиторий (удалив соответствующую строку/файл из /etc/apt/sources.list или /etc/apt/sources.list.d/), затем sudo apt-get update, затем установить пакет mysql-server обратно. Перед этим, хорошей идеей будет откатить бэкапы /etc/mysql и /var/lib/mysql на прежние места, чтобы исключить последствия изменения файлов данных/конфигов обновлением на MariaDB. Затем проанализировать, что пошло не так и более лучше подготовиться к следующей попытке миграции.

Материалы по теме с советами по миграции:
https://mariadb.com/kb/en/mariadb/upgrading-from-m...
https://mariadb.com/kb/en/mariadb/moving-to-mariadb/
https://mariadb.com/blog/how-migrate-mysql-mariadb...
https://www.digitalocean.com/community/tutorials/s...

Касательно оптимизации:

Часто производительность упирается в архитектуру приложения, а не в использование конкретной технологии.

Например, хорошей идеей будет освоить индексы для тяжёлых запросов.
Примеры, по какому принципу выбирать колонки для индексирования:
ruhighload.com/post/%D0%9A%D0%B0%D0%BA+%D0%BF%D1%8...
ruhighload.com/index.php/2009/06/09/%D0%BA%D0%B0%D...
ruhighload.com/post/%D0%A0%D0%B0%D0%B1%D0%BE%D1%82...