Доброе время суток!
Да и вообще Здравствуйте!

Есть два нода. Подключены по SAS к дисковой полке.
(Два разных компа видят один диск)
На обоих нодах(компах) MySQL, которые используют базу,
расположенную на одном диске, совместном для двух нодов(компов).
Простите, что утрирую. Просто обычно набегают троли и все глохнет.

Чего я только не начитался на просторах Инета!
Видимо как-то неправильно запрос задаю.

В основном репликация и кластеризация. В дополнение - бред и холивар!

Вопрос: могут ли, в принципе, два сервера MySQL обращаться к одной базе данных на одном носителе?
Т.е. диск один. База одна. MySQL два.(еще раз простите!)

Спасибо за конкретный ответ с (возможными) примерами!

Спасибо за ответы!

Грустно как-то!

netwind:

Действительно написано - not recommended. Более того, что-то типа "stop one of instance"!


Причем ведь вроде как ядро многопоточное!
Все равно есть механизм блокировок!
Что мешает?



Еще раз спасибо!

Akina которые прекрасно разруливают это дело в оперативной памяти.
Вы в это сам то верите?
Может посчитаем? Возьмём Ваш сайт.... У Вас оперативной памяти 8 Гб ...

AkinaТак что лучше, если с каждой БД будет работать один сервер. А второй, буде надо ему что из базы, пусть лучше с вопросами обращается к этому первому, благо есть Federated Engine. Или реплицировать в обе стороны.

Ну и слава богу! Вот и решили проблему! Сдохнет один и пускай ему! Второй подождет! Че ему мучатся! Данных то все равно нет! Репликация не прошла! Да и репликация-то своеобразная! С диска с на диск с! Мы ведь с себя на себя реплицируем!
Цитата изначального вопроса: "Есть два нода. Подключены по SAS к дисковой полке."
Да и репликация времени не занимает!

Обращение к дискам SAS пусть будет 3Gbit/s. Минус накладные - и того чего то порядка от 0.3 до 1 ГБАЙТ/с (Там 4 провода!)
Обращение по Ethernet 1 Gbit. Минус накладные - и того порядка 500-700 Мбит (сразу! почитайте стандарты и функционирование стека! а то начнется!)

Ну и пускай реплицирует! Пусть весь мир подождет!

AkinaВерю? что за бред?
....
И я знаю... нет, не так - я убеждён, что отслеживание блокировок отдельных потоков/соединений в рамках одного сервера в оперативной памяти выполняется на порядки быстрее, чем .....


Вы так верите, что аж меня заставили! Признаю! Съедаю Снимаю шляпу!
Без сарказма!

AkinaУгу... и track seek 4 мс, за которые диск про***т передачу 12 мегабайт данных.
А поскольку этих тракосиков будет не один и не два - то не надо тут дутой арифметики. А гигабитному этхернету никакие головки двигать не надо.

А, как абсолютно правильно выразился jan2ary на другой стороне не с "головки"?
Далее добавим перца...
netwindНу пробуйте на практике.
Просто мы знаем, что вам в конце концов самим не понравится и вы придете к репликации.

Я, ни в кое случае, не оспариваю Ваш профессионализм!
И вопрос даже не в том, что у меня Такая конфигурация и нужно защитить инвестиции!

Я поторопился и не написал, что это веб приложение. Простите!
И, к стати, спасибо за аргументированную дискуссию! Я про " набегут троли "! Это явно не про Вас!

Я просто хочу понять и найти соответствующее решение.
При Web-приложении:
1. На "чтение" уходит до 90% всех операций обращения к БД.
2. Из 10% операций по записи около 70% требуют "моментального" перепрочтения записанных данных.
Для контроля, для отправки юзверю и т.д. и т.п. Причем "запись" - это, как правило, один HTTP запрос, а
визуализация результата - другой. Не пинайте! Так, мне во всяком случае, проще.
3. Из 10% операций записи - 80% записывают информацию новую, не изменяющую уже имеющуюся.
4. Т.е. 20% записей изменяют и конкурируют!

Т.о., мы, в соответствии с моим любимым матаном, имеем порядка 70% из 20% из 10% = 1.4% операций к БД,
вызывающих конкуренцию за запись! Дисперсия по времени (16 часов активного рабочего дня) нам даст сотые доли
процента.
И это по максимуму. На некоторых сайтах вообще записи нет!

Но, дьявол кроется в деталях!

5. При высоконагруженных сервисах - где (на каком из нодов) окажется запрос на визуализацию результатов чтения
только что записанных данных - непредсказуемо.
6. Репликация не бывает "моментальной". И накладные расходы по чтению новой записи->подготовки передачи-> передача
-> прием -> анализ -> запись в БД - задержка Z. Это если она Реально "моментальная" а не по времени!
Если по времени, то вообще неприемлемо!

И, в соответствии с п.5 мы приходим к тому, что п.2 реально под угрозой!
Мы дадим юзверю данные, в лучшем случае, предыдущие ! А так-то 0.7 перечитываемых данных из 0.1 "записи"
* 0,ХGb (фактически скорость передачи соединения) * Uc * Z
где Z задержка на репликацию, Uc - количество пользователей.
Т.е. где-то ...
Имеем значительный процент вероятности того, что в системе репликации,
мы выдадим вообще не контролируемые данные по, пусть маленькому, но самому важному
сегменту данных!

Ух!!!
Но, это так!
Очень не хочется из-за 1.4% коллизий чтения с диска тратится на второй набор дисков - подождем!
И, практически (в моем случае) 2% (возможных. и это пока! без роста производительности)
недостоверных данных - а вот это уже ни как!
Городить два сервера с двойным набором дисков и двойной стоимостью
мне не хочется!

Ну, как бы так!

netwindSelen74, ну давайте сначала начнем и возможно, вопросы отпадут на раннем этапе:
авторрасположенную на одном диске, совместном для двух нодов(компов).
а как именно будет это сделано ? или уже сделано ? а файловая система какая тогда?

Самое простое - MS Server Datacenter. Лучше 2012r2
netwindпо-моему в линуксе нельзя два раза файловую систему примонтировать в двух местах. Там какой-то флаг пишется в нее, кажется.
Ну даже если и получится игнорировать этот флаг, логические проблемы в ядре наверняка возникнут.
Для Linux вообще куча всяких FS.

miksoftОшибаетесь. БД пишет данные блоками. И даже простой INSERT в конец таблицы произведет сначала чтение последнего блока, его модификацию с добавление новой записи и запись обратно. А если блок будет прочитан из буферного кэша, то данный инстанс MySQL даже не узнает, что другой инстанс уже модифицировал блок, и перезапишет его. Я уж не говорю про модификацию индексов, запись Redo и Undo логов.
Кто ж его блоками то угораздил? Уж не файловая система?
Даже в ту... не самом продвинутом Инет-магазине не одна таблица!
Опять же конкуренция в минус.
Это не противоречит вероятности возникновения коллизий.
Да и... мы уже поняли, что стандартный MySQL этого не может.

miksoftДа и при простом чтении нет гарантии, что этот блок не изменен другим инстансом. А механизма синхронизации кэшей в MySQL нет (по крайней мере, если не говорить о кластере).
Да и при репликации баз нет гарантии! И, более того, при репликации-то это гарантия полностью отсутствует!
Вот ведь ... сумка!

И, Господа! Из нашей с вами беседы, не кажется вам, что разобранные нами кейсы
как-то демонизируют работу сервера с памятью!
Что-то я, просмотрев нашу переписку, думаю, что "а не дофигали в памяти то у сервера содержится?"
Какое-то чувство, на уровне тазобедренного сустава, мне подсказывает, что память-то он почаще на диск сбрасывает,
чем мы о нем думаем!
Где-то промелькивала информация о, чуть ли не, тысяч операций/сек на MySQL.
Это, простите, сколько памяти то надо?

netwindЭто неправда. Есть синхронная репликация - это с гарантией.
Но практика такова, что выгоднее отказаться от синхронности ради увеличения производительности. Поэтому вы могли подумать что ее нет. Ну нет и нет. В вебе это обычно игнорируют. Чего и вам советуем.
Будем считать, что мы не поняли друг друга!

Приложение:
1. Сохраню содержимое корзины.
1.1. Сохраняю в БД (~)
1.2. Перенаправляю страницу на показ.
2. Потом выдам его для контроля юзверю.
2.1. Читаю данные.
2.2. Формирую страницу.
2.3. На странице нет результатов сохранения!

Запросы 1.2. и 2.1. на разных нодах! На разных! При скорости работы Апачей, Нгниксов, ИИСов с балансировкой - это дцать ms!
Им не надо "головки" двигать!
Через дцать ms на нод, отличный от записывающего, придет запрос "дай запись корзины"!
Где репликация? Гарантия чего? Гарантия репликации только что записанной записи нода 1 в ноде 2?
Задержек нет?
Ну... не серьезно как-то по второму-то разу одно и тоже!