Firebird 3.0
Dec. 10th, 2016 06:36 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
metaclassКак известно, после многолетних трудов был выпущен 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, если таковой понадобится, будет сложный.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2016-12-10 03:59 pm (UTC)no subject
Date: 2016-12-10 05:03 pm (UTC)no subject
Date: 2016-12-10 05:08 pm (UTC)Но для клиентов, использующих FB, в 90% случаев достаточно бесплатного Express.
В будущем году грядет версия SQL Server под Linux, беты уже доступны для тестов подписчикам.
no subject
Date: 2016-12-10 07:20 pm (UTC)1GB RAM (Same in 2008/2012)
4GB database size (raised to 10GB in SQL 2008 R2 and SQL 2012) per database.
Что-то маловато. У меня базы под 60 гиг размером.
no subject
Date: 2016-12-10 07:34 pm (UTC)Для транзакционных приложений 10 Гб - это немало.
Зачем вы советуете проприатарную каку?
Date: 2016-12-12 10:47 am (UTC)А еще есть классический Mysql, форки Перкона и Мариадб разных веток 5.5, 5.6 и 5.7.
RE: Зачем вы советуете проприатарную каку?
Date: 2016-12-12 11:28 am (UTC)no subject
Date: 2016-12-10 04:18 pm (UTC)no subject
Date: 2016-12-10 04:41 pm (UTC)no subject
Date: 2016-12-10 05:00 pm (UTC)no subject
Date: 2016-12-11 08:44 am (UTC)no subject
Date: 2016-12-11 10:02 am (UTC)Причина практически всегда - проблемы с железом. Память без ECC, диски с бэдами, выключение компьютера на живую из сети, итп.
Если я правильно понимаю ситуацию, у других СУБД то же самое, но они не делают себе черный PR из зарабатывания на ремонте баз :)
no subject
Date: 2016-12-11 10:12 am (UTC)А если не секрет, 1-2 раза в год это на сколько развернутых систем (интересует порядок 1-10-100) и каково примерно среднее/максимальное время починки?
PS. Недавно попросили починить маленькую (7GB) FB базу, пока знакомился с FB и чинил - сильно удивился проблеме невостановимости полного бэкапа и возможности скопировать файл во время работы. Но круче всего версионность метаданных и обновление процедур (быстрый bugfix на месте), которые используются другими процедурами, которые вызваны в подключенных сессиях...
no subject
Date: 2016-12-11 10:26 am (UTC)И в ряде случаев восстановлению не подлежит. Не надо так делать.
Причем мусором будет как копия базы так и ее исходник.
Пробовал такое, слава богу на тестовой базе.
no subject
Date: 2016-12-11 10:57 am (UTC)Хорошо, что убилась только консистентность между таблицей аудита подключений и генератором ее ID.
Кто б знал, как вот эти местные "ИТшники" бесят - слов нет передать. И, блядь, главное все же сами всегда лезут, никогда не позвонят в саппорт, ничего.
no subject
Date: 2016-12-11 12:22 pm (UTC)Это на винде работает, на юниксах нет.
no subject
Date: 2016-12-11 10:54 am (UTC)Файл во время работы ни в одной БД вообще копировать нельзя - он же не консистентный будет.
Невосстановимость бэкапов и то что бэкап бинарный и его нельзя руками починить - тоже маразм известный.
А замена процедур на ходу - вполне штатная ситуация.
no subject
Date: 2016-12-11 11:15 am (UTC)no subject
Date: 2016-12-11 10:35 am (UTC)У меня 5 серверов в разных городах, базы от 200мб до 7гиг, одинаковые по структуре.
За время существования FB проблема была только один раз, когда винт сдох.
На IB/YA бывали проблемки, один раз пришлось из бэкапа восстанавливаться.
Работаю на IB/YA/FB лет 15.
С невосстановимыми бэкапами сталкивался, но всегда заблаговременно, ибо для разработки использую копию базы поднятую из бэкапа. И всегда источником были мои ручки (изменение метаданных на ходу, NULL в поле NOT NULL из-за опять же изменения метаданных при наличии коннектов).
no subject
Date: 2016-12-11 10:23 am (UTC)Еще находили вроде какой-то баг в PDO, что к самому FB не относится.
Читай форум где разработчики присутствуют, наиболее быстрый путь разобраться.
no subject
Date: 2016-12-12 06:50 am (UTC)А 2.5 хотят EOL в 2017