Очистка, оптимизация, настройка mysql базы zabbix

Распространенные варианты использования дампа и восстановления

Вы можете использовать такие служебные программы MySQL, как mysqldump и mysqlpump, для дампа и загрузки баз данных в Базу данных Azure для сервера MariaDB в нескольких распространенных сценариях.

• Используйте дампы базы данных при перемещении всей базы данных. Мы рекомендуем использовать этот способ при перемещении большого количества данных MariaDB, или если вы не хотите прерывать работу службы для динамичных сайтов или приложений.

• Убедитесь, что все таблицы в базе данных используют подсистему хранилища InnoDB при загрузке данных в Базу данных Azure для MariaDB. База данных Azure для MariaDB поддерживает только подсистему хранилища InnoDB. Другие подсистемы хранилища не поддерживаются. Если таблицы настроены с помощью других подсистем хранилища, преобразуйте их в формат ядра InnoDB перед перемещением в Базу данных Azure для MariaDB.

  Например, при наличии приложения WordPress или веб-приложения, которое использует таблицы MyISAM, перед восстановлением в Базе данных для MariaDB сначала преобразуйте эти таблицы в формат InnoDB путем перемещения. Используйте предложение , чтобы задать ядро, используемое для создания таблицы, а затем передайте данные в совместимую таблицу перед восстановлением.

• Чтобы избежать проблем с совместимостью, при выполнении дампа баз данных в системах источника и назначения должна использоваться одна версия MariaDB. Например, если вы используете существующий сервер MariaDB версии 10.2, вы должны выполнить перемещение в Базу данных Azure для MariaDB, настроенную на запуск версии 10.2. Команда не будет работать в Базе данных Azure для сервера MariaDB и является неподдерживаемой. Если вам необходимо обновить все версии MariaDB, используйте сначала дамп или экспорт базы данных ранней версии, чтобы получить наиболее актуальную версию MariaDB в собственном окружении. Затем перед выполнением перемещения в Базу данных Azure для MariaDB запустите .

MySQL InnoDB, MyISAM etc.

Краткое описание современных движков хранения данных в MySQL — совместимых СУБД.

InnoDB — основной движок для MySQL, который с версии 5.5 стал дефолтным. Поддерживает транзакции, репликацию, построчную блокировку. В отличие от таблиц MyISAM, где для каждой таблицы создается один файл данных, данные InnoDB в настройках по умолчанию хранятся в больших совместно используемых файлах. То есть данные для всех таблиц и всех баз данных хранятся в одном файле, изменить это можно с помощью настроек опции innodb_file_per_table (Как включить MySQL innodb_file_per_table?).

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

• MyISAM — не поддерживает транзакции и внешние связи (foreign key), но зато может похвастаться полнотекстовыми индексами и быстротой вставки данных. На Select запросах MyISAM медленнее, чем InnoDB. Долгое время был стандартным для всех версий MySQL, а потому до сих пор является самым популярным.
• MERGE — MyISAM движок для разнесения данных в одной таблице на несколько разных.
• CVS — специализированный движок на случай, когда требуется хранить и обрабатывать большие массивы строковых данных, разделяемых запятой. Данные можно править обычным текстовым редактором.
• MEMORY — движок, использующийся для хранения данных не на диске, а в памяти. Информация из базы доступна только во время работы сервера, но это дает колоссальный прирост в производительности.
• Federated/FederatedX — этот движок специализируется на прозрачном разнесении данных по нескольким серверам (физическим) на уровне таблицы.
• PBXT — призванный заменить InnoDB новый движок, в котором реализованы полная поддержка транзакций, многоверсионность, автоматическая обработка дедлоков. Движок оптимизирован для большого количества одновременных транзакций.
• Blackhole — служебный движок, представляющий собой, по сути, /dev/null для СУБД и фактически не производящий никаких записей на диск. Используется для репликации.
• Archive — используется в тех случаях, когда необходимо хранить большие массивы данных без изменений. Для эффективности хранения используется сжатие, что приводит к медлительности во время выборок. Движок хорошо подходит для долговременного хранения логов и другой служебной информации.
• XtraDB — расширенная и исправленная в некоторых проблемных местах InnoDB от компании Percona.
• BlitzDB — еще одна замена для MyISAM с хорошей производительностью за счет встроенного построчного кэширования и автоматического восстановления после сбоев. Движок не поддерживает транзакции.
• NDB — движок для кластера, обладающий, впрочем, кучей проблем и удручающе плохой производительностью.
• Falcon — легендарный движок от компании MySQL AB, разрабатываемый еще со времен Sun, когда было принято решение заменить оракловский InnoDB.
• SphinxSE — полнотекстовый движок от создателя поискового сервера Sphinx. Лучший вариант для полнотекстового поиска и индексации по правилам русского языка. Легко оперирует терабайтами данных, обеспечивая при этом все возможности современной БД.
• Aria — замена для MyISAM с поддержкой транзакций и улучшенной работой с памятью. Движок гарантирует целостность данных и при этом не уступает в скорости MyISAM.
• BDB(BerkeleyDB) — для совместимости с BerkeleyDB.

Общие настройки

max_connections=64 — устанавливаем параметр минимальным возможным при необходимости экономить ресурсы сервера, при возникновении в логе записей вида «Too many connections…» увеличиваем значение. Не следует изменять значение этого параметра на старте. 4000 клиентов является максимумом. Можно довести максимальное количество клиентов до 7000, но для стандартных сборок 4000 является пределом.

open_files_limit = 2048 Устанавливать значение стоит опираясь на существующее количество открытых файлов MySQL:

В конфигурационном файле задается большее значение.

connect_timeout (MySQL pre-5.1.23: default 5, MySQL 5.1.23+: default 10) — количество секунд по прошествии которых сервер баз данных будет выдавать ошибку, при активном веб-сервере значение можно уменьшать чтобы увеличить скорость работы, на медленной машине — можно увеличивать. max_connect_errors (default 10) — максимальное количество единовременных соединений с сервером баз данных с хоста запрос блокируется если он прерывается запросами с того же хоста до момента окончания обработки запроса) блокируются навсегда, очистить можно только из командной оболочки MySQL:

В случае атаки на сервер нужно уменьшать (5) чтобы отсекать попытки соединения, при большой активности веб-сервера можно увеличивать max_allowed_packet (default 1M) — максимальный для буфера соединений и буфера результата при исполнении SQL инструкций. Каждый тред имеет свой буфер. Хорошим значением для начала будет 16М. tmp_table_size (system-specific default) — максимальный размер памяти выделяемой под хранение временных таблиц. 16М — довольно много.

Примеры готовых конфигураций для разных объёмов памяти можно посмотреть здесь.

Чтобы посомореть значения переменных можно воспользоваться SQL запросом:

или для конкретных переменных:

Чтобы проверить мониториг InnoDB, используте:

Чтобы узнать, не свопается ли память, используйте команду и смотрите строку swap:

#1. Модификация файла my.cnf

Файл содержит все необходимые параметры для работы MySQL. На него смотрим в первую очередь. 

Если сидите на Linux, файл можно найти в одном из каталогов:

Если используете Windows, поищите my.cnf в каталоге .

— это версия вашего сервера MySQL.

Откройте файл и найдите параметры запуска InnoDB:

Все эти переменные связаны с InnoDB — одной из подсистем низкого уровня в СУБД MySQL, которая входит в стандартные сборки для разных ОС. Далее мы будем говорить про команды InnoDB. Скорее всего, вы используете именно этот движок, так как он дефолтный и самый быстрый из всех известных. 

Настройка параметров my.cnf

Здесь нам понадобятся данные объёма доступной оперативной памяти и места на жёстком диске, которые мы определяли в самом начале.

Параметр показывает размер памяти для кэширования данных и индексов таблиц InnoDB. Он должен составлять 50–60% от доступной оперативной памяти. Чем параметр больше, тем больше данных будет кэшироваться, и вставка данных будет происходить быстрее.

Значение определяет путь, по которому хранится файл . Это основной файл, связанный с InnoDB, где располагаются все необходимые данные. Увеличьте размер переменной , чтобы она могла вместить все данные MySQL, — например, до 5–10 ГБ.

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

Настройка определяет, как сбрасываются данные на диск. Значение по умолчанию означает, что каждая транзакция должна сбрасывать буфер на диск. Это достаточно ресурсоёмко, зато соответствует требованиям ACID и безопасно. 

Параметр определяет метод записи данных из памяти на диск. Его модификация может привести к неожиданным и непредсказуемым последствиям, поэтому после изменений лучше проводить бенчмарки (тесты скорости). Самое распространенное решение — оставить параметр в значении . Это предотвратит двойную буферизацию, когда данные одновременно кэшируются и самой ОС, и InnoDB.

Настройка параметров значительно оптимизирует производительность MySQL, даже если ваш сервер имеет ограниченный объем оперативной памяти и места для хранения.

Как спланировать нагрузку на Zabbix

Под небольшой структурой, упомянутой в начале, я подразумеваю 50-100 узлов (не сетевое оборудование с десятками портов) сети на мониторинге и примерно 2000-4000 активных элементов данных, которые записывают 20-40 новых значений в секунду. Под такую сеть вам будет достаточно небольшой виртуальной машины с 2 ядрами и 4 гб памяти. База данных на преимущественно стандартных шаблонах будет расти примерно на 2-4 Гб в год. Дальше еще меньше, так как будет автоматически очищаться.

Для мониторинга такой сети можно вообще не выполнять никаких дополнительных настроек. Мониторинг будет вполне нормально работать. Если же нагрузка начнет расти, то первое, с чем вы столкнетесь — это с размером и производительностью базы данных. База zabbix будет расти пропорционально подключению к ней хостов. И с этим придется что-то делать.

Для решения вопроса производительности нужно будет двигаться в двух направлениях:

1. Очистка базы от ненужных данных.
2. Увеличение производительности сервера mysql.

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

5 ответов

• 122 рейтинг

  MySQL не уменьшает размер ibdata1. Когда-либо. Даже если вы используете , чтобы освободить место, используемое для удаленных записей, он будет использовать его позже.

  Альтернативой является настройка сервера на использование , но для этого потребуется создать резервную копию, удалить базу данных и восстановить. Положительной стороной является то, что. ibd файл для таблицы уменьшается после .

  ответ дан Leonel Martins, с репутацией 2205, 14.08.2009

• 31 рейтинг

  Просто у меня была такая же проблема.

  Что происходит, так это то, что даже если вы удалите базу данных, innodb все равно не освободит дисковое пространство. Мне пришлось экспортировать, остановить MySQL, удалить файлы вручную, запустить MySQL, создать базу данных и пользователей, а затем импортировать. Слава богу, у меня было только 200 МБ строк, но это сэкономило 250 ГБ файла innodb.

  Сбой по замыслу.

  ответ дан gilm, с репутацией 3870, 25.12.2009

• 21 рейтинг

  Если вы не используете innodb_file_per_table , восстановление дискового пространства возможно, но довольно утомительно и требует значительных простоев.

  How To довольно глубокий — но я вставил соответствующую часть ниже.

  Обязательно сохраните копию вашей схемы в вашем дампе.

  ответ дан FlipMcF, с репутацией 9090, 19.01.2012

• 0 рейтинг

  Другой способ решить проблему восстановления пространства — создать несколько разделов в таблице — на основе диапазона, на основе значения — разделы и просто удалить / усечь раздел, чтобы освободить пространство, которое освободит пространство, используемое целыми данными, хранящимися в конкретном разделе ,

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

  ответ дан Anand Immannavar, с репутацией 179, 10.02.2015

• -1 рейтинг

  Есть несколько способов восстановить дисковое пространство после удаления данных из таблицы для движка MySQL Inodb

  Если вы не используете innodb_file_per_table с самого начала, дамп всех данных, удаление всех файлов, воссоздание базы данных и повторный импорт данных — это единственный способ (проверьте ответы FlipMcF выше)

  Если вы используете innodb_file_per_table, вы можете попробовать

  1. Если вы можете удалить все данные, команда truncate удалит данные и освободит место на диске для вас.
  2. Команда «Изменить таблицу» удалит и заново создаст таблицу, чтобы можно было восстановить дисковое пространство. Поэтому после удаления данных выполните команду alter table, которая ничего не меняет, чтобы освободить жесткий диск (т. Е. У таблицы TBL_A есть кодировка uf8, после удаления данных запустите ALTER TABLE TBL_A charset utf8 — & gt; эта команда ничего не меняет в вашей таблице, но она заставляет mysql воссоздать вашу таблицу восстановить дисковое пространство
  3. Создайте TBL_B как TBL_A. Вставьте выбранные данные, которые вы хотите сохранить из TBL_A в TBL_B. Удалите TBL_A и переименуйте TBL_B в TBL_A. Этот способ очень эффективен, если TBL_A и данные, которые нужно удалить, большие (команда удаления в MySQL innodb очень плохая производительность)

  ответ дан Khánh Bùi Đức, с репутацией 661, 25.04.2016

Поддержка движков хранения данных

Система управления базами данных MariaDB поддерживает намного больше движков для хранения данных. Большинство этих движков доступны в качестве плагинов для MySQL, но в MariaDB они включены в официальный релиз. Это означает, что движки правильно интегрированы и будут хорошо работать. Вот список поддерживаемых движков:

• Aria;
• XtraDB — улучшенная версия InnoDB;
• FederatedX — улучшенная версия Federated;
• OQGRAPH;
• SphinxSE;
• IBMDB2I;
• TokuDB;
• Cassandra;
• CONNECT;
• SEQUENCE;
• Spider;
• ColumnStore;
• MySIAM.

Напомню, что оригинальная MySQL поддерживает по умолчанию только три типа таблиц — Aria, MySIAM и InnoDB. Это важный аспект в выборе MySQL или MariaDB.

Очистка и уменьшение mysql базы zabbix

Начнем с очистки базы данных zabbix от ненужных данных. Рассмотрим по пунктам в той последовательности, в которой это нужно делать.

1. Первым делом надо внимательно просмотреть все используемые шаблоны и отключить там все, что вам не нужно. Например, если вам не нужен мониторинг сетевых соединений windows, обязательно отключите автообнаружение сетевых интерфейсов. Оно само по себе находит десятки виртуальных соединений, которые возвращают нули при опросе и не представляют никакой ценности. Тем не менее, все эти данные собираются и хранятся, создавая лишнюю нагрузку. Если же вам нужен мониторинг сети в windows, зайдите в  каждый хост и отключите руками лишние адаптеры, которые будут найдены. Этим вы существенно уменьшите нагрузку. По моему опыту, в стандартных шаблонах windows мониторинг всех сетевых интерфейсов дает примерно 2/3 всей нагрузки этих шаблонов.
2. Отредактируйте в используемых стандартных шаблонах время опроса и хранения данных. Возможно вам не нужна та частота опроса и время хранения, которые заданы. Там достаточно большие интервалы хранения. Чаще всего их можно уменьшить. В целом, не забывайте в своих шаблонах ставить адекватные реальной необходимости параметры. Не нужно хранить годами информацию, которая теряет актуальность уже через неделю.
3. После отключения лишних элементов в шаблонах, нужно очистить базу данных от значений неактивных итемов. По-умолчанию, они там остаются. Можно их очистить через web интерфейс, но это плохая идея, так как неудобно и очень долго. Чаще всего попытки очистить 50-100 элементов за раз будут сопровождаться ошибками таймаута или зависанием web интерфейса. Далее расскажу, как это сделать эффективнее.

Для очистки базы данных zabbix от значений неактивных итемов, можно воспользоваться следующими запросами. Запускать их можно как в консоли mysql сервера (максимально быстрый вариант), так и в phpmyadmin, кому как удобнее.

Данными запросами можно прикинуть, сколько данных будет очищено:

SELECT count(itemid) AS history FROM history WHERE itemid NOT IN (SELECT itemid FROM items WHERE status='0');
SELECT count(itemid) AS history_uint FROM history_uint WHERE itemid NOT IN (SELECT itemid FROM items WHERE status='0');
SELECT count(itemid) AS history_str FROM history_str WHERE itemid NOT IN (SELECT itemid FROM items WHERE status='0');
SELECT count(itemid) AS history_text FROM history_text WHERE itemid NOT IN (SELECT itemid FROM items WHERE status='0');
SELECT count(itemid) AS history_log FROM history_log WHERE itemid NOT IN (SELECT itemid FROM items WHERE status='0');
SELECT count(itemid) AS trends FROM trends WHERE itemid NOT IN (SELECT itemid FROM items WHERE status='0');
SELECT count(itemid) AS trends_uint FROM trends_uint WHERE itemid NOT IN (SELECT itemid FROM items WHERE status='0');

Если запросы нормально отрабатывают и возвращают счетчик данных, которые будут удалены, дальше можете их удалять из базы следующими sql запросами.

DELETE FROM history WHERE itemid NOT IN (SELECT itemid FROM items WHERE status='0');
DELETE FROM history_uint WHERE itemid NOT IN (SELECT itemid FROM items WHERE status='0');
DELETE FROM history_str WHERE itemid NOT IN (SELECT itemid FROM items WHERE status='0');
DELETE FROM history_text WHERE itemid NOT IN (SELECT itemid FROM items WHERE status='0');
DELETE FROM history_log WHERE itemid NOT IN (SELECT itemid FROM items WHERE status='0');
DELETE FROM trends WHERE itemid NOT IN (SELECT itemid FROM items WHERE status='0');
DELETE FROM trends_uint WHERE itemid NOT IN (SELECT itemid FROM items WHERE status='0');

Данными запросами вы очистите базу данных zabbix от значений неактивных элементов данных. Но реально размер базы данных у вас не уменьшится, потому что в дефолтной настройке базы данных используется формат innodb. Все данные хранятся в файле ibdata1, который автоматически не очищается после удаления данных из базы.

Администрировать такую базу неудобно. Нужно как минимум настроить хранение каждой таблицы в отдельном файле. Этим мы далее и займемся, а заодно обновим сервер базы данных до свежей версии mariadb и реально очистим базу, уменьшив ее размер.

Find and Remove Unused Indexes

A general rule of thumb is that the more indexes you have on a table, the slower , , and operations will be and more disk space will be consumed. It is essential to track down unused indexes that consume disk space and slow down your database.

By default, statistics are not collected. This is to ensure that statistics collection does not cause any extra load on the server unless desired.

To enable statistics dynamically execute the following command :

SET GLOBAL userstat=1;

Now, every query to the database updates the statistic tables. The and are the most interesting tables. The first table shows the number of rows reads from the table and the number of rows changed in the table. The second table shows statistics on index usage.

SELECT * FROM INFORMATION_SCHEMA.TABLE_STATISTICS;
+--------------+------------------------+-----------+--------------+------------------------+
| TABLE_SCHEMA | TABLE_NAME             | ROWS_READ | ROWS_CHANGED | ROWS_CHANGED_X_INDEXES |
+--------------+------------------------+-----------+--------------+------------------------+
| hope         | eth_table1             |      1004 |            0 |                      0 |
| hope         | eth_table2             |  14343683 |            0 |                      0 |
| hope         | eth_table3             |      1002 |            0 |                      0 |
+--------------+------------------------+-----------+--------------+------------------------+

SELECT * FROM INDEX_STATISTICS;
+--------------+-------------------+------------+-----------+
| TABLE_SCHEMA | TABLE_NAME        | INDEX_NAME | ROWS_READ |
+--------------+-------------------+------------+-----------+
| hope         | eth_table1        | PRIMARY    |         2 |
| hope         | eth_table2        | PRIMARY    |         4 |
+--------------+-------------------+------------+-----------+

With the help of the new tables, you can find all unused indexes in a single query.

SELECT DISTINCT s.TABLE_SCHEMA, s.TABLE_NAME, s.INDEX_NAME
FROM information_schema.statistics `s` LEFT JOIN information_schema.index_statistics INDXS
ON (s.TABLE_SCHEMA = INDXS.TABLE_SCHEMA AND
   s.TABLE_NAME=INDXS.TABLE_NAME AND
   s.INDEX_NAME=INDXS.INDEX_NAME)
WHERE INDXS.TABLE_SCHEMA IS NULL;

Finally, to delete index run this command in  client :

DROP INDEX index_name ON table_name;

Do not forget to set when statistics are not required anymore.

Настройка сайта

Настройку начнем с того, что завершим конфигурацию Nginx для работы с PHP-FPM. Для этого изменим конфигурационный файл сайта /etc/nginx/conf.d/${WEBSITE_NAME}.conf.

Добавим перед секцией server следующий фрагмент конфигурации, который задает способ связи с PHP-FPM:

upstream php {
        server unix:/var/run/php72-fpm.sock;
}

# то, что ниже не добавлять в настройку, 
# приведено для примера куда вставить секцию
# upstream
#
server {
        listen 443 ssl;
        listen :443 ssl;

...

Удалим следующие строки конфигурации:

       index index.html;

       location / {
                try_files $uri $uri/ =404;
       }

Добавим следующие строки конфигурации вместо них:

        access_log /var/log/nginx/access.log;
        error_log /var/log/nginx/error.log;

        index index.php;

        location = /favicon.ico {
                log_not_found off;
                access_log off;
        }

        location = /robots.txt {
                allow all;
                log_not_found off;
                access_log off;
        }

        location / {
                try_files $uri $uri/ /index.php?$args;
        }

        location ~ .php$ {
                include fastcgi.conf;
                fastcgi_intercept_errors on;
                fastcgi_pass php;
        }

        location ~* .(js|css|png|jpg|jpeg|gif|ico)$ {
                expires max;
                log_not_found off;
        }

Пример полной конфигурации:

server {
    if ($host = website.com) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


        listen 80;
        listen :80;
        server_name website.com;


}

upstream php {
        server unix:/var/run/php72-fpm.sock;
}

server {
	listen 443 ssl;
	listen :443 ssl;

	server_name website.com;

	root /var/www/website.com;

        ssl_certificate /etc/letsencrypt/live/website.com/fullchain.pem; # managed by Certbot
        ssl_certificate_key /etc/letsencrypt/live/website.com/privkey.pem; # managed by Certbot

        access_log /var/log/nginx/access.log;
        error_log /var/log/nginx/error.log;

        index index.php;

        location = /favicon.ico {
                log_not_found off;
                access_log off;
        }

        location = /robots.txt {
                allow all;
                log_not_found off;
                access_log off;
        }

        location / {
                try_files $uri $uri/ /index.php?$args;
        }

        location ~ .php$ {
                include fastcgi.conf;
                fastcgi_intercept_errors on;
                fastcgi_pass php;
        }

        location ~* .(js|css|png|jpg|jpeg|gif|ico)$ {
                expires max;
                log_not_found off;
        }
}

Проверим корректность настроек Nginx и перезапустим его:

sudo nginx -t && sudo systemctl restart nginx

Убедимся, что PHP-скрипты работают корректно. Для этого создадим файл index.php в пути /var/www/$WEBSITE_NAME/index.php со следующим содержимым:

<?php 
echo "Hello\n";

Проверим работоспособность скрипта:

# локально
php /var/www/$WEBSITE_NAME/index.php
Hello

# через web
curl https://$WEBSITE_NAME/index.php
Hello

# удалим скрипт
sudo rm /var/www/$WEBSITE_NAME/index.{php,html}

Настройка сервера LEMP завершена. Теперь вы можете выполнить развертывание сайта в каталоге /var/www/$WEBSITE_NAME и начать его использование, открыв в браузере https://$WEBSITE_NAME/.

Делаем выводы

Если ты обеспокоен развитием MySQL, тебе не нравится политика Oracle и ты справедливо опасаешься, что завтра тебя обяжут платить за функционал, который еще вчера был бесплатен, посмотри вокруг. Сообщество отреагировало на покупку MySQL как на начало заката технологии, некогда выведшей современный веб на недостижимую высоту благодаря стеку LAMP (Linux-Apache-MySQL-PHP). Ключевые разработчики начали развитие собственных форков, некоторые из которых уже сейчас на голову превосходят старый MySQL. За ними стоят многие знаковые фигуры и открытое сообщество. Сделав все по уму, разработчики умудрились оставить 100% внешней совместимости с приложениями и протоколами. Поэтому все желающие поставить новый сервер не окажутся у разбитого корыта: данные сохранятся, а приложения не придется переписывать. Многие вообще не заметят разницы, кроме возросшей скорости работы и надежности.

Уже сейчас ты можешь заменить свой сервер баз данных, так что имеющиеся приложения даже не почувствуют разницы, получив при этом гораздо большую скорость работы, надежность и массу недоступных в оригинальном мускуле фишек. MariaDB с набором движков — отличный вариант для старта. Ну а если ты задумал грандиозный проект с большим количеством серверов и гигабайтами данных, посмотри на Drizzle. Как программный продукт и как сервер баз данных он является очень перспективной разработкой, которая обязательно выстрелит уже в этом году. Если же хочется стабильности и поддержки самыми лучшими специалистами по базам данных — не бойся отвернуться от Oracle и пойти к Perconа. Ребята раздают бесплатно свою версию СУБД — исправляя, насколько это возможно, баги и добавляя фичи для увеличения производительности оригинального MySQL, не нарушая при этом совместимости. Ты все еще сидишь на стареньком мускуле? Тогда мы идем к тебе!