[lang_en]MySQL Master-Master replication manager released[/lang_en][lang_ru]Релиз ПО для управления кластерами с MySQL Master-Master репликацией[/lang_ru]
5 Apr2007

[lang_en]

So, I’s been a long time since I wrote my last post here. Lots of work and almost no new interesting technologies in my work caused such delay. But today I’m proud to announce release of really interesting project: MySQL Master-Master replication manager – set of flexible scripts for management different MySQL deployment schemes with master-master replication involved.

More information about this software could be found in detailed announce in Peter Zaitsev blog (actually this software was created by me for his company’s client) or at project page. All your questions and suggestions welcomed in MMM development group on Google Groups. If you’d like to support this software on Digg.com, you’re welcome. 😉

[/lang_en]

[lang_ru]

Очень много времени прошло с момента моего последнего поста здесь. Много работы и практически полное отсутствие новых технологий в работе – вот основные причины. Ео сегодня я с удовольствием хочу аннонсировать здесь очень интересный проект: MySQL Master-Master replication manager – набор очень гибких скриптов для управления различными схемами установки MySQL, в которых используется master-master репликация.

Более детальная информация о проекте может быть найдена в детальном обзоре в блоге Петра Зайцева (на самом деле, программа создавалась мной для одного из его клиентов) или на странице проекта. Все вопросы и замечания можно отправлять в группу MMM development на Google Groups. Если вы хотите поддержать данный анонс на Digg.com, я буду не против. 😉

[/lang_ru]


[lang_en]Bug in Perl’s Thread::Semaphore: Memory Leak (solution provided)[/lang_en][lang_ru]Ошибка в Perl’овом Thread::Semaphore: Утечка памяти (решение прилагается)[/lang_ru]
25 Jan2007

[lang_en]

I spent almost all day trying to find and fix really strange bug in one of our server-side applications written on Perl. And as I’ve figured out later, there is huge problem in Perl core libraries or, even, in interpreter.

Problem is following. If you are trying to use “threads” module with “Thread::Semaphore” module like it is mentioned in official Perl documentation (perlthrtut), you’ll get 4kb memory leak on every $semaphore->up call. So, simple test-case like following would cause huge memory leaks (100 Mbytes per second on my test server):
[/lang_en]

[lang_ru]

Я потратил сегодня почти весь день пытаясь найти и поправить очень странную ошибку в одном из наших серверных приложений, написанных на Perl. И, как выяснилось в процессе, в системных библиотеках Perl или, может быть, в его интерпретаторе, есть крайне неприятная ошибка.

Проблема в следующем. Если вы попытаетесь использовать модуль “threads” вместе с модулем “Thread::Semaphore”, как это описано в официальной документации по языку Perl (perlthrtut), вы получите утечку памяти размером около 4kb на каждый вызов $semaphore->up. Следовательно, следующий простой пример кода вызовет просто огромные утечки памяти (около 100 Mбайт в секунду на моем тестовом сервере):
[/lang_ru]

Read the rest of this entry


Small Tip: How to fix “There are no public key available for the following key IDs” Error in Debian
28 Nov2006

Few days ago I’ve started migration of some of my non-critical servers to Debian Etch (from Sarge). Just after first apt-get update && apt-get dist-upgrade, when apt has been upgraded, I noticed really strange (as for me) error: when I’ve tried to do “apt-get update” it worked fine, but there was annoying message like following:

1
2
3
4
5
6
7
8
# apt-get update
......
Fetched 5562B in 13s (421B/s)
Reading package lists... Done
W: There are no public key available for the following key IDs:
A70DAF536070D3A1
W: You may want to run apt-get update to correct these problems
#


UPDATE: Thanks to Kurt Fitzner we know, that:

There is already a mechanism to do this automatically:

1
$ apt-key update

This will obtain the necesary keys and import them. No need to go through gpg directly.


After not so long research I figured out, that this problem was caused by change of gpg key used by ftpmaster on Debian official repository servers. Google gave me some information and I found some fix which works fine for me:

1
2
3
4
5
6
# gpg --keyserver wwwkeys.eu.pgp.net --recv-keys XXXXXXXXXXXXXXXX
...
# apt-key add /root/.gnupg/pubring.gpg
...
# apt-get update
...

Where XXXXXXXXXXXXXXXX is your missing key (e.g A70DAF536070D3A1).

That’s it! Happy using Debian GNU/Linux!


[lang_en]Best Tech Videos On The Net[/lang_en][lang_ru]Лучшее техническое видео в сети[/lang_ru]
20 Nov2006

[lang_en]

Few days ago I’ve started new site which name is BestTechVideos.com. I’ve created this site because there are lots really interesting videos on the Net, but if you’d like to fine some good tech video, it is not so simple to find them because of tons of crappy “funny videos” like “funny cats” and so on.

So, If you like to attend technical conferences and watch conference sessions on video, if you like idea of screencasts, etc, then this site is for you! Welcome to Best Tech Videos you’ll be impressed by amount of hi-quality and useful videos on the Net.

P.S. If you like this site idea, support it on Digg.com, please. Great thanks in advance.

[/lang_en]
[lang_ru]

Несколько дней назад я запустил новый сайт, имя которого BestTechVideos.com. Этот сайт был создан потому, что в сети реально очень много различных очень интересных видео-роликов на технические темы… вот только найти их порой бывает очень сложно из-за засилия “смешных роликов” про “прикольных котят” и тому подобного хлама.

Именно поэтому, если вы любите посещать конференции и слушать интересные доклады, любите смотреть видео, где профессионалы делятся своими скретами, понимаете и любите идею скринкастов и т.п., то этот сайт – именно для Вас! Добро пожаловать на Best Tech Videos и вы будете удивлены, сколько качественного и интересного контента есть в Сети.

P.S. Если Вам понравилась идея этого сайта, пожалуйста, проголосуйте за него на Digg.com. Заранее благодарю.

[/lang_ru]


[lang_en]Top 1000 (84) MySQL Performance Tips From MySQL Camp 2006[/lang_en][lang_ru]Список 1000 (84) Лучших Советов по Производительности MySQL с MySQL Camp 2006[/lang_ru]
14 Nov2006

[lang_en]

Looks like MySQL Camp 2006 was really interesting and useful for its attendees and for entire MySQL community. As the result of this meeting of many MySQL-related professionals we’ve got lots of interesting publications and I want to refer one of them in this post. Very interesting list of 84 MySQL performance tips has beed created on first day of this year MySQL Camp at Google headquarters:

  1. Index stuff.
  2. Don’t Index Everything
  3. Use benchmarking
  4. Minimize traffic by fetching only what you need.
    • Paging/chunked data retrieval to limit
    • Don’t use SELECT *
    • Be wary of lots of small quick queries if a longer query can be more efficient
  5. Use EXPLAIN to profile the query execution plan
  6. Use Slow Query Log (always have it on!)
  7. Don’t use DISTINCT when you have or could use GROUP BY
  8. Use proper data partitions (For Cluster. Start thinking about Cluster *before* you need them)
  9. Insert performance
    • Batch INSERT and REPLACE
    • Use LOAD DATA instead of INSERT
  10. LIMIT m,n may not be as fast as it sounds

So, I think this list can be really useful for all developers/DBAs working with MySQL and want to say “Thanks” to its authors.

[/lang_en]

[lang_ru]

Похоже, что MySQL Camp 2006 был действительно очень интересным и полезным событием как для тех, кто его посетил, так и для всего сообщества MySQL. Как результат этой встречи большого количества профессионалов, связанных с MySQL, появилось множество интересных публикаций. Именно одну из таких публикаций я и хотел бы “прорекламировать” сегодня. Очень интересный список 84 Лучших советов по производительности MySQL был создан в первый день работы MySQL Camp в штабквартире Google:

  1. Index stuff.
  2. Don’t Index Everything
  3. Use benchmarking
  4. Minimize traffic by fetching only what you need.
    • Paging/chunked data retrieval to limit
    • Don’t use SELECT *
    • Be wary of lots of small quick queries if a longer query can be more efficient
  5. Use EXPLAIN to profile the query execution plan
  6. Use Slow Query Log (always have it on!)
  7. Don’t use DISTINCT when you have or could use GROUP BY
  8. Use proper data partitions (For Cluster. Start thinking about Cluster *before* you need them)
  9. Insert performance
    • Batch INSERT and REPLACE
    • Use LOAD DATA instead of INSERT
  10. LIMIT m,n may not be as fast as it sounds

Я думаю, что этот список советов может быть очень полезен всем разработчикам и администраторам, работающим с MySQL и потому хочу сказать “Большое Спасибо” его авторам.

[/lang_ru]