The OpenNET Project / Index page

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

MySQL прокси

29.06.2007 22:27

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

  1. Главная ссылка к новости (http://forge.mysql.com/wiki/My...)
  2. Download mysql-proxy
  3. pgpool - connection pool server for PostgreSQL
Лицензия: CC-BY
Тип: Изменение в каталоге ПО
Короткая ссылка: https://opennet.ru/11247-proxy
Ключевые слова: proxy, mysql, balance
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (25) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Alex (??), 00:42, 30/06/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    господа, кто не злой...в кратце на родном русском расскажие что это и на сколько это серьезно ?
     
     
  • 2.2, Ilya Evseev (?), 02:36, 30/06/2007 [^] [^^] [^^^] [ответить]  
  • +/
    Это программа, которая для SQL-клиентов выглядит как SQL-сервер.
    Но вместо непосредственной обработки данных и доступа к базе
    она передаёт все запросы настоящим SQL-серверам.
    Какому именно из них, она выбирает в зависимости от их нагрузки,
    включённости и т.д.

    Кроме того, она способна модифицировать проходящие через неё запросы,
    и способна вести статистику по запросам.

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

     

  • 1.3, TheosBLG (?), 04:44, 30/06/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Повышает отказоустойчивость и безопасность...
     
     
  • 2.4, Квагга (?), 08:22, 30/06/2007 [^] [^^] [^^^] [ответить]  
  • +/
    Ы маштабируемость!
    Лоад балансинг это тоже не лобио кушать!
     

  • 1.5, igorsia (?), 10:49, 30/06/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Интересно, а псевдокластер с одинаковыми запросами по двум и более узлам, содержащим разные данные одинаковой структуры он позволяет делать?
     
  • 1.6, dem (?), 11:08, 30/06/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    в PostgreSQL кажись тож такое есть/
     
  • 1.7, andrey (??), 12:17, 30/06/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    все уже давно сделано
    http://sqlrelay.sourceforge.net/
     
     
  • 2.9, TS (?), 19:46, 30/06/2007 [^] [^^] [^^^] [ответить]  
  • +/
    SQL Relay doesn't have any built-in database server failover mechanism. If a database server that SQL Relay is connected to goes down, SQL Relay doesn't currently open new connections to a different "failover" database to make up for it. This is on the TODO list, but has not yet been implemented.

     
     
  • 3.10, Basma4 (?), 23:00, 30/06/2007 [^] [^^] [^^^] [ответить]  
  • +/
    Тогда надо было SQL Relay-ю помогать. Сварганить failover пач к нему и не плодить велосипеды. Вливаться надо в проекты, объединяться..
     

  • 1.8, Alex (??), 14:13, 30/06/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Парни а скажите, с помощью данного решения можно собрать 2 Машины с mysql именно как горячий резерв на случай отказа, но так чтоб приложения, использующие БД работали по доменному именни и тд?
     
     
  • 2.11, andrey (??), 00:41, 01/07/2007 [^] [^^] [^^^] [ответить]  
  • +/
    Ну, судя по описанию, это оно и есть. в данном случае домен должен быть перенесен на этот SQL-relay, на который и будут отправляться запросы. А уж он будет решать на какой из реальных серверов выполнять его отправку для выполнения. Только следует обратить внимание на репликацию данных: либо этот проект будет выполнять запросы удаления/вставки/обновления на обоих серверах, либо прийдется заморочиться с репликацией.
    Относительно репликации средствами MySQL - решение более надежное, ибо в случае хранимых процедур и самописных функций (в теории) никто не мешает выполнять модификацию базы при вызове функции (например, для сбора статистики и т.п.), что явно ускользнет от этого прокси.
    А уж если выполнять репликацию средствами MySQL, то и выполнить load balancing & failover можно и более стандартными средствами: CARP во FreeBSD, SNAT и load balancing в linux
     

  • 1.12, Alex (??), 02:13, 01/07/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    andrey, так т.е. получается MySQL-прокси сможет все же следить за состояниме ноды, и получается в минимальной конфигурации необходимо 3 сервера - 2 ноды и Управления/Распраделение(proxy)

    Соответветвенно, таким образом мы получаем отказоустойчивость, впринцпипе этого уже будет достаточно, но вот как Вы верно заметили - нужна синхронизация данных в нодах, т.е. чтоб при подении основной ноды прокси перевел заросы на резервную, но так чтоб все осталось прозрачно для ПО и пользователей, соответвенно необходима репликация данный и как я понимаю это - MASTER-MASTER
    Но вот еще одна проблема, если mysql-proxy выходит из строя мы теряем все, соответвенно его тоже нужно кластеризовать любым средством я так понимаю, поскольку данных он не хранит.
    Вообще если не жалко поделитесб соображениями на этот счет, просто вот планирую что-то подобное разварачивать у себя.

     
     
  • 2.13, DoktorPZ (?), 12:24, 01/07/2007 [^] [^^] [^^^] [ответить]  
  • +/
    Подними master-master + mysql proxy на каждом из них. Далее просто перекидывай IP, либо CARP либо heartbeat.
     
  • 2.14, Ilya Evseev (?), 16:39, 01/07/2007 [^] [^^] [^^^] [ответить]  
  • +/
    Прокси сам по себе можно держать на той же машине, что и один из sql-серверов.
    Чтобы он не конфликтовал с сервером, достаточно перевесить сервер на другой порт.

    Если прокси упадёт, достаточно будет просто исправить dns-имя,
    чтобы оно указывало на оставшийся сервер.

    Главное, что прокси в состоянии распихивать данные сразу в два хранилища на разных ящиках.
    Получается, что данные ни при каком раскладе не пропадут, а время отказа в обслуживании
    сведётся к нескольким минутам даже при отсутствии автоматической реакции на падение самого прокси.

     
     
     
    Часть нити удалена модератором

  • 4.16, DoktorPZ (?), 20:16, 01/07/2007 [^] [^^] [^^^] [ответить]  
  • +/
    Судя по резюме (если это его: http://ilya-evseev.narod.ru/personal/resume.html) человек провто не имел дело с высоконагруженными 24/7 mysql серверами.

    Насчет Mysql прокси, было бы супер если бы отслеживалась рассинхронизация master-slave или master-master для порогового времени задаваемого через конфиг. И автоматом убирало slave из списка доступных серверов.

     
     
  • 5.18, Ilya Evseev (?), 20:51, 01/07/2007 [^] [^^] [^^^] [ответить]  
  • +/
    mysql репликацию делает (делал?) не через версии данных, а через журнал операций.
    Если репликация по каким-то причинам задерживается, то он раздувается до диких размеров.
    То есть появляется ещё одна точка отказа, которой в Лотусе или MSSQL, например, нет.
    Не исключено, что дублировать на проксе запросы insert/update/delete окажется безопаснее и быстрее.

    p.s. про резюме всё правильно :-)) за исключением того, что оно не обновлялось года три.
    с тех пор появился скромный опыт работы с небольшой mysql-базой 24x7 на 8k пользователей и 2ТБ/мес. трафика.

     
     
  • 6.19, DoktorPZ (?), 21:30, 01/07/2007 [^] [^^] [^^^] [ответить]  
  • +/
    1 база, объем сколько? Поднимал с нуля, или пришел на готовое уже? Резервируешь как и чем?
     
     
  • 7.22, Ilya Evseev (?), 01:36, 02/07/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >1 база, объем сколько?
    Важных баз у меня три: две для биллинга под MySQL и одна для внутреннего АРМ'а под MSSQL.
    Объём первых двух - 110 и 75 гигов.

    > Поднимал с нуля, или пришел на готовое уже?
    Везде было как бы готовое.
    Как бы - потому что с нуля было бы легче. :-))

    >Резервируешь как и чем?

    Резервное копирование везде делалось с нуля.

    MySQL - трафик переносится в архивные таблицы собственной процедурой в обход
    имеющейся в биллинге, с одновременным ужатием части полей и переносом со SCSI на SATA.
    Важные данные (пользователи, платежи) архивируются раз в день рано утром через mysqlhotcopy.
    Чаще не получается - блокировки не дают. Ждем Фалькона :)
    Для архивов применяется прореживание через picobackup.

    MSSQL - днём каждый час делается в online-режиме резервная копия на соседний компьютер,
    где тоже готов к запуску MSSQL. Ежечасные копии стираются утром.
    Утром делается ежедневная копия, которая заливается на Рапидшару через up2rshare
    и сохраняется локально с прореживанием через picobackup.
    Все копии немедленно после создания шифруются через gpg.

     
     
  • 8.24, k (??), 11:05, 03/07/2007 [^] [^^] [^^^] [ответить]  
  • +/
    это жесть ... текст свёрнут, показать
     
  • 8.25, ilia kuliev (?), 12:07, 03/07/2007 [^] [^^] [^^^] [ответить]  
  • +/
    Я извиняюсь, но вместо того чтобы мучать Рапидшару не лучше ли арендовать сервер... текст свёрнут, показать
     
     
  • 9.26, Ilya Evseev (?), 00:41, 04/07/2007 [^] [^^] [^^^] [ответить]  
  • +/
    Если платный вариант чем-то лучше, то я буду рад услышать аргументы по существу ... текст свёрнут, показать
     
     
  • 10.28, Samm (??), 03:40, 21/07/2007 [^] [^^] [^^^] [ответить]  
  • +/
    Да это же очевидно В бесплатном вам никто ничего не должен и гарантий нет никак... текст свёрнут, показать
     
     
  • 11.29, Ilya Evseev (?), 17:49, 22/07/2007 [^] [^^] [^^^] [ответить]  
  • +/
    Гарантия в популярности Платные тоже закрываются Приватность обеспечивается pg... текст свёрнут, показать
     
  • 2.27, andrey (??), 01:23, 06/07/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >Вообще если не жалко поделитесб соображениями на этот счет, просто вот планирую
    >что-то подобное разварачивать у себя.
    не жалко, конечно. собственно, соображения от DoktorPZ (ответ со счастливым номером 13 :) ) можно рассматривать, как руководство к действию :) коротко, ёмко и по существу.
    было бы очень интересно увидеть результаты эксперимента и впечатления от этой софтины
     

  • 1.20, DoktorPZ (?), 21:36, 01/07/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    0.5.1 - 2007-06-30

      * added script examples for rewriting and injection
      * added support for UNIX sockets
      * added protection against duplicate resultsets from a script
      * added missing dependency to libmysqlclient-dev to the INSTALL file
      * added support for pre-4.1 passwords in a 4.1 connection
      * added inj.query_time and inj.response_time into the lua scripts
      * added resultset.affected_rows and resultset.insert_id
      * added proxy.VERSION

      * changed --proxy.profiling to --proxy-skip-profiling

      * fixed assertion when read_query_result() is not provided
        when PROXY_SEND_QUERY is used
      * fixed warning if connect_server() is not provided
      * fixed handling of duplicate ERR on COM_CHANGE_USER in MySQL 5.1.18+
      * fixed compile error with MySQL 4.1.x on missing COM_STMT_*
      * fixed mysql check in configure to die when mysql.h isn't detected
      * fixed crash on fields > 250 bytes when the resultset is inspected
      * fixed assertion when a error occurs at initial script exec time

     

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



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

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