URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 64808
[ Назад ]

Исходное сообщение
"Моментальное обновление данных в СУБД MySQL с помощью LVM SN..."

Отправлено opennews , 16-Мрт-10 21:51 
В статье (http://wiki.opennet.ru/MySQL_LVM_Update) представлен вариант решения проблемы  блокировки сервисов извлечения информации при добавлении  больших блоков данных в СУБД MySQL. Проблема решена с помощью моментальных снимков (snapshot) в менеджере томов LVM.

URL: http://wiki.opennet.ru/MySQL_LVM_Update
Новость: http://www.opennet.me/opennews/art.shtml?num=25818


Содержание

Сообщения в этом обсуждении
"Моментальное обновление данных в СУБД MySQL с помощью LVM SN..."
Отправлено funky_dennis , 16-Мрт-10 21:51 
После каждого слова в статье надо писать MyISAM!

"Моментальное обновление данных в СУБД MySQL с помощью LVM SN..."
Отправлено anonymous , 17-Мрт-10 00:46 
обновления в примере один раз в час, значит буферпул с большой долей вероятности будет сброшен на диски.
при желании можно ускорить recovery и уменьшить потерю данных через:
set global innodb_max_dirty_pages_pct=0;

"Моментальное обновление данных в СУБД MySQL с помощью LVM SN..."
Отправлено walrus , 17-Мрт-10 17:25 
И что случится, если использовать такой бэкап с  innodb? то же , что при потере питания машины. Во время восстановления откатятся текущие транзакции. И все.

"Моментальное обновление данных в СУБД MySQL с помощью LVM SN..."
Отправлено wkon , 17-Мрт-10 23:00 
В целом соглашусь с funky_dennis. Действительно, метод работает в случае если та часть БД
с которой выполняется снимок состоит из таблиц MyISAM.
Подкорректирую статью.

"Моментальное обновление данных в СУБД MySQL с помощью LVM SN..."
Отправлено Аноним , 17-Мрт-10 01:37 
К сожалению, "моментальные" снимки LVM не такие-уж и моментальны и, что самое главное, под нагрузкой после снимка все начитает _так_ тормозить
Полноценно такую технику можно использовать "в бою" только на Copy-on-Write файловых системах, например - ZFS.

"Моментальное обновление данных в СУБД MySQL с помощью LVM SN..."
Отправлено Аноним , 17-Мрт-10 11:13 
Ага, только зфс тот еще тормоз....

"Моментальное обновление данных в СУБД MySQL с помощью LVM SN..."
Отправлено ank1812 , 17-Мрт-10 14:04 
zfs реально одна из самых быстрых файловых систем. "просто добавь воды"(памяти).

"Моментальное обновление данных в СУБД MySQL с помощью LVM SN..."
Отправлено Аноним , 17-Мрт-10 14:25 
тора гой, не используй ZFS под vmware и все будет карашо.

если серьзно - ZFS хороша на "родном" Solaris. там она для MySQL - шикарна.


"Моментальное обновление данных в СУБД MySQL с помощью LVM SN..."
Отправлено wkon , 17-Мрт-10 23:08 
>К сожалению, "моментальные" снимки LVM не такие-уж и моментальны ...

Я почему-то склонен верить ссылке, приведеной в статье:
http://www.mysqlperformanceblog.com/2009/02/05/disaster-lvm-...

Общий вывод - LVN + xfs + snapshot - вполне съедобно. ZFS может и лучше, но к сожалению на Linux ее не
предвидется :(.

При случае проведу аккуратные тесты и выложу результаты.

--
Вениамин.


"Моментальное обновление данных в СУБД MySQL с помощью LVM SN..."
Отправлено sluge , 18-Мрт-10 14:50 
fuse вам в помощ

"Моментальное обновление данных в СУБД MySQL с помощью LVM SN..."
Отправлено wkon , 19-Мрт-10 17:04 
Сдалал тесты, методика следующая:

1. оптимизируем таблицы в mydb_master.
2. mysqladmin refesh
3. sync
4. echo 2 > /proc/sys/vm/drop_caches; echo 3 > /proc/sys/vm/drop_caches
5. запускаем обработку  + sync.

Далее добавляем симок и повтяряем операцию.

Каждый раз обрататывается один и тот же блок данных (1000000 записей,размером ~100MB).
Исоходные данные агрегируются оп различным схемам и записываются в индексированные таблицы. Фактически, каждый раз данные перезаписываются, то есть состояение базы не меняется.

Кроме того я проверял время копирования одного гигабайта в каждом случае.


Конфигурация    Время оптимизации       Обрабтка+sync              Копируем 1GB + sync
mydb                        07:03                2:50                             0:05
mydb+1*snap                 09:23                2:56                             0:05
mydb+2*snap                 10:74                3:01                             1:40
mydb+3*snap                 11:23                3:15                             4:03

Вывод - наличие одного снимка практически не влияет на производительность.
Это и предполагалось, так как в обоих случах блок данных пишется только один раз.
Далее скорость копирования резко падает, а скорость обносления индексированных таблиц уменьшается незначительно.
В общем, получилось даже лучше чем я ожидал.