• cities : Города мира (страна, регион, широта, долгота, класс IP-адреса)
• fips_countries : Страны мира (код, имя)
• fips_regions : Регионы
• ip_group_city : Местонахождение IP-адресов (по стране, региону, городу, почтовому индексу, широте и долготе)

Как пользоваться?
IP-адреса находятся в таблицах ip_group_city и ip_group_country и вычисляются по формуле (например для IP A.B.C.D):

ip = (A*256+B)*256+C

Точность до последнего октета на так важна :)
Например, у нас есть IP 74.125.45.100 (google)
Приводим его к виду, сохраненному в БД

ip = (74*256+125)*256+45 = 4881709

И делаем запрос:

SELECT * FROM `ip_group_city` where `ip_start` <= 4881709 order by ip_start desc limit 1;

Результат:

ip_start|country_code|region_code|city|zipcode|latitude|longitude
4881664|US|CA|Mountain View|94043|37.4192|-122.057

Почему в базе данных лишь 1,2 миллионов записей, в то время как в действительности IP-адресов больше чуть ли не в 10 раз???
Пусть IP с 74.125.0.XXX по 74.125.32.XXX расположены близко друг к другу (принадлежат Google, например) Если бы в базе 32 раза была бы сохранена одна и таже информация, то размер базы был бы огромным! Поэтому в базе лежит лишь 74.125.0.XXX. Следующая строка начнется с 74.125.33.XXX

Оригинал: http://blogama.org/node/58
Скачать базу: http://www.blogama.org/ipinfodb.sql.bz2 (10 Mb)

Зеркало: http://www.boombick.org/ipinfodb.sql.bz2

Но использование MySQL Proxy лишь в качестве посредника (принял запрос -> передал серверу -> получил ответ -> передал клиенту) было бы весьма нецелесообразным. И действительно, эта небольшая программа умеет немало всего. В MySQL Proxy есть встроенный интерпретатор языка lua, с его помощью мы можем выполнять немало полезных действий над данными, проходящими через прокси.

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

• Передать его дальше неизмененным (по умолчанию)
• Исправить грамматические ошибки (CRATE DATAABSE, знакомо, не правда ли?)
• Отфильтровать запрос по неким правилам (или совсем отклонить его)
• Исправить запрос (например добавить более стойкий пароль или заполнить пустые значения)
• Добавить “забытые” значения (автокоммит включен, а пользователь послал запрос BEGIN WORK? Вы можете поместить перед ним SET AUTOCOMMIT = 0)
• И это далеко не все, полный список возможностей ограничен лишь вашей фантазией!

Также вы можете выполнять операции над результатами запросов:

• Добавлять, удалять и модифицировать записи в результате запроса. Хотите замаскировать пароль или скрыть конфиденциальные данные от неавтоизованного пользователя?
• Строить свои собственные result set’ы, включая имена столбцов. Например, если вы позволяете пользователю вводить его собственные SQL-команды, то вы можете показать предварительный результат
• Игнорировать результат, то есть ничего не отсылать клиенту
• Хотите большего? Ничего невозможного: смотрите примеры и экспериментируйте!

Ключевые понятия
MySQL Proxy построен на базе объектно-ориентированной архитектуры. Основной класс имеет три публичных метода и вы можете переопределить их в своих lua-сценариях.

• connect_server(): – вызывается при соединении, при помощи этого метода вы можете оперировать параметрами соединения. Именно этот метод используется при построении распределения нагрузки (load balancing)
• read_query(packet): – этот метод вызывается перед отправкой запроса на сервер. Вы можете изменить оригинальный запрос, добавить свои подзапросы или запросы или решить вообще ничего не отправлять на сервер, а отдать клиенту собственный result set (Например в ответ на SELECT * FROM big_table вы можете вернуть Таблица big_table содержит более 20 миллионов записей. Вы не забыли условие WHERE?)
• read_query_result(injection_packet) – эта функция выполняется перед отправкой результата запроса клиенту. Вы можете проигнорировать result set, изменить его или отправить клиенту неизмененным

Комбинация этих трех методов обеспечит вам прекрасную маневренность при управлении сервером (или серверами) MySQL

Установка
Установки Proxy предельно проста. Дистрибутив содержит в себе один бинарный файл (с версии 0.5.1 также несколько lua-скриптов для примера). Вы можете распаковать его и поместить туда, куда вам больше нравится. Или воспользоваться пакетным менеджером вашего дистрибутива (например, RPM или apt-get).
Если ваш дистрибутив не содержит готового пакета с Proxy или вы хотите поэксперементировать с опциями сборки, то вы можете получить исходные тексты из репозитория Subversion и собрать Proxy самостоятельно. Для этого необходимо выполнить несколько простых действий:

./autogen.sh
./configure && make
sudo make install
# will copy the executable to /usr/local/sbin

Простой перехват запроса
В качестве нашего первого примера давайте просто сделаем преобразование запроса с добавлением метки типа “Я здесь был” :)

1. Создайте lua-сценарий с листингом, приведенным ниже и сохраните его под именем first_example.lua
2. Предположим, что ваш сервер находится на той же физической машине, что и клиент
3. С другой консоли присоединитесь к вашему прокси-серверу и выполните какой-нибудь запрос (используйте порт 4040 вместо порта сервера 3306)

 -- first_example.lua
 function read_query(packet)
   if string.byte(packet) == proxy.COM_QUERY then
     print("Hello world! Seen the query: " .. string.sub(packet, 2))
   end
 end

# starting the proxy
$ mysql-proxy –proxy-lua-script=first_example.lua -D
# from another console, accessing the proxy
$ mysql -u USERNAME -pPASSWORD -h 127.0.0.1 -P 4040 -e ‘SHOW TABLES FROM test’

Если мы вернемся к предыдущей консоли, то увидим, что прокси успешно перехватил запросы:

Hello world! Seen the query: select @@version_comment limit 1
Hello world! Seen the query: SHOW TABLES FROM test

Первый запрос был послан клиентом MySQL при соединении, вторый выполнен нами. Как видите, мы находимся точно посередине между клиентом и сервером и даже уже можем кое-что сделать.. Пока это крайне мало, но в следующих главах будет интереснее.

Комментарий
До версии 0.5.0 для использования lua-сценариев, вы должны были запускать прокси с параметром –proxy-profiling, иначе функции read_query и read_query_result просто не работали. Начиная с версии 0.5.1 этот параметр не обязателен. Теперь эти опции включены по умолчанию. Напротив, если вы используете MySQL Proxy только для балансировки нагрузки, то рекомендуется стартовать прокси-сервер с опцией –proxy-skip-profiling

Изменение запросов
Более интересные возможности открываются при взгляде на возможности прокси по изменению запросов. Для демонстрации давайте возьмем реальный пример. Мы хотим перехватывать запросы с типичными орфографическими ошибками и заменять их на корректные. Для примера используем часто встречающиеся SLECT и CRATE

second_example.lua

 function read_query( packet )
   if string.byte(packet) == proxy.COM_QUERY then
     local query = string.sub(packet, 2)
     print ("received " .. query)
     local replacing = false
     -- matches "CRATE" as first word of the query
     if string.match(string.upper(query), '^%s*CRATE') then
         query = string.gsub(query,'^%s*%w+', 'CREATE')
         replacing = true
     -- matches "SLECT" as first word of the query
     elseif string.match(string.upper(query), '^%s*SLECT') then
         query = string.gsub(query,'^%s*%w+', 'SELECT')
         replacing = true
     end
     if (replacing) then
         print("replaced with " .. query )
         proxy.queries:append(1, string.char(proxy.COM_QUERY) .. query )
         return proxy.PROXY_SEND_QUERY
     end
   end
 end

Не забываем запустить прокси с параметром –proxy-lua-script=second_example.lua и присоединиться к нему из mysql-клиента:

$ mysql -u USERNAME -pPASSWORD -h 127.0.0.1 -P 4040
 Welcome to the MySQL monitor.  Commands end with ; or \g.
 Your MySQL connection id is 48
 Server version: 5.0.37-log MySQL Community Server (GPL)

 Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

 mysql> use test
 Database changed
 mysql> CRATE TABLE t1 (id int);         # Notice: TYPO!
 Query OK, 0 rows affected (0.04 sec)

 mysql> INSERT INTO t1 VALUES (1), (2);
 Query OK, 2 rows affected (0.01 sec)
 Records: 2  Duplicates: 0  Warnings: 0

 mysql> SLECT * FROM t1;                 # Notice: TYPO!
 +------+
 | id   |
 +------+
 |    1 |
 |    2 |
 +------+
 2 rows in set (0.00 sec)

Великолепно! Я сделал свои типичные ошибки, но, тем не менее, запросы прекрасно выполнились.. Давайте посмотрим отчет

received select @@version_comment limit 1
received SELECT DATABASE()
received CRATE TABLE t1 (id int)
replaced with CREATE TABLE t1 (id int)
received INSERT INTO t1 VALUES (1), (2)
received SLECT * FROM t1
replaced with SELECT * FROM t1

Первые два запроса выполнил клиент.. А затем запросы с типичными ошибками были переписаны: CRATE был успешно изменен на CREATE, а SLECT превратился в SELECT
Это достаточно простой скрипт, но он демонстрирует большие возможности и безграничный простор для экспериментов!

“Инъекции” в запросы
Далее мы рассмотрим уникальный механизм внедрения данных в запросы: query-инъекции. По мере надобности proxy может создавать очереди запросов, и после присвоения уникального ID каждому запросу, отсылать их на сервер.

На картинке сервер получает три запроса и, конечно же, возвращает три result set’а. Когда мы используем механизм инъекций, обработку результатов берет на себя функция прокси: read_query_result, в которой вы можете сопоставить наборы данных с идентификаторами. Например, для ID 2 и 3 вы только извлекаете из значения и определяете влияние основного запроса на сервер. Посколько вы используете эти значения только для внутренних вычислений, вы не отсылаете их клиенту, и это, собственно, правильно, так как клиент их и не ожидает.

Возвращенный результирующий набор данных в точности соответствует запросу клиента, но, абсолютно прозрачно для него, нам удалось собрать кое-какие статистические данные, которые и отображаются на консоли прокси. Более полное руководство по инъекциям вы можете найти в Injection Tutorial

Макросы
Макросы – это лишь один из способов применения “переписывания запроса”, но они являются одним из самых ярких примеров использования proxy. Вы можете изменить язык SQL или адаптировать его “под свой вкус”. Например, многие предпочитают использовать в командной строке cd и ls, вместо USE db; и SHOW TABLES;. Используя MySQL Proxy это возможно! Давайте попробуем написать свой первый макрос.

Создание Result set’a: команды shell из mysql-клиента
Proxy получает запрос от клиента и возвращает набор данных, в большинстве случаев так и происходит. Передача запроса на сервер, получение набора данных, возврат результатов клиенту. Но что если мы должны вернуть данные, которые сервер не может нам предоставить? Мы должны самостоятельно построить результирующий набор данных, состоящий из имен столбцов и двумерного массива с данными.

Основы создания result set’а
Например, если вы хотите вернуть предупреждение об устаревшей команде, вы можете использовать result set наподобие нижеследующего:

 proxy.response.resultset = {
     fields = {
         {
            type = proxy.MYSQL_TYPE_STRING,
            name = "deprecated feature",
         },
         {
            type = proxy.MYSQL_TYPE_STRING,
            name = "suggested replacement",
         },
     },
     rows = {
          {
             "SHOW DATABASES",
             "SHOW SCHEMAS"
          }
     }
 }
 -- and then, send it to the client
 return proxy.PROXY_SEND_RESULT

В результате клиент получит следующий result set:

+---------------------+-----------------------+
| deprecated feature  | suggested replacement |
+---------------------+-----------------------+
| SHOW DATABASES      | SHOW SCHEMAS          |
+---------------------+-----------------------+

Как видите, мы можем построить любой, необходимый нам, результирующий набор данных. За примерами обращайтесь к Jan Kneschke

Системый командный интерпретатор в mysql-клиенте
А теперь нечто совсем другое! Давайте посмотрим, как можно использовать только что полученные нами знания для выполнения команд оболочки через прокси. Как говорилось выше (и как вы уже могли заметить :)) поведение прокси-сервера может быть изменено при помощи lua-скриптов. LUA является полноценным языком программирования, поэтому вы можете делать на нем все, что угодно. В том числе и исполнять shell-команды. Связав этот факт с возможностью построения собственных result set’ов мы пришли к тому, что неплохо было бы обращаться к оболочке напрямую из командной строки mysql-клиента, возвращая данные в виде классического result set’а

Наш сценарий будет использовать следующий синтаксис для выполнения команд оболочки:

SHELL command

Например:
SHELL ls -lh /usr/local/mysql/data

1. Загрузите учебный сценарий
2. Запустите прокси
3. Соединитесь с прокси

$ /usr/local/sbin/mysql-proxy –proxy-lua-script=shell.lua -D

# from a different console
$ mysql -U USERNAME -pPASSWORD -h 127.0.0.1 -P 4040

Убедитесь, что все работает нормально

 Welcome to the MySQL monitor.  Commands end with ; or \g.
 Your MySQL connection id is 49
 Server version: 5.0.37-log MySQL Community Server (GPL)

 Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

 mysql> use test
 Database changed
 mysql> show tables;
 +----------------+
 | Tables_in_test |
 +----------------+
 | t1             |
 +----------------+
 1 row in set (0.00 sec)

 mysql> select * from t1;
 +------+
 | id   |
 +------+
 |    1 |
 |    2 |
 +------+
 2 rows in set (0.00 sec)

Отлично, обычные операции работают нормально. Теперь протестируем наши расширенные возможности:

 mysql> shell df -h;
 +--------------------------------------------------------+
 | df -h                                                  |
 +--------------------------------------------------------+
 | Filesystem            Size  Used Avail Use% Mounted on |
 | /dev/md1               15G  3.9G  9.7G  29% /          |
 | /dev/md4              452G  116G  313G  27% /app       |
 | tmpfs                 1.7G     0  1.7G   0% /dev/shm   |
 | /dev/md3              253G  159G   82G  67% /home      |
 | /dev/md0               15G  710M   13G   6% /var       |
 +--------------------------------------------------------+
 6 rows in set (0.00 sec)

Привет, шелл! :) Теперь вы можете работать намного эффективнее…

 mysql> shell grep key_buffer /usr/local/mysql/my.cnf;
 +-----------------------------------------+
 | grep key_buffer /usr/local/mysql/my.cnf |
 +-----------------------------------------+
 | key_buffer=2000M                        |
 +-----------------------------------------+
 1 row in set (0.00 sec)

Конечно, тот же результат можно было бы получить из запроса SHOW VARIABLES;, но наша задача – показать, что в клиенте mysql мы имеем полноценный shell!

 mysql> shell free -m;
 +---------------------------------------------------------------------------+
 | free -m                                                                   |
 +---------------------------------------------------------------------------+
 |              total       used       free     shared    buffers     cached |
 | Mem:          3280       1720       1560          0          9       1006 |
 | -/+ buffers/cache:        704       2575                                  |
 | Swap:         8189          2       8186                                  |
 +---------------------------------------------------------------------------+
 4 rows in set (0.08 sec)

Неплохо. Но все это лежит на нашем же сервере.. А как насчет работы с сетью? Для примера мы посмотрим последние 20 записей на Планете MySQL

   wget -q -O - http://www.planetmysql.org/rss20.xml  \
      | perl -nle 'print $1 if m{}' \
      |head -n 21 | tail -n 20;

Да, длинновато немного, но это реально работает!

 mysql> shell last_planet.sh;
 +-------------------------------------------------------------------------------------+
 | last_planet.sh                                                                      |
 +-------------------------------------------------------------------------------------+
 | Top 5 Wishes for MySQL                                                              |
 | Open Source ETL tools.                                                              |
 | MySQL Congratulates FSF on GPLv3                                                    |
 | Query cache is slow to the point of being unusable - what is being done about that. |
 | About 'semi-unicode' And 'quasi Moon Stone'                                         |
 | My top 5 MySQL wishes                                                               |
 | Four more open source startups to watch                                             |
 | More on queue... Possible Solution...                                               |
 | MySQL as universal server                                                           |
 | MySQL Proxy. Playing with the tutorials                                             |
 | Open source @ Oracle: Mike Olson speaks                                             |
 | Quick musing on the "Queue" engine.                                       |
 | Distributed business organization                                                   |
 | Ideas for a MySQL queuing storage engine                                            |
 | MySQL Test Creation Tool Design Change                                              |
 | Queue Engine, and why this won' likely happen...                                    |
 | What?s your disk I/O thoughtput?                                                    |
 | My 5+ Wish List?                                                                    |
 | Top 5 best MySql practices                                                          |
 | Packaging and Installing the MySQL Proxy with RPM                                   |
 +-------------------------------------------------------------------------------------+
 20 rows in set (1.48 sec)

Доступ к командной строке и Internet из mysql-клиента… Впечатляет :)

Пару слов об осторожности
Разрешая доступ к командной строке вы можете получить кучу неприятностей. Тщательно следите за разделением доступа и контролируйте выполнение потенциально опасных shell-команд. Иначе вы можете в одночасье лишиться результатов долгой кропотливой работы…

Например:

 mysql> shell ls *.lua*;
 +---------------------+
 | ls *.lua*           |
 +---------------------+
 | first_example.lua   |
 | first_example.lua~  |
 | second_example.lua  |
 | second_example.lua~ |
 +---------------------+
 4 rows in set (0.03 sec)

 mysql> shell rm *~;
 Empty set (0.00 sec)

 mysql> shell ls *.lua*;
 +--------------------+
 | ls *.lua*          |
 +--------------------+
 | first_example.lua  |
 | second_example.lua |
 +--------------------+
 2 rows in set (0.01 sec)

Будьте осторожны!!!
Помните, что таким способом вы получаете доступ к командному интерпретатору хоста на котором запущен proxy, а не сервер баз данных. Это очень частая ошибка!!!

Выборочное логирование
Я оставил этот пример напоследок, поскольку (судя по моему опыту) он является наиболее интересным и даже имеет практическое применение! В MySQL 5.1 у вас есть возможность вести такие логи средствами самой СУБД, а если у вас версия 5.0, то proxy поможет вам :)
Для помещения запросов в общий лог-файл просто поместите следующий код в файл simple_logs.lua или скачайте его с MySQL Forge.

 local log_file = 'mysql.log'
 local fh = io.open(log_file, "a+")

 function read_query( packet )
   if string.byte(packet) == proxy.COM_QUERY then
     local query = string.sub(packet, 2)
     fh:write( string.format("%s %6d -- %s \n",
         os.date('%Y-%m-%d %H:%M:%S'),
         proxy.connection["thread_id"],
         query))
     fh:flush()
   end
 end

Запустите прокси и соединитесь с ним из нескольких различных клиентов. Сценарий будет записывать запросы в файл с именем mysql.log После завершения всех сессий файл будет выглядеть примерно так:

 2007-06-29 11:04:28     50 -- select @@version_comment limit 1
 2007-06-29 11:04:31     50 -- SELECT DATABASE()
 2007-06-29 11:04:35     51 -- select @@version_comment limit 1
 2007-06-29 11:04:42     51 -- select USER()
 2007-06-29 11:05:03     51 -- SELECT DATABASE()
 2007-06-29 11:05:08     50 -- show tables
 2007-06-29 11:05:22     50 -- select * from t1
 2007-06-29 11:05:30     51 -- show databases
 2007-06-29 11:05:30     51 -- show tables
 2007-06-29 11:05:33     52 -- select count(*) from user
 2007-06-29 11:05:39     51 -- select count(*) from columns

Лог содержит дату, время, ID соединения и сам запрос. Просто и эффективно для короткого сценария. Надо заметить, что есть три сессии и запросы из них не отсортированы по ID, но расположены по времени выполнения.

Приятно, что вам не надо перезагружать сервер для включения логирования… Все, что необходимо, это перенаправить все запросы с порта 3306 (стандартного порта mysql-сервера) на порт 4040 (стандартный порт MySQL Proxy). И вам не нужно трогать сервер или какие-то приложения.. Одно просто правило для iptables поможет вам:

sudo iptables -t nat -I PREROUTING \
-s ! 127.0.0.1 -p tcp \
–dport 3306 -j \
REDIRECT –to-ports 4040

Теперь у вас включено логирование, а приложения-клиенты и сервер даже не заметили этого!! После того, как потребность в логировании отпадет просто удалите правило при помощи ключа -D и остановите прокси

sudo iptables -t nat -D PREROUTING \
-s ! 127.0.0.1 -p tcp \
–dport 3306 -j \
REDIRECT –to-ports 4040

Еще больше возможностей для логирования
Предыдущий пример с ведением журналов прост и нагляден но, к сожалению, действительно слишком прост. Мы могли бы иметь гораздо более подробную информацию в логах: количество успешных и неуспешных запросов, количество запросов с синтаксическими ошибками, количество переданных или затронутых строк.

Попробуем это реализовать. Это сценарий уже побольше предыдущего

 -- logs.lua
 assert(proxy.PROXY_VERSION >= 0x00600,
  "you need at least mysql-proxy 0.6.0 to run this module")

 local log_file = os.getenv("PROXY_LOG_FILE")
 if (log_file == nil) then
   log_file = "mysql.log"

 end

 local fh = io.open(log_file, "a+")
 local query = "";

Сначала мы проверяем версию прокси (так как мы используем возможности, которых нет в 0.5.0) и устанавливаем имя файла (забирая его из переменной окружения или присваивая значение по умолчанию)

 function read_query( packet )
   if string.byte(packet) == proxy.COM_QUERY then
     query = string.sub(packet, 2)
     proxy.queries:append(1, packet )
     return proxy.PROXY_SEND_QUERY
   else
       query = ""

   end
 end

Первая функция совсем проста – она добавляет запрос к очереди, чтобы следующая функция сработала, когда поступит результат.

 function read_query_result (inj)
   local row_count = 0
   local res = assert(inj.resultset)
   local num_cols = string.byte(res.raw, 1)
   if num_cols > 0 and num_cols < 255 then
     for row in inj.resultset.rows do
       row_count = row_count + 1
     end
   end
   local error_status =""
   if res.query_status and (res.query_status < 0 ) then
       error_status = "[ERR]"

   end
   if (res.affected_rows) then
       row_count = res.affected_rows
   end
   --
   -- write the query, adding the number of retrieved rows
   --
   fh:write( string.format("%s %6d -- %s {%d} %s\n",
     os.date('%Y-%m-%d %H:%M:%S'),
     proxy.connection["thread_id"],
     query,
     row_count,
     error_status))
   fh:flush()
 end

В этой функции мы проверяем, имеем мы дело с запросом на выборку или же изменяются какие-то данные. В лог-файл записывается количество возвращенных строк. Если есть измененные строки, их количество также будет отображено в логе, и, наконец, все данные о произошедших ошибках тоже не останутся без внимания. Вот пример лога:

 2007-06-29 16:41:10     33 -- show databases {5}
 2007-06-29 16:41:10     33 -- show tables {2}
 2007-06-29 16:41:12     33 -- Xhow tables {0} [ERR]
 2007-06-29 16:44:27     34 -- select * from t1 {6}
 2007-06-29 16:44:50     34 -- update t1 set id = id * 100 where c = 'a' {2}
 2007-06-29 16:45:53     34 -- insert into t1 values (10,'aa') {1}
 2007-06-29 16:46:07     34 -- insert into t1 values (20,'aa'),(30,'bb') {2}
 2007-06-29 16:46:22     34 -- delete from t1 {9}

Первая, вторая и четвертая строчки описывают, что сервер вернул, соотвественно, пять, две и шесть строк в ответ. Третья говорит об ошибке. В пятой строки мы видим, что команда UPDATE затронула две строки. Остальные строки описывают "последствия" команд INSERT и DELETE

Оригинал: http://www.oreillynet.com/pub/a/databases/2007/07/12/getting-started-with-mysql-proxy.html

MySQL Proxy распросраняется под лицензией GPL

Синтаксис командной строки

$ mysql-proxy --help-all

Использование:

  mysql-proxy [OPTION...] - MySQL Proxy
Опции справки:

  -?, --help                                          Показать краткую справку
  --help-all                                          Показать все пункты справки
  --help-admin                                        Показать ключи для модуля admin
  --help-proxy                                        Показать ключи для модуля proxy

Модуль admin

  --admin-address=<host:port>                         Слушать заданный адрес:порт для внутреннего модуля администрирования (по умолчанию: :4041)

Модуль proxy

  --proxy-address=<host:port>                         Адрес:порт прокси-сервера (по умолчанию: :4040)
  --proxy-read-only-backend-addresses=<host:port>     Адрес:порт удаленного дополнительного сервера (по умолчанию: не задан)
  --proxy-backend-addresses=<host:port>               Адрес:порт удаленных backend-серверов (по умолчанию: 127.0.0.1:3306)
  --proxy-skip-profiling                              отключить профилирование запросов (по умолчанию: включено)
  --proxy-fix-bug-25371                               исправить ошибку #25371 (mysqld > 5.1.12) для старых версий libmysql
  --proxy-lua-script=<file>                           имя lua-скрипта (по умолчанию: не задано)
  --no-proxy                                          Не стартовать прокси-сервер

Опции приложения:

  -V, --version                                       Показать версию
  --daemon                                            Запускаться в режиме демона
  --pid-file=<file>                                   PID-файл (в случае запуска в режиме демона)

Соединение
В качестве простого примера запустите mysql-proxy и попробуйте присоединиться к ней с помощью клиента:

$ mysql-proxy &
$ mysql –host=127.0.0.1 –port=4040 –user=… –password

Подключение будет проксировано на адрес 127.0.0.1 и порт 3306
ВАЖНО: сервер MySQL должен иметь версию 5.0.x и выше. Работа с версиями 4.1 официально не поддерживается, но если вы решите использовать эту связку, то не забудьте отослать репорты об ошибках

Модуль Proxy
Модуль Proxy состоит из двух частей:

• Ядро, написанное на C
• Интерфейс на lua

Ядро обрабатывает пересылку пакетов на низком уровне и пытается работать настолько быстро, насколько это возможно, оно обрабатывает более тысячи параллельных соединений одновременно. Ядро состоит из:

• обработчика конфиг-файла
• шифровщика протокола mysql
• обработчика сокетов
• балансировщика нагрузки
• реализации механизма failover

 $ mysql-proxy --help-proxy
 Использование:
   mysql-proxy [OPTION...] - MySQL Proxy

 proxy-module
   --proxy-address=<ip:port>               слушать адрес:порт прокси-сервера (по умолчанию: :4040)
   --proxy-read-only-address=<ip:port>     Слушать адрес:порт для соединений только для чтения (по умолчанию: :4042)
   --proxy-backend-addresses=<ip:port>     Адрес:порт для удаленных backend-серверов (по умолчанию: не задан)
   --proxy-profiling                       включить профилирование запросов
   --proxy-fix-bug-25371                   исправить ошибку #25371 (mysqld > 5.1.12) для старых версий libmysql
   --proxy-lua-script=<file>               расположение lua-скрипта (по умолчанию: не задан)

–proxy-address – это адрес и порт сервера, который транслирует запросы к одному из backend-серверов.
Backend-сервер, объявленный при помощи –proxy-backend-addresses по умолчанию имеет значение 127.0.0.1:3306. Вы можете использовать эту опцию несколько раз и задать нужное количество серверов.

Admin server
Сервер администрирования реализует основные возможности протокола mysql и может отвечать на некоторые базовые запросы. В нем реализованы:

• Обработка сокетов
• Жизненный цикл соединения
• mysql wire-протокол
• len-encoding (?) некоторых полей
• Типы полей
• Результирующие наборы данных

Дизайн основывается на идеях, заимствованных из lighttpd и использует неблокирующий сетевой ввод/вывод, сетевой протокол основан на информации, доступной во внутренних документах с dev.mysql.com
В admin server реализованы 2 базовых запроса, которые доступны из командной строки mysql-клиента:

select @@version_comment LIMIT 1;
select USER();

Используя admin server, вы можете реализовать необходимую функциональность, чтобы любой mysql-клиент (php, jdbc, odbc, perl, …) мог использовать его.
Мы используем его для экспорта текущей конфигурации и отслеживания открытых соединений.

> select * from proxy_connections;
+------+--------+-------+-------+
| id   | type   | state | db    |
+------+--------+-------+-------+
|    2 | proxy  | 8     | world |
|    3 | server | 8     |       |
+------+--------+-------+-------+

> select * from proxy_config;
+---------------------------------+----------------+
| option                          | value          |
+---------------------------------+----------------+
| admin.address                   | :4041          |
| proxy.address                   | :4040          |
| proxy.backend_addresses[0]      | 127.0.0.1:3306 |
| proxy.backend_addresses[1]      | 127.0.0.1:3307 |
| proxy.fix_bug_25371             | 0              |
| repclient.master_address        |                |
+---------------------------------+----------------+

Балансировка нагрузки и failover

$ mysql-proxy \
–proxy-backend-addresses=10.0.1.2:3306 \
–proxy-backend-addresses=10.0.1.3:3306 &

Запустите тестовые соединения, остановите один из backend-серверов и вы увидите, как весь трафик будет передан второму, который продолжает работать.

Расширение lua
MySQL Proxy поддерживает язык lua. Это маленький встраиваемый и очень удобный язык. На mysql.com есть репозиторий скриптов для MySQL Proxy

На рисунке изображены состояния работы сервера с клиентом

При помощи lua-скриптов вы можете “вклиниться” в три стадии:

• connect_server
• read_query
• read_query_result

Если вы хотите написать балансировщик нагрузки, то вы можете “вклиниться” в connect_server, который вызывается перед соединением с backend-сервером. Балансировщик может выбрать backend из списка, который был задан при запуске прокси.

read_query – это стадия между передачей запроса от клиента серверу. На этой стадии вы можете решить что делать с запросом: передать клиенту “как есть”, изменить его, добавить еще запросов или напрямую ответить клиенту без передачи запроса на сервер.

Например, вы можете “дампить” все данные, передаваемые между клиентом и сервером (после авторизации):

 (sqf) taking 127.0.0.1:3306, clients: 0
 .---  mysql result packet
 | query.len = 13
 | query.packet = 03 73 68 6f 77 20 65 6e 67 69 6e 65 73
 | .--- query
 | | command = COM_QUERY
 | | query = "show engines"
 | '---
 |
 | result.len = 1
 | result.packet = 06
 | .---
 | | command = COM_QUERY
 | | num-cols = 6
 | | field[0] = { type = 253, name = Engine }
 | | field[1] = { type = 253, name = Support }
 | | field[2] = { type = 253, name = Comment }
 | | field[3] = { type = 253, name = Transactions }
 | | field[4] = { type = 253, name = XA }
 | | field[5] = { type = 253, name = Savepoints }
 | | row[0] = { ndbcluster, DISABLED, Clustered, fault-tolerant tables, YES, NO, NO }
 | | row[1] = { MRG_MYISAM, YES, Collection of identical MyISAM tables, NO, NO, NO }
 | | row[2] = { BLACKHOLE, YES, /dev/null storage engine (anything you write to it disappears), NO, NO, NO }
 | | row[3] = { CSV, YES, CSV storage engine, NO, NO, NO }
 | | row[4] = { MEMORY, YES, Hash based, stored in memory, useful for temporary tables, NO, NO, NO }
 | | row[5] = { FEDERATED, YES, Federated MySQL storage engine, YES, NO, NO }
 | | row[6] = { ARCHIVE, YES, Archive storage engine, NO, NO, NO }
 | | row[7] = { InnoDB, YES, Supports transactions, row-level locking, and foreign keys, YES, YES, YES }
 | | row[8] = { MyISAM, DEFAULT, Default engine as of MySQL 3.23 with great performance, NO, NO, NO }
 | '---
 '---

Для более глубокого изучения работы MySQL Proxy мы рекомендуем статью Getting started with MySQL Proxy (Перевод)

Оригинал: http://forge.mysql.com/wiki/MySQL_Proxy

Действительно, существует очень много ситуаций, в которых сервер падает или не отвечает на запросы. Причем ситуации эти существуют для любых версий MySQL и их можно воспроизвести, обладая базовыми привилегиями для доступа к sql-серверу.

Мы часто помогаем людям исправлять ошибки в их приложениях, использующих MySQL (но положа руку на сердце можно сказать – в большинстве случаев они сами являются причиной некорректной работы сервера) и ошибки эти очевидны.

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

Такое положение вещей будет сохраняться все время, пока MySQL использует Глобальное Управление Ресурсами, и вы реально не можете контролировать количество ресурсов, доступных вашим пользователям.

Вы можете возразить, что это, в принципе, не катастрофа. Конечно, но сервер можно еще перегрузить и сделать его недоступным. Или заставить MySQL использовать всю доступную память, в результате чего сервер будет просто убит операционной системой. На 32-битных системах провести подобные трюки гораздо легче.

Дам вам несколько советов:
Временные таблицы вы можете использовать запросы с производными таблицами и создавать в памяти неограниченное количество временных таблиц с неограниченным размером.

Таблицы в памяти Если вы можете создать в памяти одну таблицу, значит вы можете создать любое количество. Хотя размер таблицы ограничен директивой max_heap_table_size, общий размер таблиц не ограничен никак. Вы можете создавать таблицы как TEMPORARY и их не будет в файловой системе.

MyISAM Sort Buffer – обычно его размер устанавливают довольно большим, но он может одновременно работать только с несколькими таблицами. А что будет, если пользователь использует все его дозволеные 100 подключений для инструкции ALTER для 100 разных таблиц? Можно искусственно ограничить его занижением значения параметра myisam_sort_buffer_size, но это отразится на производительности.

Количество подготовленных инструкций (Prepared Statements) – к счастью теперь есть лимит на максимальное количество подготовленных инструкций (параметр max_stmt_count), который задается сервером. Это лучше, чем было раньше, когда можно было заставить сервер использовать всю доступную память, просто забыв закрыть подготовленные инструкции. Однако ограничения для пользователя отсутствуют и один пользователь может исчерпать весь лимит, заблокировав доступ к использованию подготовленных инструкций для остальных. Кроме того, не все инструкции занимают одинаковое количество памяти и подготовка сложных инструкций может отнять бoльшую часть ресурсов. Решить проблему можно, ограничив использование подготовленных инструкций и установив параметр max_prepared_stmt_count в очень низкое значение.

Подготовленные инструкции и BLOB-данные – если вы хотите получить память, занятую одной подготовленной инструкцией, вы можете создать инструкцию с тысячей меток (placeholders) и посылать данные каждой из них, используя вызов mysql_stmt_send_long_data. Буферы сервера будут принимать данные до тех пор, пока инструкция не будет выполнена.

Утечки кэша таблиц Innodb – InnoDB никогда не ограничивает размер внутренних таблиц в кеше (словарь данных). Так что открывая большие таблицы и работая с ними вы можете исчерпать всю доступную память. Обычно размер 4-8К на таблицу, но сложные таблицы могут занимать и больше. В основном это проблема небольших серверов.

Кэш Слитых таблиц – кэш таблиц обычно распределен и каждая запись обычно соответствует не более, чем паре файловых дескрипторов. Но не в случае Слитых таблиц – создание и доступ к нескольким слитым таблицам с, например, тысячей подтаблиц не лучшим образом скажется на вашем сервере. Тоже самое относится и к Разделенным талицам из MySQL 5.1

Место на диске – для MyISAM-таблиц хостинг-провайдеры обычно используют дисковые квоты. Вы можете использовать похожий подход при помощи innodb_file_per_table. Однако вы не можете контролировать рост системных таблиц InnoDB, которые используются для хранения данных об отменах и которые могут увеличиваться с каждой открытой транзакцией и делать множество обновлений. Или просто сохранять транзакцию открытой и позволять другим пользователям делать обновления – InnoDB может только очистить данные после старых транзакций, нуждающихся в мгновенном коммите. Вы можете решить этот вопрос путем уничтожения слишком старых транзакций, но более верным решением будет установление некоего лимита на объем хранимой информации о отменах. Еще один неплохой способ – это использовать запросы с большими временными таблицами или сортировкой файлов. Даже если временные таблицы будут храниться на другом разделе, при его переполнении другие пользователи не смогут нормально работать с сервером.

Хранимые процедуры – сколько памяти можно выделить для хранимой процедуры? Можно создать 1000 переменных в хранимой процедуре и зарезервировать для каждой их них по 1М памяти. Я не проводил целенаправленных экспериментов, но думаю, что жесткой политики выделения памяти для хранимых процедур нет.

Указатели в хранимых процедурах – указатели в хранимых процедурах реализованы в виде временных таблиц. Поэтому используя большое количество указателей можно заполнить доступный объем оперативной памяти.

Рекурсия в хранимых процедурах – На самом деле отличается от “классического” представления рекурсии. Это всего лишь вызовы одной процедуры из другой. Которые так же требуют выделения памяти и, что важно, размещаются в стеке. Есть некоторые способы для защиты от переполнения стека, но они не могут гарантировать 100%-ного результата.

Переменные на стороне сервера – каждый сервер имеет ограничение в виде директивы max_allowed_packet (1M по умолчанию). Но, по-видимому, нет никаких ограничений на количество создаваемых переменных.

Разбор деревьев – внутренне представление запросов в MySQL выглядит как разбор дерева, которое зависит от размера запроса, который, в свою очередь, контролируется директивой max_allowed_packet. Но некоторые способы оптимизации MySQL (такие как equity propagation и range expansion) могут привести к критическим ошибкам при анализе дерева. Для нескольких тривиальных случаев такое поведение было исправлено, но вызывает сомнения, что эти исправления актуальны для всех подобных ситуаций.

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

Блокировка хоста – сервер может заблокировать хост клиента из-за большого количества неудачных соединений. Этого можно избежать, выставив большое значение для параметра max_connect_errors, но будьте осторожны: это снизит устойчивость к брутфорсу.

Взаимные исключения – как InnoDB, так и MyISAM имеют “хотспоты” с несколькими соединениями. Используя их можно существенно замедлить работу сервера.

Перегрузка – у MySQL нет достаточного контроля за использованием ресурсов и вы можете “положить” сервер просто выполняя тяжелые запросы. Существующие ограничения не могут полностью контролировать потребление ресурсов пользователем, поскольку не имеют механизма определения “тяжести” запроса. Тяжелые запросы могут сильно нагрузить систему ввода/вывода и заполнить кэш ОС, что заметно снизит скорость работы сервера и запросы других пользователей будут выполняться на порядок медленнее.

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

Как вы видите, MySQL-сервер отнюдь не выглядит “пуленепробиваемым”, если кто-то намеренно будет пытаться его обрушить. Дело в том, что большинство существующих ограничений (таких как max_heap_table_size или max_prepared_stmt_count) реализованы для защиты от типичных ошибок при разработке приложений, а отнюдь не от запланированной атаки

Примечание: я рассмотрел лишь некоторые из объектов сервера, т.е. снижение производительности при некорректной работе с каждым из них. Существует ряд глобальных квот, которые влияют на работу сервера в целом – вы не можете применить их для конкретного пользователя или соединения.

P.S.: вы можете подумать: “как же это все возможно, если существуют тысячи хостинг-провайдеров, предоставляющих доступ к своим серверам БД?” Да, некоторым везт и их пользователи не создают проблем для корректной работы MySQL, но большинству приходится “вручную” постоянно контролировать и ограничивать пользователей, мешающих нормальному функционированию. Не говоря о компаниях, предоставляющих вирутальный хостинг – там, как правило, используются старые версии ПО, имеющие куда больше проблем.

P.P.S.: ничего из вышеописанного не является “новостью” для команды разработчиков MySQL. Эта заметка – лишь попытка осветить некоторые аспекты безопасности и обеспечения корректной работы MySQL-сервера.

Оригинал: http://www.mysqlperformanceblog.com/2007/11/13/10-ways-to-crash-or-overload-mysql/

#!/bin/bash
while [ 1 ]
do
mysql -N -u root -p password -e ‘show processlist’ |grep -v ‘show processlist’
sleep 2
done

Примечание: Замените password на ваш пароль.
Примечание: -N убирает заголовки полей

Скрипт не показывает сам вывод команды SHOW PROCESSLIST. Вы также можете исключить из вывода спящие процессы, модифицировав сценарий следующим образом:

mysql -N -u root -ppassword -e ’show processlist’ |egrep -v ‘Sleep|show processlist’

Этот скрипт далеко не идеален, и уж тем более, не “одинок”. Существует мощная утилита mtop, с бОльшей функциональностью. Но она написана на perl, а его не слишком люблю :) Вероятно, что именно у меня не получилось заставить ее работать так, как хотелось бы мне. Лично я предпочел ей простое решение на bash, потому что я отнюдь не матерый perl-хакер.

Вы также можете использовать лог медленных запросов, но предложенный мной способ лучше подходит для поиска узких мест. Лог медленных запросов не показывает причину “замедленности” запроса, запись попадет в него уже после завершения запроса.

Оригинал: http://blog.taragana.com/index.php/archive/monitoring-mysql-queries-using-bash-script/

Hardware
Если у вас есть база данных innodb большого объема, и это действительно важные данные, то 16 – 32 GB оперативной памяти будут оптимальным решением. Процессоры – 2*DualCore подойдут для большой нагрузки, а два Quad Core помогут решить проблемы с дальнейшим масштабированием системы. Хотя имеется множество нюансов. Третий момент – это подсистема ввода/вывода. Напрямую подключенный DataStorage с большим количеством дисков и RAID с возможностью сохранения кэша будут отличным выбором. Обычно необходимо 6 – 8 жестких дисков в стандартный блок, но порой может понадобиться и больше. Также обратите внимание на новые 2.5” SAS диски. Они меньше, но часто работают гораздо быстрее, чем обычные HDD. RAID10 хорошо подходит как для хранения, так и для чтения данных, но в случае, если вы можете позволить некоторую избытычность. В противном случае можно сделать RAID5, но опасайтесь случайных записей.

Операционная система
Дя начала: установите 64-битную операционную систему. Часто можно увидеть 32-битный linux, или запущенный в режиме совместимости с 64-bit. Не делайте так. Если вы используете LVM для хранения базы данных, вы сможете более эффективно работать с резервными копиями. Файловая система Ext3 будет оптимальным выбором в большинстве случаев, но если вы запускаете particular roadblocks, то попробуйте XFS. Вы можете использовать опции noatime и nodiratime, если вы используете innodb_file_per_table и большое количество таблиц, но это, в принципе, не столь важно. Также убедитесь, что OS резервирует достаточно большое количество памяти для MySQL.

Опции MySQL InnoDB
Важнейшими опциями являются:
innodb_buffer_pool_size – 70 – 80% оперативной памяти. Я ставлю это значение в 12G на системе с 16G RAM
innodb_log_file_size – зависит от необходимого вам объема данных для восстановления, но 256МБ будут разумным компромиссом между производительностью и рамером лог-файла
innodb_log_buffer_size=4M – 4 мегабайта – нормальное значение, если вы не используете подачу больших блоков данных в InnoDB через каналы (pipes). Если используете, это значение лучше увеличить.
innodb_flush_logs_at_trx_commit=2 – если вас не особо заботит ACID, и вы можете себе позволить потерять транзакции за последние секунду или две, в случае полного краха ОС, то установите это значение. Но это может повлечь печальные эффекты при коротких записях транзакций.
innodb_thread_concurrency=8 – даже при имеющихся InnoDB Scalability Fixes будет совсем не лишним иметь ограниченное количество потоков. Значение может быть больше или меньше в зависомости от ваших потребностей, но 8 будет оптимальным значением для начала.
innodb_flush_method=O_DIRECT – избегайте двойной буферизации и уменьшите активность swap, в большинстве случаев это увеличивает производительность. Но будьте осторожны, если у вас нет RAID с возможностью сохранения данных, операции ввода-вывода могут проходить некорректно и данные могут быть повреждены.
innodb_file_per_table – если у вас немного таблиц, используйте эту опцию и рост занимаемого таблицами места не будет бесконтрольным. Эта опция добавлена в MySQL 4.1 и сейчас достаточно стабильна для использования.

Проверьте также, могут ли ваши приложения запускаться в режиме изоляции READ-COMMITED. Если это так, то установите опцию transaction-isolation=READ-COMITTED. Этот вариант увеличит производительность.

Есть еще немало опций, значения которых можно поменять для достижения лучшей производительности. Об этом можно прочитать в заметке Настройка опций mysql-server (перевод) или в одной из наших презентаций.

Настройка приложений для работы с InnoDB
При переходе с типа MyISAM, вам конечно будет интересно, что изменилось и какие новые возможности вам теперь доступны. Во-первых: убедитесь, что вы используете транзакции при обновлениях. Это необходимо для повышения производительности. Во-вторых: готово ли ваше приложение обрабатывать проблемы, которые могут произойти? И в-третьих: возможно вы захотите пересмотреть структуру своих таблиц и посмотреть как вы можете использовать свойства InnoDB: распределение по первичному ключу, использование первичного ключа на всех индексах (это позволяет сократить первичеый ключ), быстрый просмотр по первичным ключам (попробуйте использовать это при запросах с JOIN) или большие несжаты индексы (облегчают индексирование).

При помощи этого краткого описания вы сможете провести первичную настройку InnoDB, которая повысит производительность на системах без battery backup, без изменения настроек ОС и не внося изменения в настройки приложений, до сих пор использующих MyISAM

Оригинал: http://www.mysqlperformanceblog.com/2007/11/01/innodb-performance-optimization-basics/

P.S.: Буду благодарен за корректный перевод словосочетания particular roadblocks.

Пул буферов InnoDB – это очень важный параметр и для него должно быть выбрано правильное значение. Мне приходилось видеть множество людей, которые оставляли значение по умолчанию (8М) и получали из-за этого проблемы. Если у вас есть выделенный сервер для MySQL и вы используете только innodb-таблицы, возможно вы захотите отдать всю неиспользуемую память для пула буферов InnoDB.

Конечно же предполагается, что размер ваших InnoDB-таблиц достаточно велик для большого размера пула. Если нет, то установите размер пула немного большим, чем размер ваших таблиц. Несомненно, стоит учесть дальнейшее увеличение объема ваших баз данных. Размер пула должен быть немного (скажем, на 10%) большим, чем размер ваших таблиц, потому что в нем содержатся не только сами таблицы, но также и индексы, вставленные буферы, блокировки, которым тоже необходимо некоторое количество памяти. Но это не очень критично. На большинстве задач размер пула, меньший чем 10% особо не отразится на производительности.

Также вы можете исходить из того, что объем базы данных уже больше, чем объем имеющейся памяти. Но не забывайте корректировать его. Так же это будет хорошим выбором в том случае, если у вас выделенный сервер для MySQL и нет иных задач, требующих оперативной памяти.

Необходимо помнить о том, что InnoDB выделяет немного больше памяти для хранения пула, чем задано в конфигурации – я только что проверил на наших серверах с размером буфера 12GB и очень маленьким дополнительным буфером и лог-буфером. InnoDB занимал там немного больше 13GB. Некоторое время назад Вадим писал об этом.

После того, как вы определились с размером баз данных, проверьте, нет ли каких-либо ограничений для размера пула, который вы хотите использовать. Обычно подобные ограничения возникают на 32-битных системах, но бывают и неожиданные сюрпризы, особенно в среде Windows. Обычно подобные ограничения распространяются на общий размер памяти, который может использовать процесс. При подборе оптимального значения убедитесь в том, что вы оставили некоторое количество памяти для остальных нужд MySQL.

Следующий шаг, который необходимо сделать – это рассчитать объем памяти, необходимый остальным приложениям. Это могут быть нужды операционной системы – системные процессы, буферы сокетов и так далее :) Всем нужна память. Я использую примерно такие интервалы: от 256MB (на маленьких системах) до 5% от всего объема (соответсвенно, на больших :)). Хотя реальные потребности могут быть и меньше. Помимо ОС самому серверу MySQL также необходима дополнительная память – это буферы MySQL, кэш запросов, key_buffer, нити, временные таблицы, буферы сортировки в нитях. На это тоже необъодимо выделить память. Также подумайте о доаолнительных буферах InnoDB (которые могут занимать бОльший объем памяти, чем вы установили для них. Особенно если у вас много таблиц).

Я мог бы начать приводить вам какие-то цифры. Например, сложите все ваши глобальные буферы и добавьте по 1 мегабайту на каждое планируемое соединение. Но в реальности эти числа могут сильно отличаться – все зависит от конкретных задач. К примеру неактивные соединения будут потреблять меньше памяти, чем работающие с временными таблицами. Или чем другие более сложные запросы к БД. Как правило, это гораздо проще и быстрее проверить на практике. Запустите mysql-server с буфером размером 10GB для начала и посмотрите, как увеличиваются RSS и VSZ (их значения можно увидеть в выводе команды `ps` на Unix-системах). Если буфер увеличился до 12GB, а вам необходимо 2GB под иные задачи, вы сможете немнго увеличить его размер, в соответствии с вашими потребностями.

Третий важный момент, о котором необходимо помнить – это кэш операционной системы. Даже если вы и исключили ваши InnoDB-таблицы из кэша ОС, есть и другие процессы, которым этот кэш необходим: таблицы MyISAM (собственные баз данных mysql, временные таблицы и так далее), frm-файлы, логи.. Логи транзакций InnoDB тоже неплохо кэшировать там. Ну и конечно же у вас есть системные процессы, которым тоже необходимо некоторое количество кэш-памяти. Значение этого параметра сильно варьируется в зависимости от системы и задач. Обычно значения этого параметра лежат в диапазоне от 200MB до 1GB.

Отключите двойную буферизацию – это опять-таки очень важно для выбора размера пула. Вы же не хотите, чтобы операционная система кэшировала данные, уже находящиеся в кэше InnoDB. Собственный кэш более эффективен, чем кэш ОС, так как он не копирует данные, адаптирует хэш-индексы, позволяет писать в буферы.. Есть множество факторов, чтобы отказаться от использования двойной буферизации. Тем более, как уже говорилось выше, кэш ОС нужен не только для InnoDB, и если вы не отключите двойную буферизацию, InnoDB попросту затрет весь ваш кэш. На win-системах вам не нужно ничего менять. На Linux, FreeBSD, Solaris вам нужно задать параметр innodb_flush_method=O_DIRECT. На других системах вы сможете блокировать двойную буфферизацию на уровне ОС, но будьте уверены в своих действиях.
Но бывают ситуации, когда отключение двойной буфферизации не очень полезно. Например, если у вас нет RAID с BBU, а для вашей системы характерна интенсивная запись. Но даже в этом случае бывают исключения.

Облегчите работу вашей ОС – хорошей идеей будет запретить MySQL и другим важным процессам использовать файловую систему для кэша. Но ОС может решить, что это “неправильно” – MySQL занимает 95% памяти и лишь несколько процентов кэша на диске. Некоторые администраторы пытаются решить эту пролему, вообще отключая своппинг. Но тут есть подводный камень: ОС может убить процесс MySQL, который вышел за допустимые пределы (или ОС “думает”, что вышел). Такое сожет случиться, например, из-за неожиданно высокой нагрузки с большим числом соединений. Вдобавок не все ядра хорошо работают с отключенным своппингом. Да есть еще масса причин, чтобы так не делать. Люди, которые все-таки отключают использование файла подкачки, обычно подстраховывают себя, обеспечивая достаточное количество свободной памяти для кэша и буферов. Кевин Бартон (Kevin Burton) написал хорошую заметку о его экспериментах

В зависимости от ОС вы можете использовать различные методы стабилизации виртуальной памяти. Например, можно “заставить” MySQL использовать LargePages (большие страницы) памяти для размещение пула буферов InnoDB и использовать другие буферы, что хорошо скажется на производительности системы. Можно подкорректировать работу вирутальной памяти, выполнив echo 0 > /proc/sys/vm/swappiness, но не факт, что это спасет вас от своппинга. Некоторые ядра имеют другие собственные опции для оптимизации работы VM. Наконец, вы можете попробовать “закрепить” процессы MySQL в памяти, используя опцию -memlock, но будьте осторожны – ОС может уничтожить процессы, потребляющие слишком много памяти.

Два момента в использовании вирутальной памяти. Первый: мониторинг swap по показателям “swap used” – не самая удачная идея, так как вы не можете точно сказать, кто пишет в своп – MySQL или другие процессы. Чтобы убедиться в отстутствии активного своппинга, следите за значениями “si/so” в выводе vmstat на linux-системах. Пока там 0 – все в порядке :) Нет ничего страшного в нескольктх обращениях к swap-файлу в минуту. Но если за 60 секунд пишется 100+ страниц, то это уже проблема.

Второй момент: администраторы, которые заботятся о том, чтобы вирутальная памяьт не использовалась для буферов, часто думают так: если у меня маленький размер буфера, то получится одна операция ввода/вывода на запись его в своп и одна на извлечение. Малое количество операций – это не страшно. Это заблуждение. Во-первых ОС должна синхронизировать страницы в реальной и виртуальной памяти, а InnoDB может просто игнорировать выбор ОС. Но что более важно, алгоритмы InnoDB уже оптимизированы для более эффесктивного размещения страниц в реальной и вирутальной памяти. Например, InnoDB старается избегать блокирования данных в момент выполнения операции ввода/вывода, но данные могут оказаться заблокированными, пока осуществляется доступ к пулу буферов. Если одна из страниц окажется в своп-файле, в то время, как имеются связанные с ней страницы в памяти, то придется ожидать выполнения всех операций ввода/вывода для получения полных данных, необходимых для выполнения операции.

Эти рекомендации подходят для 70-80% систем, и, конечно же, не стоит слишком сильно привязываться к цифрам. Если у вас 50GB RAM, то для вас вполне будут приемлемы настройки, описаные для 64GB систем.

P.S. В заметке описаны рекомендации только для InnoDB. Если вы используете иной тип хранения данных (например MyISAM, Falcon, PBXT или Archive), то вы должны оптимизировать работу сервера в соответствии с рекомендациями именно к используемому вами Storage Engine.

Оригинал: http://www.mysqlperformanceblog.com/2007/11/03/choosing-innodb_buffer_pool_size/

Для настройки доступно довольно большое количество параметров, но лишь некоторые из них действительно влияют на производительность сервера. После установки этих параметров в правильные для вашего проекта значения, остальные настройки будут лишь незначительно влиять на поведение сервера.

key_buffer_size – очень важный параметр, если вы используете MyISAM-таблицы. Установите его равным 30-40% от имеющейся оперативной памяти, если вы используете только MyISAM. Актуальное для вашей системы значение зависит от индексов, размера данных и рабочего процесса. Помните, MyISAM использует кэш операционной системы для хранения данных и вам необходимо позаботиться о достаточных размерах выделяемой памяти. Во многих случаях, объем данных может быть значительно больше. Проверьте, не используется ли завышенное значение key_buffer. Нередко параметр установлен в значение 4GB при суммарном объеме .MYI-файлов в один гигабайт. Это напрасная трата ресурсов. Если вы используете несколько таблиц MyISAM – понизьте значение этого параметра. Но не опускайте его ниже 16-23 MB – этого будет достаточно для размещения индексов временных таблиц, которые создаются на диске.

innodb_buffer_pool_size – это очень важный параметр для настройки InnoDB. Таблицы этого типа гораздо более чувствительны к размеру буфера, нежели MyISAM. MyISAM может нормально работать даже при дефолтном значении buffer_size, в отличии от InnoDB, производительность которых будет заметно ниже при значении innodb_buffer_pool_size по умолчанию и больших объемах данных. Также пул буферов InnoDB самостоятельно кэширует индексы и данные, так что не нужно оставлять место для кэша ОС. Обычно предполагается выделение 70 – 80% памяти для серверов, на которых ничего не запущено, кроме InnoDB. Некоторые правила key_buffer применимы и в этом параметре: если у вас небольшие объемы данных и они не собираются стремительно увеличиваться, не завышайте значение innodb_buffer_pool_size, вы сможете найти свободной оперативной памяти лучшее применение.

innodb_additional_mem_pool_size – этот параметр не имеет сильного влияния на производительность. По крайней мере в операционных системах с грамотным распределением памяти. Но вы можете установить значение этого параметра раным 20MB (иногда больше) и вы можете видетm сколько памяти выделяет InnoDB для различных нужд.

innodb_log_file_size – очень важный параметр для систем с интенсивной записью, особенно больших объемов данных. Увелечение значения этого параметра обычно дает прирост производительности, но будьте осторожны. Обычно я использую значения 64M – 512 MB в зависимости от сервера.

innodb_log_buffer_size – значение по умолчанию вполне подойдет для большинства проектов со средней интенсивностью записи и короткими транзакциями. Однако если у вас бывают пики активности или работа с большим объемом данных, вы, вероятно, захотите увеличить значение этого параметра. Не делайте его слишком большим, это повлечет лишний расход памяти. Буфер сбрасывается каждую секунду и вам не нужен бОльший объем памяти. Обычно вполне хватает 8 – 16МB. Чем меньше система – тем меньше должно быть значение.

innodb_flush_logs_at_trx_commit – Вам кажется, что InnoDB в сто раз медленнее MyISAM? Вероятно, вы забыли изменить значение этого параметра. Значение по умолчанию 1 означает, что после каждой завершенной транзакции (или после изменения состояния транзакции) лог должен быть сброшен на диск. Это достаточно дорогая операция, особенно если у вас нет Battery backed up cache. Многие приложения, особенно те, в которых раньше использовался MyISAM будут хорошо работать при значении 2, который означает, что не надо сбрасывать буфер на диск, а следует отправить его в кэш операционной системы. Лог по-прежнему будет сбрасываться на диск каждую секунду и максимум, что вы можете потерять – это 1-2 секунды записей. Значение 0 обеспечивает более высокую скорость, но и более низкую надежность. Есть вероятность потерять транзакции даже при падении mysql-сервера. При значении равном 2 единственная возможность потерять данные – это фатальный сбой операционной системы.

table_cache – открытые таблицы могут разрастаться. Например, таблицы MyISAM помечают MYI-заголовок, как используемый. Вы, конечно же, не хотите, чтобы это происходило слишком часто и это, как правило, хорошее решение. Лучше увеличить размер кэша, чтобы он мог вместить большинство открытых таблиц. Кэш использует некоторое количество памяти и ресурсов ОС, но для современной техники это, как правило, не проблема. Значение 1024 будет оптимальным решением для нескольких сотен открытых таблиц (помните, каждое соединение нуждается в собственной копии). Если у вас много соединений или большое количество открытых таблиц – увеличьте это значение. Я видел системы со значением этого параметра > 100.000

thread_cache – Создание/уничтожение нитей (threads) может ухудшать производительность, особенно если они создаются/уничтожаются при каждом соединении/разъединении. Обычно я устанавилваю значение этого параметра равным 16. Если приложение делает большие прыжки в параллельных соединениях, то можно увидеть, как быстро растет переменная Threads_Created. Параметр предназначен для того, чтобы не создавать новых нитей в нормальных операциях.

query_cache_size – если ваше приложение читает много данных и у вас нет кэша на уровне приложения, этот параметр может неплохо помочь. Но не устанавливайте слишком большого значения – это может замедлить работу и содержание такого кэша может обойтись довольно дорого. Оптимальные значения – от 32MB до 512MB. Тем не менее, проверьте эффективность работы кэша через некоторое время. Вполне возможно, что текущее значение слишком велико.

Примечание: как вы заметили, все эти переменные являются глобальными и зависят от аппаратного обеспечения и устройств хранения данных. Сессионные переменные зависят от специфики конкретного проекта. Если у вас простые запросы, вам совершенно не нужно увеличивать параметр sort_buffer_size, даже если в вашем распоряжении 64GB оперативной памяти. Кроме того, это может снизить производительность. Обычно я оставляю настройку сессионных переменных на второй шаг, уже после оценки фронта работ.

P.S.: в дистрибутиве MySQL есть отличные примеры файла my.cnf для систем различных размеров. Они могут использоваться в качестве базы для ваших собственных файлов конфигурации, главное правильно выбрать шаблон.

Оригинал: http://www.mysqlperformanceblog.com/2006/09/29/what-to-tune-in-mysql-server-after-installation/

Что обычно говорят про настройку этого параметра: если вы хотите ускорить поиск в больших таблицах, увеличьте значение этого параметра. В стандартном my.cnf для систем с большим количеством памяти это значение установлено в 1М, дефолтное значение – 128К. Некоторые администраторы, имея большое количество оперативной памяти и несколько соединений устанавливают это значение в 32М, надеясь повысить производительность. Давайте посмотрим, оправдано ли это?

Чтобы проверить это, я создал таблицу с простой структурой:

SQL:
mysql> SHOW CREATE TABLE dt2 \G
*************************** 1. row ***************************
TABLE: dt2
CREATE TABLE: CREATE TABLE `dt2` (
`grp` int(10) UNSIGNED NOT NULL,
`slack` varchar(50) DEFAULT NULL
) ENGINE=MyISAM DEFAULT CHARSET=latin1
1 row IN SET (0.00 sec)

Таблица заполнена 75М строк и занимает 4GB. Система запущена на Fedora Core i686. Характеристики: 2 процессора Xeon, 2 GB RAM и два жестких диска в RAID0.

Я использовал следующие запросы для проверки поиска в таблице:

SQL:
mysql> SELECT count(*) FROM dt2 WHERE slack LIKE "a%";
+----------+
| count(*) |
+----------+
|  4705992 |
+----------+
1 row IN SET (51.77 sec)

Вот результаты, которые я получил:
read_buffer_size и эффективность поиска:

8200 байт – минимальное значение для read_buffer_size, поэтому мы начали с него.
Как вы можете видеть, результаты двольно неожиданные. Производительность действительно увеличивается на несколько процентов при увеличении значения вплоть до 128К. Но при последующем увеличении она резко падает. И продолжает снижаться по мере увеличения значения параметра до 32М.

Почему это происходит? У меня не было достаточного количества времени, для выяснения точных причин подобного поведения. Быть может, операционная система разбивает большие запросы на несколько маленьких и их обрабатывает более медленное устройство, быть может причина в чем-то другом. Но факт остается фактом – слишком большое значение параметра read_buffer_size способно снизить эффективность запросов. (Не так давно я уже писал об этом)

Давайте проведем еще один тест для небольших таблиц (умещающихся в кеше ОС):
read_buffer_size и кэш в памяти:

Как вы видите, разница в процентах уменьшилась. Теперь она составляет всего 10% между наилучшим и наихудшим значениями. Но пиковые пороги остаются теми же: 128К и 32М. Значит дело не в разбивке запроса, по крайней мере не только в этом.

Примечание: в данном случае любопытно было бы узнать результаты тестов на различных платформах, с разным аппаратным обеспечением и операционными системами. Различные структуры и размер таблиц, не говоря уж о таблицах с разрозненными строками также могут влиять на результаты.

В этом тестировании не учитывается степень распараллеливания – маленькие буферы, возможно, были бы более эффективными. Все необходимо испытывать на реальном тестировании.

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

Оригинал: http://www.mysqlperformanceblog.com/2007/09/17/mysql-what-read_buffer_size-value-is-optimal/