Неожиданно поступила задача разобраться почему определенный сайт не работает столь быстро сколь хочется. В основе его CakePHP, в связке с Apache и MySQL. В статье описание процесса поиска узких мест и приведение в порядок на столько, на сколько это возможно.
Название сайта светить не буду — думаю, программисты сами узнают. Скажу лишь, что это приложение для социальной сети нагрузкой 70-150 тысяч посетителей в обычное время. Все усложняется тем, что периодически производится рекламная рассылка, которая привлекает около 200-300 тысяч посетителей за пару часов.
Читать полностью »
Рубрика «mysql» - 51
Оптимизация связки Nginx, Apache, PHP, MySql
2012-06-20 в 11:09, admin, рубрики: Apache, linux, mysql, mysql performance, оптимизация сайта, метки: apache, mysql performance, оптимизация сайтаread_buffer_size может разрывать репликацию данных
2012-06-15 в 16:41, admin, рубрики: mysql, mysql tricks, переводы, метки: mysql tricksПеревод свежей статьи Miguel Angel Nieto «read_buffer_size can break your replication».
Существуют некоторые переменные, которые могут влиять на проведение репликации и иногда причинять большие неприятности. В этом посте я собираюсь поговорить о переменной read_buffer_size, и о том, как эта переменная вместе с max_allowed_packet может разорвать вашу репликацию.
Читать полностью »
Радужные таблицы в домашних условиях
2012-06-14 в 11:55, admin, рубрики: mysql, php, информационная безопасность, радужные таблицы, хэши, метки: mysql, PHP, информационная безопасность, радужные таблицы, хэши 
Прошедшая неделя с точки зрения информационной безопасности выдалась исключительно «удачной»: то база хэшей LinkedIn утекла в сеть, то хэши last.fm. И во всех обсуждениях, так или иначе, упоминают о радужных таблицах.
Слышали о них почти все, но делали их своими руками очень немногие.
Читать полностью »
Репликация из OLTP в OLAP базу данных
2012-06-13 в 11:35, admin, рубрики: mysql, Vertica, Администрирование баз данных, репликация, метки: mysql, Vertica, репликацияМой друг Роберт Ходжес на днях опубликовал статью про репликацию из OLTP в OLAP базу данных (а именно, из MySQL в Vertica), которую его компания построила на своем продукте Tungsten. Самое интересное, это преобразование данных, которое происходит в процессе репликации. Подход достаточно общий, и может быть использован и для других систем.
Обычный подход к репликации — это синхронный или асинхронный перенос бинарного лога с одной базы данных (мастер) на другие (слейвы). В бинарном логе строго последовательно записываются все операции, которые модифицируют данные. Если его «проиграть» на другой системе с той же начальной точки, то должно получиться точно такое же состояние данных, как и на исходной. «Проигрывание» происходит по одной операции или по одной транзакции, то есть очень маленькими кусочками.
Этот подход плохо работает с OLAP-специфичными, и особенно, колонко-ориентированными базами данных, которые хранят данные физически не по строкам, а по колонкам. Такие базы данных оптимизированы на запись, чтение и сортировку больших массивов данных, что типично для аналитических задач, но не на маленькие операции на единичных записях, потому что любая операция затрагивает много колонок, которые физически хранятся в разных файлах (а иногда и разных дисках). Хуже всего обстоит дело с изменением данных. Конечно, все базы данных поддерживают стандарт SQL и оператор UPDATE, но на физическом уровне он, как правило, транслируется в то, что обновляемая запись помечается как удаленная, а вместо нее вставляется измененная копия. Потом, когда-нибудь, «сборщик мусора» перетрясет таблицу и удаленные записи удалятся навсегда. Помимо плохой эффективности, отсюда следует, что частые удаления и обновления приводят к «засорению» базы данных, что снижает ее производительность в том числе и на чтение.
Роберт предложил, как мне кажется, новый, хотя и естественный подход к решению проблемы репликации данных для таких случаев. Бинарный лог преобразуется в последовательность частично упорядоченных множеств операций типа DELETE/INSERT для каждой таблицы, причем, так слово «множество» подразумевает, что «одинаковые» в некотором смысле операции достаточно сделать один раз. Поясню чуть подробнее.
Читать полностью »
Смешная уязвимость в MySQL под Ubuntu 64-bit
2012-06-11 в 8:17, admin, рубрики: glibc, mariadb, memcmp, mysql, информационная безопасность, любой пароль, Убунтариум, метки: glibc, mariadb, memcmp, mysql, любой парольВ субботу координатор по безопасности проекта MariaDB Сергей Голубчик сообщил об интересной уязвимости в MySQL/MariaDB до версий 5.1.61, 5.2.11, 5.3.5, 5.5.22.
Суть в том, что при подключении пользователя MariaDB/MySQL вычисляется токен (SHA поверх пароля плюс хэш), который сравнивается с ожидаемым значением. При этом функция memcmp() должна возвращать значение в диапазоне -128..127, но на некоторых платформах (похоже, в glibc в Linux с оптимизацией под SSE) возвращаемое значение может выпадать из диапазона.
В итоге, в 1 случае из 256 процедура сравнения хэша с ожидаемым значением всегда возвращает значение true, независимо от хэша. Другими словами, система уязвима перед случайным паролем с вероятностью 1/256.
Читать полностью »
Смешная уязвимость в MySQL под Linux 64-bit
2012-06-11 в 8:17, admin, рубрики: glibc, mariadb, memcmp, mysql, информационная безопасность, любой пароль, Убунтариум, метки: glibc, mariadb, memcmp, mysql, любой парольВ субботу координатор по безопасности проекта MariaDB Сергей Голубчик (petropavel) сообщил об интересной уязвимости в MySQL/MariaDB до версий 5.1.61, 5.2.11, 5.3.5, 5.5.22.
Суть в том, что при подключении пользователя MariaDB/MySQL вычисляется токен (SHA поверх пароля плюс хэш), который сравнивается с ожидаемым значением. При этом функция memcmp() должна возвращать значение в диапазоне -128..127, но на некоторых платформах (похоже, в glibc в Linux с оптимизацией под SSE) возвращаемое значение может выпадать из диапазона.
В итоге, в 1 случае из 256 процедура сравнения хэша с ожидаемым значением всегда возвращает значение true, независимо от хэша. Другими словами, система уязвима перед случайным паролем с вероятностью 1/256.
Читать полностью »
Все прекрасно знают, что разорить букмекера невозможно, а обыграть очень и очень трудно.Ведь у нас намного меньше оружий для войны с букмекером.Другими словами мы играем в темную с одним ножом против букмекера у которого есть все в том числе и прибор видения в темноте.
Этим прибором может быть что угодно — договорные матчи, сотни подручных изучающие каждую новость команды вплоть до и после начала матча, возможность убирать и изменять исходы и т.д. Но мы конечно не жалуемся и просто играем на поставленных нам условиях. А что же нам еще делать? Играть то хочется.
Читать полностью »
Простая замена phpMyAdmin для гиков
2012-06-09 в 16:47, admin, рубрики: breeze, mysql, php, метки: breeze, mysql, PHPДовольно часто возникает ситуация, когда надо быстренько запустить пару запросов к MySQL базе у клиента на сервере. При этом есть только FTP и параметры соединения с СУБД. Самый простой выход — загрузить туда phpMyAdmin, ну а дальше дело техники. Обычно все это проиcходит на фоне того, что у клиента уже установлена какая-то CMS — WordPress, Drupal, Joomla…
Я люблю простые, красивые и удобные вещи. Я тепло отношусь к phpMyAdmin но в 90% моих Use Cases мне он не нужен. Нужно что-то простое. В идеале такое, что можно просто залить на сервер и открыть в браузере — не настраивая.
Пара вечеров и пакет готов.
Читать полностью »
Дубликаты первичных ключей в таблице MySQL
2012-06-09 в 10:27, admin, рубрики: mysql, Песочница, репликация базы данных, метки: mysql, репликация базы данныхВпервые столкнулся во время разработки с такой ситуаций: дубликаты первичных ключей в таблице MySQL.
При импорте таблицы с боевого сервера на локальный обнаружилось, что есть дубликаты первичных ключей. В первую очередь попробовал на боевом запросить записи с этим ключом:
SELECT *
FROM `map_group_tmp`
WHERE id =672192
В результате phpMyAdmin вернул только одну строку.
Ок, пошли дальше: поискал вхождения строки '672192' в .sql файле (результат экспорта из phpMyAdmin) с боевого. Действительно, нашлось две такие записи.
Контроль версий структуры базы данных MySQL
2012-06-04 в 9:12, admin, рубрики: Lua, mysql, mysql-proxy, Веб-разработка, метки: lua, mysql, mysql-proxyПри разработке веб-приложений хорошим тоном, наряду с практичностью, считается использовать систему контроля версий. В этом случае всегда можно легко откатить или развернуть изменения, внесенные в код одним или несколькими разработчиками. Часто веб-приложения не обходятся без реляционных баз данных, структура которых может меняться в процессе разработки и переходе от версии к версии. Отслеживание этих изменений — необходимый этап процесса разработки.
Существует несколько способов держать актуальной структуру таблиц во всех окружениях разработки. Например, можно писать вручную изменяющие SQL-запросы в отдельный файл, использовать схемы баз данных или программы для автоматизации сборки проектов, вроде Maven или Phing.
Если используется СУБД MySQL задачу можно решить с помощью проксирования запросов.