The OpenNET Project / Index page

[ новости/++ | форум | wiki | теги | ]

16.03.2010 21:20  Моментальное обновление данных в СУБД MySQL с помощью LVM SNAPSHOT

В статье представлен вариант решения проблемы блокировки сервисов извлечения информации при добавлении больших блоков данных в СУБД MySQL. Проблема решена с помощью моментальных снимков (snapshot) в менеджере томов LVM.

  1. Главная ссылка к новости (http://wiki.opennet.ru/MySQL_L...)
Автор новости: Вениамин
Тип: яз. русский / Практикум
Ключевые слова: mysql, snapshot, linux, lvm
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение Ajax/Линейный | Раскрыть все сообщения | RSS
 
  • 1.1, funky_dennis (?), 21:51, 16/03/2010 [ответить] [показать ветку] [···]    [к модератору]
  • +/
    После каждого слова в статье надо писать MyISAM!
     
     
  • 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 не такие-уж и моментальны и, что самое гл... весь текст скрыт [показать]
     
     
  • 2.4, Аноним (-), 11:13, 17/03/2010 [^] [ответить]    [к модератору]  
  • +/
    Ага, только зфс тот еще тормоз....
     
     
  • 3.5, ank1812 (?), 14:04, 17/03/2010 [^] [ответить]    [к модератору]  
  • +/
    zfs реально одна из самых быстрых файловых систем. "просто добавь воды"(памяти).
     
  • 3.6, Аноним (-), 14:25, 17/03/2010 [^] [ответить]    [к модератору]  
  • +/
    тора гой, не используй ZFS под vmware и все будет карашо.

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

     
  • 2.9, wkon (ok), 23:08, 17/03/2010 [^] [ответить]    [к модератору]  
  • +/
    >К сожалению, "моментальные" снимки LVM не такие-уж и моментальны ...

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

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

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

    --
    Вениамин.

     
     
  • 3.10, sluge (ok), 14:50, 18/03/2010 [^] [ответить]    [к модератору]  
  • +/
    fuse вам в помощ
     
  • 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]

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


     

     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:


      Закладки на сайте
      Проследить за страницей
    Created 1996-2018 by Maxim Chirkov  
    ДобавитьПоддержатьВебмастеруГИД  
    Hosting by Ihor