Чтобы добавлять сообщения и комментарии, .

@AlexVK:
AlexVK

В 24 fedora своеобразный скрипт для первоначального развёртывания mariadb.
Если в конфиге log-error не задан, то он его создаёт в $datadir (/var/lib/mysql по умолчанию)
Затем проверяет пустой ли $datadir и ругается — "не могу создать, т.к. не пустой".
Если же log-error указать (/var/log/mariadb например) то стартует нормально.
Но сперва не очень понятно почему оно не стартует.

@OCTAGRAM:
OCTAGRAM

About SphinxSE in MariaDB
Любопытный способ сделать поддержку Sphinx в LAMP проектах. Там ещё и JOIN можно делать.

@Dimez:
Dimez

optimize table table_name;Stage: 1 of 2 'altering table' 550% of stage done

@OCTAGRAM:
OCTAGRAM

MariaDB Debian Wheezy
Ставлю MySQL на ещё одну тачку. По привычке начал делать apt-get install mysql-server, но тут вспомнил, что после покупки Sun Oracle'ом из–за недружественной к сообществу политики Oracle надо бы переходить на нечто более дружественное, как я уже сделал, перейдя на LibreOffice вместо OpenOffice.org, и в данном случае надо бы ставить вместо MySQL MariaDB, которого, правда, в пакетах не оказалось. Попробовав разные дополнительные deb–репозитории, нашёл рабочий вариант для Debian 7 Wheezy.

@Balancer:
Balancer

Своеобразное первое крещение огнём. 6 дней назад отвалилась master-master MySQL репликация на вторичный сервер. Посколько он не используется, а я на выходных мотался на свадьбу к родственникам, то заметил это только вчера. Отставание от мастера превышало 400000+ секунд (5 суток), а время хранения бин-логов на сервере — 3 суток. Классическое решение в этом случае — mysqldump (или percona xtrabackup, что не сильно лучше и много сложнее) и возобновление репликации.

Поступил иначе. Возобновил репликацию с начала первого доступного файла бинлога, и провёл синхронизацию проблемных (по целостности внешних ключей) данных через pt-table-sync. Всё решилось онлайн, без простоев :)

@Balancer:
Balancer

Пришёл к идее, что, если удастся нормально настроить под MariaDB произвольную мастер-мастер репликацию индивидуальных БД (т.е. разные БД — на разные сервера), то надо нафиг выносить MariaDB из контейнеров («в каждом своя») на хост. Достало оверхедить памятью :)

@rakoth:
rakoth

sql> TRUNCATE user_data
[2014-10-20 01:43:04] Cancelling...
[2014-10-20 01:43:04] [70100][1317] Query execution was interrupted
Statement cancelled due to client request
sql> DELETE FROM user_data
23 row(s) affected in 72 ms

Truncate пришлось отменить — задумался очень надолго. Затем банальное удаление пролетело нараз.

SELECT COUNT(*) FROM user_data;
23

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

@Balancer:
Balancer

И хотя я планирую активно перелезать в облака с контейнерами, на новый домашний сервер поставить не CoreOS, как планировал а Ubuntu Cloud Server. Те же уши, но решение проверенное уже многими и за долгий срок. Кстати, первая моя установка Ubuntu на свою серверную железку :D До этого на своих была всегда Gentoo, а Ubuntu была на чужих (Hetzner и DigitalOcean).

Ubuntu Server взывала странные чувства. Репозитории сетевые не подключила, только CD-ROM. После перезапуска даже nano не было установлено. Хотя полтора гига сожрало. Доустановил nano с диска (т.е. с USB-флешки), прописал репы, обновился, поставил mc — жить можно, дальше всё как привычно :D

Хотел было MariaDB воткнуть в Docker и организовать персистентное хранилище, а потом подумал — а нафига? Всё равно ресурсов будет жрать столько, что больше одного инстанса ставить смысла мало, проще на хосте и поставить (привет CoreOS, там так не сделать) и уже оттуда пользоваться всем, кому нужно. Тем более, что, как я понял, в MariaDB сделали возможность репликации разных баз на разные сервера (единственная для меня причина по которой тяжёлый MySQL имело смысл ставить в нескольких инстансах в контейнерах).

Да и обновляться так будет проще.

Вообще, вопрос обновления — самый больной для Docker. Не рассчитан он на обновления :-/ Каждый раз придётся взвешивать тщательно, что приоритетнее, лёгкое разворачивание и автономность или поддержка/обновления.

@zoonman:
zoonman

Пытаюсь подружить Машку и Руби под соусом мак-портов. Пока получился такой монстр philmms:RubymineProjects zoonman$ sudo gem install --no-rdoc --no-ri mysql2 — --with-mysql-dir=/opt/local/lib/mariadb --with-mysql-config=/opt/local/lib/mariadb/bin/mysql_config --with-mysql-include=/opt/local/include/mariadb/mysql --with-mysql-lib=/opt/local/lib/mariadb/mysql
Building native extensions with: '--with-mysql-dir=/opt/local/lib/mariadb --with-mysql-config=/opt/local/lib/mariadb/bin/mysql_config --with-mysql-include=/opt/local/include/mariadb/mysql --with-mysql-lib=/opt/local/lib/mariadb/mysql' надеюсь оно будет работать.

@Balancer:
Balancer

Сегодня рискнул обновить свой последний MySQL на MariaDB на самой жирной БД (/var/lib/mysql на 37Гб). Кажется, больше MySQL нигде не осталось :) Пойду теперь разбираться с мастер-мастер репликацией, чтобы больше не городить мастер-мастер кольца.

@Sectoid:
Sectoid

Вопрос к дебианщикам: есть неизвратный способ запускать несколько instance'ов MariaDB под Debian? Неизвратный == без создания 100500 init-скриптов и более/менее нормально вписывающийся в существующую систему debian-скриптов.

Вопрос достаточно важный, потому рекоменд приветствуется.

@Ta2i4:
Ta2i4

Я смотрю, многие переходят с MySQL на MariaDB. А что там такого интересного, кроме ее открытости?

@ufm:
ufm

О как.
Если написать

create procedure insert_gws(in a INT, in b INT)
begin
insert into n set `aa`=a, `bb`=b;
end$$

CREATE TRIGGER `n_BINS` BEFORE INSERT ON `n` FOR EACH ROW
begin
...
end$$

То при вызове insert_gws триггер срабатывать не будет.
А если наоборот, сначала объявить триггер а потом процедуру — будет.
Это так и задумано, и я просто недопонимаю тайную логику?

@partizan:
partizan

лол, смотрю на Incompatibilities between MariaDB 5.1 and MySQL 5.1
— The installation package names starts with MariaDB instead of MySQL.
— Timings may be different as MariaDB is in many cases faster than MySQL.

@stanislavv:
stanislavv

Попытка апгрейда 5.2->5.5 не удалась.
Получили OOM на 24Гб памяти.

@zoonman:
zoonman

У кого есть опыт с проблемами по I/O в MySQL, порекомендуйте на чем остановиться, второтег или третьетег? Первотег тормозит. Таблицы InnoDB, похоже на highload, ~200 q/s. wa 10-20%. ~10 мегазаписей переписываются раз в час. База около 2 GB. Частые и массивные INSERT's. Софтверный RAID прилично тупит. Есть идея уговорить начальство мигрировать на железный RAID и SAS, переехать на Percona XTRADB. Пишут, что лучше. У кого есть реальный опыт?

@netneladno:
netneladno

How does optimizer work with the different Join Algorithms available?Currently, the part of the optimizer that is responsible for choosing the join algorithm for a particular query and QEP is not advanced enough and there is work to be done yet. As I understand it MariaDB folks are working on the cost-based choice for any joins. It’s not easy because the current costing model is primitive and must be enhanced to support the possibility of existence of different join algorithms. So what does that mean to MariaDB/MySQL users right now with the state of the current optimizer. Right now you would have to manually enable and disable the join algorithms for the optimizer to choose from.
In MariaDB, every algorithm has a number given to it:
1 – flat BNL
2 – incremental BNL
3 – flat BNLH
4 – incremental BNLH
5 – flat BKA
6 – incremental BKA
7 – flat BKAH
8 – incremental BKAHThe variable join_cache_level controls which algorithms are enabled. If join_cache_level=4 all algorithms numbered 1 to 4 are enabled, if join_cache_level=8, all algorithms numbered 1 to 8 are enabled. Optimizer is naive in the sense that it always uses the max values join algorithm. If join_cache_level=4 it always uses BNLH (hash join), if join_cache_level=8 it always uses BKAH (a variant of BKA). Optimizer does not try to check which algorithm is the best one to use, it just assumes that the algorithm with the highest numeric value is the best one.
So we can force the join algorithm used by setting appropriate values of “join_cache_level”. For example in my test I forced the optimizer to use hash join by setting join_cache_level=4. We can set certain rules for which certain join algorithms are best and then use that algorithm by making use of the variable “join_cache_level”.

@Jacaranda:
Jacaranda

Ох уж эти хитрые оптимизаторы запросов в базах данных. Дядя монти жжот, Мария 5.3 абалденно класно оптимизирует join.

@mikola:
mikola

#MariaDB 5.2.7 released goo.gl