forum.opennet.ru - "Моментальное обновление данных в СУБД MySQL с помощью LVM SN..." (11)

форумы

помощь

поиск

регистрация

майллист

вход/выход

слежка

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

Форумы Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"Моментальное обновление данных в СУБД MySQL с помощью LVM SN..."		+/–
Сообщение от opennews on 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
Высказать мнение \| Ответить \| Правка \| Cообщить модератору

Оглавление

Моментальное обновление данных в СУБД MySQL с помощью LVM SN..., funky_dennis, 21:51 , 16-Мрт-10, (1)

Моментальное обновление данных в СУБД MySQL с помощью LVM SN..., anonymous, 00:46 , 17-Мрт-10, (2)
Моментальное обновление данных в СУБД MySQL с помощью LVM SN..., walrus, 17:25 , 17-Мрт-10, (7)
Моментальное обновление данных в СУБД MySQL с помощью LVM SN..., wkon, 23:00 , 17-Мрт-10, (8)

Моментальное обновление данных в СУБД MySQL с помощью LVM SN..., Аноним, 01:37 , 17-Мрт-10, (3)

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

Моментальное обновление данных в СУБД MySQL с помощью LVM SN..., ank1812, 14:04 , 17-Мрт-10, (5)
Моментальное обновление данных в СУБД MySQL с помощью LVM SN..., Аноним, 14:25 , 17-Мрт-10, (6)

Моментальное обновление данных в СУБД MySQL с помощью LVM SN..., wkon, 23:08 , 17-Мрт-10, (9)

Моментальное обновление данных в СУБД MySQL с помощью LVM SN..., sluge, 14:50 , 18-Мрт-10, (10)
Моментальное обновление данных в СУБД MySQL с помощью LVM SN..., wkon, 17:04 , 19-Мрт-10, (11)

Сообщения по теме [Сортировка по времени | RSS]

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

Сообщение от funky_dennis on 16-Мрт-10, 21:51

После каждого слова в статье надо писать MyISAM!

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

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

Сообщение от anonymous (??) on 17-Мрт-10, 00:46

обновления в примере один раз в час, значит буферпул с большой долей вероятности будет сброшен на диски.
при желании можно ускорить recovery и уменьшить потерю данных через:
set global innodb_max_dirty_pages_pct=0;

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

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

Сообщение от walrus on 17-Мрт-10, 17:25

И что случится, если использовать такой бэкап с  innodb? то же , что при потере питания машины. Во время восстановления откатятся текущие транзакции. И все.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

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

Сообщение от wkon (ok) on 17-Мрт-10, 23:00

В целом соглашусь с funky_dennis. Действительно, метод работает в случае если та часть БД
с которой выполняется снимок состоит из таблиц MyISAM.
Подкорректирую статью.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

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

Сообщение от Аноним (??) on 17-Мрт-10, 01:37

К сожалению, "моментальные" снимки LVM не такие-уж и моментальны и, что самое главное, под нагрузкой после снимка все начитает _так_ тормозить
Полноценно такую технику можно использовать "в бою" только на Copy-on-Write файловых системах, например - ZFS.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

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

Сообщение от Аноним (??) on 17-Мрт-10, 11:13

Ага, только зфс тот еще тормоз....

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

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

Сообщение от ank1812 on 17-Мрт-10, 14:04

zfs реально одна из самых быстрых файловых систем. "просто добавь воды"(памяти).

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

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

Сообщение от Аноним (??) on 17-Мрт-10, 14:25

тора гой, не используй ZFS под vmware и все будет карашо.
если серьзно - ZFS хороша на "родном" Solaris. там она для MySQL - шикарна.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

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

Сообщение от wkon (ok) on 17-Мрт-10, 23:08

>К сожалению, "моментальные" снимки LVM не такие-уж и моментальны ...
Я почему-то склонен верить ссылке, приведеной в статье:
http://www.mysqlperformanceblog.com/2009/02/05/disaster-lvm-...
Общий вывод - LVN + xfs + snapshot - вполне съедобно. ZFS может и лучше, но к сожалению на Linux ее не
предвидется :(.
При случае проведу аккуратные тесты и выложу результаты.
--
Вениамин.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

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

Сообщение от sluge (ok) on 18-Мрт-10, 14:50

fuse вам в помощ

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

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

Сообщение от wkon (ok) on 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
Вывод - наличие одного снимка практически не влияет на производительность.
Это и предполагалось, так как в обоих случах блок данных пишется только один раз.
Далее скорость копирования резко падает, а скорость обносления индексированных таблиц уменьшается незначительно.
В общем, получилось даже лучше чем я ожидал.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "Моментальное обновление данных в СУБД MySQL с помощью LVM SN..."		+/–
Сообщение от funky_dennis on 16-Мрт-10, 21:51
После каждого слова в статье надо писать MyISAM!
Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	2. "Моментальное обновление данных в СУБД MySQL с помощью LVM SN..."		+/–
	Сообщение от anonymous (??) on 17-Мрт-10, 00:46
	обновления в примере один раз в час, значит буферпул с большой долей вероятности будет сброшен на диски. при желании можно ускорить recovery и уменьшить потерю данных через: set global innodb_max_dirty_pages_pct=0;
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


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


	8. "Моментальное обновление данных в СУБД MySQL с помощью LVM SN..."		+/–
	Сообщение от wkon (ok) on 17-Мрт-10, 23:00
	В целом соглашусь с funky_dennis. Действительно, метод работает в случае если та часть БД с которой выполняется снимок состоит из таблиц MyISAM. Подкорректирую статью.
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору

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


	4. "Моментальное обновление данных в СУБД MySQL с помощью LVM SN..."		+/–
	Сообщение от Аноним (??) on 17-Мрт-10, 11:13
	Ага, только зфс тот еще тормоз....
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	5. "Моментальное обновление данных в СУБД MySQL с помощью LVM SN..."		+/–
	Сообщение от ank1812 on 17-Мрт-10, 14:04
	zfs реально одна из самых быстрых файловых систем. "просто добавь воды"(памяти).
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	6. "Моментальное обновление данных в СУБД MySQL с помощью LVM SN..."		+/–
	Сообщение от Аноним (??) on 17-Мрт-10, 14:25
	тора гой, не используй ZFS под vmware и все будет карашо. если серьзно - ZFS хороша на "родном" Solaris. там она для MySQL - шикарна.
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	9. "Моментальное обновление данных в СУБД MySQL с помощью LVM SN..."		+/–
	Сообщение от wkon (ok) on 17-Мрт-10, 23:08
	>К сожалению, "моментальные" снимки LVM не такие-уж и моментальны ... Я почему-то склонен верить ссылке, приведеной в статье: http://www.mysqlperformanceblog.com/2009/02/05/disaster-lvm-... Общий вывод - LVN + xfs + snapshot - вполне съедобно. ZFS может и лучше, но к сожалению на Linux ее не предвидется :(. При случае проведу аккуратные тесты и выложу результаты. -- Вениамин.
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	10. "Моментальное обновление данных в СУБД MySQL с помощью LVM SN..."		+/–
	Сообщение от sluge (ok) on 18-Мрт-10, 14:50
	fuse вам в помощ
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	11. "Моментальное обновление данных в СУБД MySQL с помощью LVM SN..."		+/–
	Сообщение от wkon (ok) on 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+1snap 09:23 2:56 0:05 mydb+2snap 10:74 3:01 1:40 mydb+3*snap 11:23 3:15 4:03 Вывод - наличие одного снимка практически не влияет на производительность. Это и предполагалось, так как в обоих случах блок данных пишется только один раз. Далее скорость копирования резко падает, а скорость обносления индексированных таблиц уменьшается незначительно. В общем, получилось даже лучше чем я ожидал.
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору