| |
| 2.2, anonymous (??), 00:46, 17/03/2010 [^] [^^] [^^^] [ответить]
| +/– |
обновления в примере один раз в час, значит буферпул с большой долей вероятности будет сброшен на диски.
при желании можно ускорить recovery и уменьшить потерю данных через:
set global innodb_max_dirty_pages_pct=0;
| | |
| 2.7, walrus (?), 17:25, 17/03/2010 [^] [^^] [^^^] [ответить]
| +/– |
 И что случится, если использовать такой бэкап с innodb? то же , что при потере питания машины. Во время восстановления откатятся текущие транзакции. И все.
| | |
| 2.8, wkon (ok), 23:00, 17/03/2010 [^] [^^] [^^^] [ответить]
| +/– |
В целом соглашусь с funky_dennis. Действительно, метод работает в случае если та часть БД
с которой выполняется снимок состоит из таблиц MyISAM.
Подкорректирую статью.
| | |
|
| 1.3, Аноним (-), 01:37, 17/03/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
К сожалению, "моментальные" снимки LVM не такие-уж и моментальны и, что самое главное, под нагрузкой после снимка все начитает _так_ тормозить
Полноценно такую технику можно использовать "в бою" только на Copy-on-Write файловых системах, например - ZFS.
| | |
| |
| |
| 3.5, ank1812 (?), 14:04, 17/03/2010 [^] [^^] [^^^] [ответить]
| +/– |
zfs реально одна из самых быстрых файловых систем. "просто добавь воды"(памяти).
| | |
| 3.6, Аноним (-), 14:25, 17/03/2010 [^] [^^] [^^^] [ответить]
| +/– | |
тора гой, не используй ZFS под vmware и все будет карашо.
если серьзно - ZFS хороша на "родном" Solaris. там она для MySQL - шикарна.
| | |
|
| |
| 3.11, wkon (ok), 17:04, 19/03/2010 [^] [^^] [^^^] [ответить]
| +/– | |
Сдалал тесты, методика следующая:
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).
Исоходные данные агрегируются оп различным схемам и записываются в индексированные таблицы. Фактически, каждый раз данные перезаписываются, то есть состояение базы не меняется.
Кроме того я проверял время копирования одного гигабайта в каждом случае.
[CODE]
Конфигурация Время оптимизации Обрабтка+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
[/CODE]
Вывод - наличие одного снимка практически не влияет на производительность.
Это и предполагалось, так как в обоих случах блок данных пишется только один раз.
Далее скорость копирования резко падает, а скорость обносления индексированных таблиц уменьшается незначительно.
В общем, получилось даже лучше чем я ожидал.
| | |
|
|
|
