| 1.1, Alex (??), 00:42, 30/06/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
господа, кто не злой...в кратце на родном русском расскажие что это и на сколько это серьезно ? | | |
| |
| 2.2, Ilya Evseev (?), 02:36, 30/06/2007 [^] [^^] [^^^] [ответить]
| +/– |
 Это программа, которая для SQL-клиентов выглядит как SQL-сервер.
Но вместо непосредственной обработки данных и доступа к базе
она передаёт все запросы настоящим SQL-серверам.
Какому именно из них, она выбирает в зависимости от их нагрузки,
включённости и т.д.
Кроме того, она способна модифицировать проходящие через неё запросы,
и способна вести статистику по запросам.
На мой взгляд, не единственный, но крайне полезный инструмент
для повышения быстродействия и для отладки. | | |
|
| 1.5, igorsia (?), 10:49, 30/06/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Интересно, а псевдокластер с одинаковыми запросами по двум и более узлам, содержащим разные данные одинаковой структуры он позволяет делать? | | |
| |
| 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.
| | |
| |
| |
| |
| 10.28, Samm (??), 03:40, 21/07/2007 [^] [^^] [^^^] [ответить] | +/– |  Да это же очевидно В бесплатном вам никто ничего не должен и гарантий нет никак... текст свёрнут, показать | | |
|
|
|
|
|
|
|
|
| 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 | | |
|
