Комментарии 35
Полезный пост с практическими примерами простой реализации критически важных функций MySQL. Чем проще, тем надежнее :-)
Прочитал с интересом, спасибо. Так же уяснил для себя, что я практически не знаю MySQL… ушел учить :)
Спасибо, очень полезно. Пошел теперь читать вашу статью про мастер-мастер, которой не придал должного внимания вначале.
Статья безусловно интересная! Но матчасти можно было и побольше выдать )
Ребята, хочется разбавить вашу битрикс-тусовку, потому что, мало кому итересно очередное битрикс-мыло. Я считаю, что самая сильная сторона вашего продукта, это конечно же подсветка синтаксиса в редакторе кода. Развивайте это направление и вас ждет успех!
Почему же мыло. Из всех ЦМС наиболее удобная для конечного пользователя да и для разработчиков тоже. Да есть и битрикса свои недостатки. Покажите мне систему, у которой их нет.
Рад, что вам нравится наш редактор с подсветкой! И, кстати, для истинных ценителей есть еще несколько схожих по функционалу модулей в нашем маркетплейсе:
marketplace.1c-bitrix.ru/solutions/citrus.ace/
marketplace.1c-bitrix.ru/solutions/cn.highlight/
Спасибо за добрые пожелания! ;)
marketplace.1c-bitrix.ru/solutions/citrus.ace/
marketplace.1c-bitrix.ru/solutions/cn.highlight/
Спасибо за добрые пожелания! ;)
используем сходные решения у себя, пришли к тем же выводам и библиотекам
но:
— отказались от хранения сессий в базе. при большой нагрузке удаление сессий из базы становится трудоемкой задачей, да и смысла хранить там данные нет. Как показывает пример вам не очень важна сессия пользователя, превосходно с ее хранением справится мемкешед.
— чтобы сделать быстрый бекап у перконы есть специальная утилита xtrabackup, его же можно использовать что бы поднять репликацию
но:
— отказались от хранения сессий в базе. при большой нагрузке удаление сессий из базы становится трудоемкой задачей, да и смысла хранить там данные нет. Как показывает пример вам не очень важна сессия пользователя, превосходно с ее хранением справится мемкешед.
— чтобы сделать быстрый бекап у перконы есть специальная утилита xtrabackup, его же можно использовать что бы поднять репликацию
— Сессии (в итоге, после разных экспериментов) тоже храним в мемкеше. Правда, потребовалась некоторая доработка логики, чтобы реализовать собственный механизм локировок (в мемкеше его нет).
— xtrabackup тоже используем, но для других сценариев. Снэпшот и образ машины делаются сильно проще и быстрее. Да и разворачивать их потом тоже легче.
— xtrabackup тоже используем, но для других сценариев. Снэпшот и образ машины делаются сильно проще и быстрее. Да и разворачивать их потом тоже легче.
Поднятие образа машины из снепшота в амазоне с моментальным снимком данных — работает в принципе не хуже xtrabackup. Иначе использовали бы конечно xtrabackup.
Нет, ребята! Стоп! За годы потоков говна на ваш продукт, вы видимо научились замыливать любые высказывания по поводу вашего «продукта». Как Рыжиков, когда на презентациях что-то не работает ( а у вас всегда что-то не работает. Последнее выступление на партнерской летней конференции вообще было фееричным, смеялись всем офисом), он отшучивается и уводит тему в другое русло.
Так вот, конечные пользователи вообще не суются в вашу админку и, что бы сменить картинку, звонят разработчикам, а разработчик чертыхаясь лезет туда, думая о том, что пора сваливать из конторы, которая юзает ваш «продукт»( не потому что он удобный, а потому что ваша партнерская программа дает возможность заработать).
Ну все, не буду разводить снова эту возню вокруг «продукта». Как говориться не трогай, оно и вонять не будет. Всем добра!
Так вот, конечные пользователи вообще не суются в вашу админку и, что бы сменить картинку, звонят разработчикам, а разработчик чертыхаясь лезет туда, думая о том, что пора сваливать из конторы, которая юзает ваш «продукт»( не потому что он удобный, а потому что ваша партнерская программа дает возможность заработать).
Ну все, не буду разводить снова эту возню вокруг «продукта». Как говориться не трогай, оно и вонять не будет. Всем добра!
Если вы столь искренне переживаете за наш продукт, расскажите о ваших переживаниях там, где это будет уместно. Лично Рыжикову (его e-mail, твиттер, фейсбук не являются тайной; на конструктивную критику он всегда реагирует), на сайте idea.1c-bitrix.ru/ (его читают все наши разработчики), создайте обращение в тех. поддержку или напишите лично ее руководителю (все контакты тоже доступны).
Эта статья — о практиках использования MySQL. Для любых проектов, на Битриксе они сделаны или нет.
Если вы как на красную тряпку реагируете именно на слово «битрикс», тут уж ничего не поделаешь — так уж сложилось, что в данном случае практическим опытом делимся именно мы. И очень верю, что для многих он — полезен.
Эта статья — о практиках использования MySQL. Для любых проектов, на Битриксе они сделаны или нет.
Если вы как на красную тряпку реагируете именно на слово «битрикс», тут уж ничего не поделаешь — так уж сложилось, что в данном случае практическим опытом делимся именно мы. И очень верю, что для многих он — полезен.
Ваше, безусловно авторитетное мнение, подсказывает, что вы можете привести парочку альтернатив битриксу?
ошибки вида «1062 Error 'Duplicate entry'» можно избежать, сказав серверу использовать автоинкримент со смещением:
auto_increment_increment
auto_increment_offset
dev.mysql.com/doc/refman/5.1/en/replication-options-master.html
auto_increment_increment
auto_increment_offset
dev.mysql.com/doc/refman/5.1/en/replication-options-master.html
Это подразумевается по умолчанию. И об этом как раз говорится в предыдущей статье, на которую я несколько раз ссылался: habrahabr.ru/company/bitrix/blog/146490/
В противном случае «м-м» в принципе не будет работать.
Но даже с настроенными auto_increment_increment и auto_increment_offset «Duplicate entry» все равно будут. Один из возможных сценариев появления такой ошибки как раз описан в статье.
В противном случае «м-м» в принципе не будет работать.
Но даже с настроенными auto_increment_increment и auto_increment_offset «Duplicate entry» все равно будут. Один из возможных сценариев появления такой ошибки как раз описан в статье.
Позвольте не согласиться,
При использовании этих 2-х параметров сервера м-м будут создавать только то значение, которое им позволено и никогда не пересекуться.
Например
сервер А:
auto_increment_increment=10
auto_increment_offset=1
сервер В:
auto_increment_increment=10
auto_increment_offset=2
тогда
Сервер А значения:
1,11,21,31,41,51
Сервер В значения:
2,12,22,32,42,52
даже если один из них умрет, второй продолжит создавать записи по своему офсету, не покушаясь на значения другого сервера.
Это касается автоинкриментов, но не спасает от Duplicate key — В данном случае поможет:
указать, какие типы ошибок игнорировать. В таком случае, методом проб, ошибок и нагоняев программистам достигается устойчивая м-м репликация. Полный список кодов можно посмотреть в share/errmsg.txt
Другое дело, если вдруг в коде используются конструкции вида Now(), при разрыве реплик — значения будут существенно разными.
При использовании этих 2-х параметров сервера м-м будут создавать только то значение, которое им позволено и никогда не пересекуться.
Например
сервер А:
auto_increment_increment=10
auto_increment_offset=1
сервер В:
auto_increment_increment=10
auto_increment_offset=2
тогда
Сервер А значения:
1,11,21,31,41,51
Сервер В значения:
2,12,22,32,42,52
даже если один из них умрет, второй продолжит создавать записи по своему офсету, не покушаясь на значения другого сервера.
Это касается автоинкриментов, но не спасает от Duplicate key — В данном случае поможет:
--slave-skip-errors={code}|All
указать, какие типы ошибок игнорировать. В таком случае, методом проб, ошибок и нагоняев программистам достигается устойчивая м-м репликация. Полный список кодов можно посмотреть в share/errmsg.txt
Другое дело, если вдруг в коде используются конструкции вида Now(), при разрыве реплик — значения будут существенно разными.
mysql_upgrade should be executed each time you upgrade MySQL. dev.mysql.com/doc/refman/5.5/en/mysql-upgrade.html JFYI
Уж что-что, а sql битрикс жрет как ни что другое… Просто кошмар сисадмина какой-то, а не система. Иногда приходится просить разрабов писать собственные sql-запросы для обращения к некоторым инфоблокам, чтобы не видеть в slow-query-log'е 15-этажные JOIN'ы. Самое забавное, когда join_buffer_size = 8G оказывается мало сайту с посещаемостью 5к человек в день. :)
Чтобы не было 15 этажных джойнов, можно делать разумную избыточность в инфоблоках.
Чёрт, что я пишу, если у вас есть некэшируемые(на сто тысяч лет) запросы с 15тью джойнами, то у вас просто напросто криво спроектирована структура инфоблоков, других вариантов нет.
Приведу пример: есть 200000 зареганных юзеров, есть 15 инфоблоков, по которым размазана инфа об этих юзерах. Когда нужно вытянуть это дело в одну таблицу, возникают траблы: не получается красиво разрулить такую ситуацию, руководствуясь правилами построения запроса к инфоблокам Битрикса. Приходится строить свои запросы к базе. Иногда получается что-то оптимизировать средствами битрикса, но чаще приходится самим что-то придумывать (даже писать свое кэширование, например).
Алсо, наши программисты ни то что читали ни раз всю документацию по Битриксу, но и затерли до дыр все статьи об оптимизации и грамотном программировании к Битрикс на Вашем (и не только) сайте.
Система хорошая, одна из лучших CMS, почти не глючит, но мееедленная…
Иногда, копаясь в ядре Битрикс натыкаешься на такой быдлокод, что волосы дыбом встают (в особенности, касаемо SQL-запросов).
Кстати, за годы разработки под Битрикс, мы написали что-то вроде фреймворка под свои нужды — вот в нем есть много переписанных функций ядра Битрикс, которые позволяют быстрее общаться с нашими БД.
Алсо, наши программисты ни то что читали ни раз всю документацию по Битриксу, но и затерли до дыр все статьи об оптимизации и грамотном программировании к Битрикс на Вашем (и не только) сайте.
Система хорошая, одна из лучших CMS, почти не глючит, но мееедленная…
Иногда, копаясь в ядре Битрикс натыкаешься на такой быдлокод, что волосы дыбом встают (в особенности, касаемо SQL-запросов).
Кстати, за годы разработки под Битрикс, мы написали что-то вроде фреймворка под свои нужды — вот в нем есть много переписанных функций ядра Битрикс, которые позволяют быстрее общаться с нашими БД.
1. насчёт «быдлокода» — в голову не приходила мысль, что это код написан таким образом в силу определённых причин? Например, некоторые куски кода можно, заменить стандартной php функцией, но только при определённых настройках сервера и при работе под mbstring'ом эта самая функция работает не правильно. И поэтому её приходится заменять «странным кодом», только он выглядит странным для прохожего, а как только вникаешь в причину его появления, понимаешь какая огромная работа была проделана.
2. размазывать информацию о пользователях по 15ти инфоблокам это жёстко! Опять же, для меня как для прохожего, который не знает всех ваших внутренних нюансов и бизнес-процессов, это как раз кажется быдлокодом. Хотя есть вероятность что такой подход, в силу каких то причин в вашем случае оправдан.х.з.
3. когда кол-во ИБ переваливает за 50, всегда стараюсь делать разумную избыточность, тогда данные можно выбирать без джойнов.
4. при больших объёмах таблиц, вычисления можно размазывать по времени — например некоторые значения можно рассчитывать при изменении элементов ИБ, это лучше чем пытаться за один проход всё сразу просчитать.
p.s. прошу прощения если вам покажется, что я пытаюсь объяснить детские истины.
2. размазывать информацию о пользователях по 15ти инфоблокам это жёстко! Опять же, для меня как для прохожего, который не знает всех ваших внутренних нюансов и бизнес-процессов, это как раз кажется быдлокодом. Хотя есть вероятность что такой подход, в силу каких то причин в вашем случае оправдан.х.з.
3. когда кол-во ИБ переваливает за 50, всегда стараюсь делать разумную избыточность, тогда данные можно выбирать без джойнов.
4. при больших объёмах таблиц, вычисления можно размазывать по времени — например некоторые значения можно рассчитывать при изменении элементов ИБ, это лучше чем пытаться за один проход всё сразу просчитать.
p.s. прошу прощения если вам покажется, что я пытаюсь объяснить детские истины.
А как Вы определили, что «join_buffer_size = 8G» — это мало? :)
И сколько у вас было при этом RAM в системе?
И сколько у вас было при этом RAM в системе?
mysqltuner.pl об этом рапортовал.
На mysql отводилось 12G.
На mysql отводилось 12G.
# Joins
if ($mycalc{'joins_without_indexes_per_day'} > 250) {
badprint "Joins performed without indexes: $mycalc{'joins_without_indexes'}\n";
push(@adjvars,"join_buffer_size (> ".hr_bytes($myvar{'join_buffer_size'}).", or always use indexes with joins)");
push(@generalrec,"Adjust your join queries to always utilize indexes");
} else {
...Если не будет индексов (зачастую — составных, которые надо построить самим), то он, видимо, всегда так будет рапортовать. :)
И «join_buffer_size = 8G» — это в любом случае плохо. Вот неплохое описание (с комментариями), как происходит выделение памяти для join_buffer_size:
www.mysqlperformanceblog.com/2010/07/05/how-is-join_buffer_size-allocated/
Чуть не забыл — спасибо за очень полезную статью.
Кстати, если репликация сломалась, у нас есть скрипты которые автоматом ее поднимают. Бывает в суматохе сразу и не вспомнишь всю последовательность действий для поднятия репликации с нуля, а скрипт отрабатывает за секунды.
Но у нас пока тупо master-slave для резервного зеркала.
Кстати, если репликация сломалась, у нас есть скрипты которые автоматом ее поднимают. Бывает в суматохе сразу и не вспомнишь всю последовательность действий для поднятия репликации с нуля, а скрипт отрабатывает за секунды.
Но у нас пока тупо master-slave для резервного зеркала.
Отличная статья! Тоже готовимся к большим проектам :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
11 «рецептов приготовления» MySQL в Битрикс24