Размещаем MySQL на RAW-партиции

Пока вы используете MySQL как записную книжку (именно так ее использует большинство web-проектов), вы никогда не столкнетесь с проблемой производительности СУБД. По-своему опыту могу сказать, что MySQL не лучший выбор для высоконагруженных баз данных. Причин много: частые deadlock’и, отсутствие хороших механизмов репликации, низкая производительность. Если у вас есть возможность выбора - выбирайте PostgreSQL или Oracle, если вам нужны именно реляционные базы данных. Но если у вас есть уже готовые решения с использованием MySQL, а миграция на другую СУБД невозможно или слишком трудо\экономически затратна, то придется оптимизировать и настраивать “записную книжку”. Сегодня речь пойдет о переносе InnoDB таблиц на отдельную raw-партицию.

Прежде, чем оптимизировать сервер базы данных, нужно понять, какого характера нагрузка присутствует. Я выделяю три типа нагрузки: нагрузка на чтение, нагрузка на запись, смешанная нагрузка. Если у вас нагрузка на чтение - следует повышать объемы оперативной памяти и процессорную мощность. А вот если у вас нагрузка на запись или смешанная - одной памятью и процессором уже не обойтись!

Первое, что нужно сделать - вынести все файлы, используемые базой данных на отдельную партицию, отличную от системной. Этим мы исключим конкурентный доступ к дисковой подсистеме. Исключим? Не совсем... MySQL помимо файлов самих баз дынных использует бинарные логи операций с базами. Отключать их ни в коем случае нельзя, иначе вы рискуете потерять данные в результате сбоя СУБД. Что же остается? Разнести файлы баз данных и логи на разные партиции!

Но просто расположить файлы базы данных на отдельный раздел - это плохо, т.к. файловая система на разделе будет лишним (тормозящим) звеном! Но возрадуемся, дорогие читатели, у MySQL есть raw-партиции для InnoDB-механизмов хранения данных! Для начала советую прочитать статью на официальном сайте. Проблема в том, что статья написана в стиле “возьми пирожок и отстань от дядьки!”. Когда я ее прочитал, у меня возникли сразу следующие вопросы: что можно считать raw-партициями? умеет ли MySQL инициализировать raw-партицию по мере востребованности? как перенести данные на raw-партицию?

Теперь о всем по порядку. В современных операционных системах в качестве raw-партиции можно использовать любой раздел диска, просто достаточно указать путь к разделу. Раньше, для этого нужно было “городить огород” из драйверов.

Вы прочитали материал по вышеупомянутой ссылку? Вот что это за синтаксис (и что это за цифры столетней давности о_О)?

[mysqld]

innodb_data_home_dir=

innodb_data_file_path=/dev/hdd1:3Gnewraw;/dev/hdd2:2Gnewraw

Мы с Вячеславом решили провести эксперимент. Для начала мы запустили СУБД с такой конфигурацией:

innodb_data_file_path=/dev/md0:100Mnewraw

после чего попытались залить дамп базы объемом более 100Мб. Итог - импорт вывалился с сообщением об ошибке: innodb хранилище заполнилось. Не помог даже перезапуск сервера с параметром autoextend (на самом деле мы не могли представить, как с таким синтаксисом его можно куда-то добавить: потыкались - MySQL не завелся). Итого, нужно сразу указывать необходимый объем партиции. При этом, если вы укажите объем превышающий объем raw-партиции, вы получите следующее сообщение об ошибке:

285000 285100 285200 285300 285400 285500 285600 285700 285800 285900

286000 286100110413 12:49:42  InnoDB: Error: Write to file /dev/md0

failed at offset 69 3721396224.

InnoDB: 1048576 bytes should have been written, only 262144 were written.

InnoDB: Operating system error number 22.

InnoDB: Check that your OS and file system support files of this size.

InnoDB: Check also that the disk is not full or a disk quota exceeded.

InnoDB: Error number 22 means 'Invalid argument'.

InnoDB: Some operating system error numbers are described at

InnoDB: http://dev.mysql.com/doc/refman/5.1/en/operating-system-error-codes.html

InnoDB: Error in creating /dev/md0: probably out of disk space

InnoDB: Could not open or create data files.

InnoDB: If you tried to add new data files, and it failed here,

InnoDB: you should now edit innodb_data_file_path in my.cnf back

InnoDB: to what it was, and remove the new ibdata files InnoDB created

InnoDB: in this failed attempt. InnoDB only wrote those files full of

InnoDB: zeros, but did not yet use them in any way. But be careful: do not

InnoDB: remove old data files which contain your precious data!

110413 12:49:42 [ERROR] Plugin 'InnoDB' init function returned error.

110413 12:49:42 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.

110413 12:49:42 [ERROR] Unknown/unsupported table type: INNODB

110413 12:49:42 [ERROR] Aborting

110413 12:49:42 [Note] mysqld: Shutdown complete

бобик сдох... Самое верное - указать размер, превышающий фактический, запустить демона MySQL из командой строки (чтобы он писал все сообщения в консоль) и посмотреть, на каком объеме произойдет ошибка инициализации. Этот объем впишите в файл конфигурации.

На третий вопрос отвечу кратко: делаете дамп предыдущей базы и, после перехода на использование raw-партиции, заливаете ее обратно.

Если вы думаете, что все так просто, вы ошибаетесь! Когда вы будете все это настраивать, пред вами сразу всплывет догадайтесь что? Правильно! Наши любимые подводные грабли! Я настраивал сервер на Ubuntu, поэтому у меня грабли имели вид AppArmor! AppArmor, так же как и SELinux помогает добавить “безопасности” (читать “гемороя”) на ваш сервер. Для того, чтобы MySQL смог обращаться к raw-партиции следует добавить следующую строчку в файл /etc/apparmor.d/usr.sbin.mysqld:

/dev/md0 rwk

Но и это еще не все, т.к. для доступа к устройству нужны права root, либо состоять в группе disk. Ни первого, ни второго mysql-демон не имеет. В интернете любят извращения и добавляют в UDEV политику доступа к raw-партиции для MySQL. По-моему, проще добавить пользователя mysql в группу disk.

Вот и весь тюнинг! Теперь ваш сервер MySQL работает на raw-партиции. Но помните, самый лучший способ оптимизировать MySQL - отказаться от MySQL! ;-)

«Данный материал написан для «Первого конкурса русскоязычных статей для ОС Ubuntu 2011 года» (konkurs.ubuntu.ru)».