Нужен ликбез по работе с базой данных и клиент-серверной архитектуре

Реализовал программу с помощью компонентов доступа к базе FireDAC (FDQuery). База MySQL лежит на сервере.
Сервер был на FreeBSD и MySQL. Клиентов порядка 10 компьютеров. Никаких проблем не было.
Потом сервер отдали другому сисадмину, он зачем-то решил снести FreeBSD и поставить Линукс и MariaDB. Начались проблемки, но мы их решили.
Недавно новый админ обновил MariaDB до последней версии 11.4.2. После чего программа стала зависать у клиентов.
В логах отображается множество коннектов, которые накапливаются и не удаляются.
Админ объяснил это так: "У вас не клиент-серверная архитектура. Клиенты подключаются напрямую к базе, поэтому возникает множество дедлоков".
Может я чего-то не понимаю, но я так полагал, что когда клиенты подключаются к серверу БД - это и есть клиент-серверная архитектура (а не файл-серверная).
Т.е. он предлагает переписать программу на трехзвенную архитектуру? Клиент - сервер приложений - сервер БД?
Но все работало нормально, пока не обновили MariaDB. Никаких дедлоков и ничего не отваливалось. В дельфи всегда традиционно работали через FireDAC, и не грузили логику серверами приложений и джейсонами. Или я не прав?

0

Сообщение от xxbesoxx У него такой ?

Не совсем. Видимо такой:

Клиент -> СУБД (на сервере).

А админ предлагает такое:

Клиент -> Сервер Приложения -> СУБД

Правда для меня остаётся загадкой, как это должно помочь решить вопрос ТСа. Особенно в контексте того, что админ-диверсант продуктовое окружение может по желанию левой пятки изменить.

1

Т. е. прямое обращение создаёт дедлоки, а прокладка, которая будет такие же запросы к БД слать, создавать их не будет?

И эту прокладку кто админить будет? Этот же самый админ? Ну так может намекнуть ему, что в случае реализации, на него ляжет дополнительная работа.

Я сам как-то трехзвенку никогда не делал, мне, если что, где сервер приложений развернуть, вопрос. Но я не помню, чтобы трехзвенка, вроде, тех же 1С хоть где-то работала просто сравнимо по скорости и удобству с прямым подключением. И если нет критических вопросов безопасности, то я не вижу никакого смысла с этим заморачиваться.

0

Можно я скажу через призму несколько иного восприятия?

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

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

Сообщение от Beltar И эту прокладку кто админить будет?

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

Но с точки зрения производительности и облегчения доступа - я бы посоветовала прямое подключение. Пусть администратор возится с правами доступа исходя из IP клиента, mac клиента, логин и пароль подключения к БД опять же можно через админа сделать уникальным для каждого клиента.

Что важно, *nix системы, а точнее штатные файерволы на них - помимо систем защиты непосредственно БД - предоставляют гораздо более широкий спектр контроля в сравнении с win. Плюс идентификация от сервера БД - это будет вполне вменяемый уровень безопасности, но настраивать его придётся вашему админу.

0

Сообщение от Hiori а вот, сервер приложения фигачит доступ всем

С фига-ли? Сервер приложений, как минимум, скрывает структуру БД и реальные логины и пароли к ней. Ну и в целом ограничивает набор доступных операций с БД теми, которые в нем определены. Настраивать же реальные правила доступа надо в любом случае.

Сообщение от Hiori который не умеет и не хочет работать - никто

Ну поэтому организации ставят 1С и штат сотрудников к нему, но делать что-то локально самому и потом за эту прокладку, которая где-то крутится, и не у программера, и не у юзеров отвечать, толку немного. В моем понимании, если есть компьютер, то отвечать за ВСЁ ПО на нем должен кто-то один. Корпоративный сервер - значит и отдел, сопровождения отвечает. Зато, если есть нормальная СУБД со своей системой прав, к которой есть администраторы, то можно создать для них документ, какие группы пользователей должны быть с какими правами, и потом любой админ, сможет не заморачиваясь с особенностями работы приложения просто отработать запрос вида "включить нового сотрудника в группы A, D и G"

0

Сообщение от Beltar Зато, если есть нормальная СУБД со своей системой прав

Только на практике система прав бывает сильно сложнее того, что может СУБД предоставить.

Сообщение от Hiori С точки зрения администратора - это решение сильно упрощает работу и перекладывает ответственность на программиста

Админу оно ничего не упрощает и ничего ни на кого не перекладывает.

0

svnvlad, а это нормально что у вас один и тот-же пользователь ruser с разных ip заходит?...

0

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

0

Сообщение от svnvlad Это плохо?

Нет, это правильно.

0

Сообщение от Usaga Админу оно ничего не упрощает и ничего ни на кого не перекладывает.

Почему же? Я сужу со своей точки зрения именно администратора. Сказать "Я тут при чём? Разрабатывал кодер - с него и спрашивайте..." гораздо проще, чем пытаться отладить коробочное приложение, которое полностью в моей ответственности.

Сообщение от u235 а это нормально что у вас один и тот-же пользователь ruser с разных ip заходит?...

Сообщение от svnvlad Это плохо?

Да, это плохо. При трёхзвенной архитектуре - это правильно. При доступе с рабочего места к БД - нет.

Сообщение от svnvlad При создании нового рабочего места каждый раз лезть в базу на уровне админа базы и создавать пользователя?

Но вы же создаёте нового пользователя в структуре домена. Почему не создать в БД?

Добавлено через 7 минут

Сообщение от Beltar Сервер приложений, как минимум, скрывает структуру БД и реальные логины и пароли к ней

Я не это имела ввиду. Сервер приложений имеет свою идентификацию пользователя, но отрыт для доступа с любого IP (ну, чаще всего). На уровне БД же можно спокойно ограничить доступ определённого пользователя с конкретного IP. Я говорила только об этом.

Сообщение от Beltar В моем понимании, если есть компьютер, то отвечать за ВСЁ ПО на нем должен кто-то один

Не получится. Точнее получится, но за ПО на рабочем месте и ПО на стороне сервера чаще всего отвечают разные люди, хотя это один софт. Даже больше того, я сама постоянно сталкиваюсь с тем, что работа софта - это ответственность моего бюро (администрирования), однако плагины, написанные для него - ответственность бюро программирования.

0

Сообщение от Hiori Почему же?

Потому, что если что-то глючит, то это 90% что вопросы к разработчику, а не к админу. При условии, что админ не выступает диверсантом-вредителем, как в данной теме.

0

Сообщение от Usaga Потому, что если что-то глючит, то это 90% что вопросы к разработчику, а не к админу

Только в том случае, если разработчик доступен.

Я не раз сталкивалась с ситуацией, когда на админа наседает начальство "к утру должно работать!", и мне такое говорили в том числе. А там софт купленный из левой шарашки, его даже софтом не назовёшь - поделка школьника, но зато в этой шарашке работает сын/внук/зять/племянник одного из директоров предприятия. И естественно - если не работает, то виноват админ

0

Hiori, и у админа есть объективная возможность на такой софт повлиять? И если есть такая возможность, то админ продолжает работать админом?

0

Нет, но продолжает, потому что деньги и соцпакет

0

Сообщение от Hiori На уровне БД же можно спокойно ограничить доступ определённого пользователя с конкретного IP. Я говорила только об этом.

"На уровне БД"

Есть порадикальнее предложение - не ограничиваться IP-layer, а спуститься до физического:
по витой паре пускать, а если по по оптоволокну пытается подлец добраться до таблицы - сразу калёной метлой по наглой роже.

0

Сообщение от volodin661 Есть порадикальнее предложение - не ограничиваться IP-layer, а спуститься до физического: по витой паре пускать, а если по по оптоволокну пытается подлец добраться до таблицы - сразу калёной метлой по наглой роже.

А как же, пока не опустимся до коаксиального соединения - не верить никому.
Только к чему вообще сарказм, если MySQL при регистрации пользователя требует указать хост? Или вы указываете % и потом хоть трава не расти?

0

1) Потому что это не уровень БД.

2) про MySql сказать нечего, не пользуюсь, брезгливый.

3) Хочется порулить IP, сдай на права и welcome to коммутатор.

0

Сообщение от Hiori Но вы же создаёте нового пользователя в структуре домена. Почему не создать в БД?

Чево ето? У нас нет никакого домена, все компы в горизонтальной структуре.
В локальной сети в БД один пользователь, для внешнего доступа с сайта - другой, и фаервол ограничивает внешний доступ к 3306 только с одного IP.
Права доступа разграничиваются в бизнес-логике приложения. Там специальная форма с чекбоксами на read write delete к каждому функционалу для каждой группы пользователей. Кто-то может работать со списком клиентов, кто-то со списком лекарств, кто-то с назначениями врача, кто-то с кассой и т.д. Группы пользователей: директор, регистратор, старший регистратор, врач, старшая медсестра, бухгалтер и т.д.

0