The OpenNET Project / Index page

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

Оптимизация InnoDB на высоких нагрузках

07.03.2011 20:41

В статье описаны ключевые моменты конфигурации InnoDB в MySQL и их специфику при использовании на высоких нагрузках.

  1. Главная ссылка к новости (http://www.pentarh.com/wp/2011...)
Автор новости: Pentarh
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/29832-mysql
Ключевые слова: mysql, innodb
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (15) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Sylvia (ok), 00:29, 08/03/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    было бы интересно прочитать сравнение не только InnoDB с MyISAM

    но и с такими хранилищами как Aria (mariadb 5.2) (Maria (mariadb 5.1)) - с преимуществами myisam, но поддержкой транзакций, да пока это только в mariadb

    опять же Percona делает что-то с XtraDB, я не очень в курсе насколько у них велико расхождение с InnoDB, но возможно уже есть нюансы

     
     
  • 2.3, Pentarh (?), 01:07, 08/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Я сравнение общими фразами дал так.. по ходу повествования. Если их конкретно сравнивать, да еще и другие стораджи, книга получится )
     
     
  • 3.15, crypt (ok), 20:18, 12/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Я сравнение общими фразами дал так.. по ходу повествования. Если их конкретно
    > сравнивать, да еще и другие стораджи, книга получится )

    Чессказать я не очень вижу смысл в советах от человека, который в старых постах пишет:

    "Мой чисто практический опыт применения InnoDB на производственных мощностях показал, что данный драйвер гавно, массивные инсерты и апдейты кладут его в смерть. Симптомы: непонятные зависания тредов мускуля, потери данных. SQL вроде проходит, ошибки не возвращает, а данные не записались."

    Правда это 2009 год. Что-то могло измениться, но хотело бы тогда прочесть что-то типа "InnoDB изменился в лучшую сторону и вот почему... или за два года я получил ценный опыт и научился настраивать InnoDB, о чем и хочу поделиться..."

     

  • 1.2, opendb (?), 00:57, 08/03/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    "Собственный IT-блог с блекджеком и шлюхами"

    Очень ценный ресурс, да.

    InnoDB - ни рыба, ни мясо. Недотранзакции с ужасающей производительностью.

     
  • 1.4, achekalin (ok), 01:39, 08/03/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Где только автор русский изучал? Первая же попавшаяся на глаза фаза:

    "Надо хорошо понимать о происходящих в ее недрах процессах дабы правильно настроить этот тип хранилища."

    пишется хотя бы так:

    "Надо хорошо _разбираться_в_ происходящих в недрах _InnoDB_ процессах_,_ дабы... "

     
     
  • 2.8, sabitov (ok), 10:10, 08/03/2011 [^] [^^] [^^^] [ответить]  
  • –1 +/
    пишется хотя бы так:
    "Надо хорошо понимать происходящие в её ... "

    Скорее всего автор хотел написать одно, потом придумал другое, а результат получился AS-IS :)

     

  • 1.5, дм (?), 04:08, 08/03/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    А разве корректно делать бэкап баз путем снапшота раздела lvm как описано в статье? Есть же специальная утилита mysqldump.
     
     
  • 2.6, fetisheer (ok), 06:25, 08/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Не корректно, но и mysqldump не идеальный вариант. XtraDB backup лучше для этого подходит.
    LVM snapshot же плох своим оверхедом: http://www.mysqlperformanceblog.com/2009/02/05/disaster-lvm-performance-in-sn
     
     
  • 3.11, Sw00p aka Jerom (?), 14:57, 08/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    а чем плох дампер от перконы ?

    суперский

     
  • 2.7, angra (ok), 08:55, 08/03/2011 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Использовать mysqldump для бекапа, это все равно, что бекапить код программы переписыванием его на листочек. У mysqldump  несколько другое назначение.
     
  • 2.9, samm (ok), 11:09, 08/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    У вас база ляжет от локов во время mysqldump. Правда у лвм снепшотов ужасная производительность, лучше всего для этого ZFS на солярке, например
     
     
  • 3.12, fetisheer (ok), 15:10, 08/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    У mysqldump есть ключ --single-transaction, он как раз призван исключить блокировки.
     
     
  • 4.13, Pentarh (?), 15:24, 08/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > У mysqldump есть ключ --single-transaction, он как раз призван исключить блокировки.

    Ну я представляю как mysqldump превращает в SQL 40 гигов данных. Особенно интересно как происходит обратная операция.

     
     
  • 5.14, fetisheer (ok), 15:37, 08/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Не спорю, скорость у mysqldump не самая высокая, но связано это не с локами. Полагаю, по скорости восстановления с бэкапом, полученным с помощью snapshot, вообще ничего не сравнится.
     
  • 2.10, Pentarh (?), 14:22, 08/03/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > А разве корректно делать бэкап баз путем снапшота раздела lvm как описано
    > в статье? Есть же специальная утилита mysqldump.

    mysqldump на высоких нагрузках суръезно заткнет базу на время бекапа. Может быть в случае небольшой нагрузки mysqldump и канает.

    Я делаю бекап через LVM снапшот, описано это здесь:
    http://www.pentarh.com/wp/2010/08/12/mysql-remote-encrypted-backup-lvm-snapsh

    Очень даже замечательно бекапит 40 гигов.

     

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



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

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