![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Firebird 3.0
Как известно, после многолетних трудов был выпущен Firebird 3.0.
Если подключаться к нему клиентом от Firebird 2.5 то он выдает сообщение об ошибке "connection rejected by remote interface".
Если я правильно понимаю, это старый клиент так реагирует, когда его сервер посылает, когда обнаруживает устаревший wire-протокол, который по умолчанию запрещен (его надо разрешать в firebird.conf или использовать клиент от 3.0): https://stackoverflow.com/questions/30390465/connection-rejected-by-remote-interface-connecting-to-firebird-3-with-pdo
Еще в нем при инсталяции руками надо подключаться локально к произвольной базе (в примерах используется демо-база employee) и создавать юзера SYSDBA на весь сервер. Немного смущает что для манипуляции общей базой юзеров надо подключаться к частной базе - нелогично.
И еще надо давать пользователям - владельцам БД явные права на создание баз.
Посмотрю, что будет дальше, но уже понятно что процесс миграции с 2.5, если таковой понадобится, будет сложный.
Если подключаться к нему клиентом от Firebird 2.5 то он выдает сообщение об ошибке "connection rejected by remote interface".
Если я правильно понимаю, это старый клиент так реагирует, когда его сервер посылает, когда обнаруживает устаревший wire-протокол, который по умолчанию запрещен (его надо разрешать в firebird.conf или использовать клиент от 3.0): https://stackoverflow.com/questions/30390465/connection-rejected-by-remote-interface-connecting-to-firebird-3-with-pdo
Еще в нем при инсталяции руками надо подключаться локально к произвольной базе (в примерах используется демо-база employee) и создавать юзера SYSDBA на весь сервер. Немного смущает что для манипуляции общей базой юзеров надо подключаться к частной базе - нелогично.
И еще надо давать пользователям - владельцам БД явные права на создание баз.
Посмотрю, что будет дальше, но уже понятно что процесс миграции с 2.5, если таковой понадобится, будет сложный.
no subject
no subject
no subject
Но для клиентов, использующих FB, в 90% случаев достаточно бесплатного Express.
В будущем году грядет версия SQL Server под Linux, беты уже доступны для тестов подписчикам.
no subject
1GB RAM (Same in 2008/2012)
4GB database size (raised to 10GB in SQL 2008 R2 and SQL 2012) per database.
Что-то маловато. У меня базы под 60 гиг размером.
no subject
Для транзакционных приложений 10 Гб - это немало.
Зачем вы советуете проприатарную каку?
А еще есть классический Mysql, форки Перкона и Мариадб разных веток 5.5, 5.6 и 5.7.
RE: Зачем вы советуете проприатарную каку?
no subject
no subject
no subject
no subject
no subject
Причина практически всегда - проблемы с железом. Память без ECC, диски с бэдами, выключение компьютера на живую из сети, итп.
Если я правильно понимаю ситуацию, у других СУБД то же самое, но они не делают себе черный PR из зарабатывания на ремонте баз :)
no subject
А если не секрет, 1-2 раза в год это на сколько развернутых систем (интересует порядок 1-10-100) и каково примерно среднее/максимальное время починки?
PS. Недавно попросили починить маленькую (7GB) FB базу, пока знакомился с FB и чинил - сильно удивился проблеме невостановимости полного бэкапа и возможности скопировать файл во время работы. Но круче всего версионность метаданных и обновление процедур (быстрый bugfix на месте), которые используются другими процедурами, которые вызваны в подключенных сессиях...
no subject
И в ряде случаев восстановлению не подлежит. Не надо так делать.
Причем мусором будет как копия базы так и ее исходник.
Пробовал такое, слава богу на тестовой базе.
no subject
Хорошо, что убилась только консистентность между таблицей аудита подключений и генератором ее ID.
Кто б знал, как вот эти местные "ИТшники" бесят - слов нет передать. И, блядь, главное все же сами всегда лезут, никогда не позвонят в саппорт, ничего.
no subject
Это на винде работает, на юниксах нет.
no subject
Файл во время работы ни в одной БД вообще копировать нельзя - он же не консистентный будет.
Невосстановимость бэкапов и то что бэкап бинарный и его нельзя руками починить - тоже маразм известный.
А замена процедур на ходу - вполне штатная ситуация.
no subject
no subject
У меня 5 серверов в разных городах, базы от 200мб до 7гиг, одинаковые по структуре.
За время существования FB проблема была только один раз, когда винт сдох.
На IB/YA бывали проблемки, один раз пришлось из бэкапа восстанавливаться.
Работаю на IB/YA/FB лет 15.
С невосстановимыми бэкапами сталкивался, но всегда заблаговременно, ибо для разработки использую копию базы поднятую из бэкапа. И всегда источником были мои ручки (изменение метаданных на ходу, NULL в поле NOT NULL из-за опять же изменения метаданных при наличии коннектов).
no subject
Еще находили вроде какой-то баг в PDO, что к самому FB не относится.
Читай форум где разработчики присутствуют, наиболее быстрый путь разобраться.
no subject
А 2.5 хотят EOL в 2017