[pkg-firebird-general] [long] firebird 2.0 - and now what?

[Kai Bäsler]

Hello Damyan,

Am 09.06.2006 um 16:48 schrieb Damyan Ivanov:
>
> Generally, I think we can be OK if 2.0 server is working with
> 1.5-created databases even with limited capabilities.

I agree here.


> It would be fine if this approach is possible:
> 1) forget about separate packages for 2.0 servers
> 2) 2.0 server can read 1.5 databases
> 2.1) 2.0 packages convert security.fdb to security2.fdb on upgrade
>    (with big warning, since this conversion can't use advanced
> password hashing used in security2)
> 3) admin checks new updatable view semantics and fixes them  
> appropriatelly
> 4) admin checks for conflicts with new keywords
> 5) admin makes a backup and restores to *different* location
> if 5) gives errors, go to 3) and 4) and repeat
> 6) happy, happy admin uses 2.0 and moves old databases away
>

This sounds reasonable to me.


> For this to happen, 2.0 server must be able to work (manipulate
> metadata and take backup) of 1.5 database - and this is something that
> needs testing. I'll do it with a copy of out 19G production database
> and report (within a couple of weeks).
> It is also important that no automatic ODS upgrade is done when 2.0
> server works with 1.5 database, because if admin decides to get back
> to 1.5, the database would use unsupported ODS.

I agree. I will test our databases too.


> This reminds me of another possible problem. What if 1.5->2.0 move is
> not completely ok and admin wants to go back and continue using 1.5?
> (Restore pre-upgrade backup is a possible solution, but kind of
> non-optimal)

That would not be a problem if there were two separate (1.5 and 2.0)  
versions.


>
> My idea was that leaving 1.5 listening on non-standard port is only
> temporary until databases are migrated. Something like the following:
>
> -1) ... friday ... noone is suspecting anything
> 0) ...saturday morning...
> 1) install 1.5 listening on 3060
> 2) install 2.0 listening on 3050
> 3) make 1.5 databases compatible with 2.0 and take a backup (all this
> using 1.5 server on port 3060)
> 4) restore on 2.0
> 4a) in case of a problem, go to 3)
> 5) ... monday morning ...
> 6) all client applications happily work with 2.0 server and converted
> databases on the same standard port 3050
> 7) sysadmin takes a long vacation on a desert island :)
>
> Perhaps all this may be made selectable on install. Something like:
> ,----------
> |   What version of firebird do you want running on default port?
> |
> |   ( ) 2.0
> |   ( ) 1.5
> `-----------
> Similarly to XDM selection.

My environment is more like 24x7. Your idea won't work for me :/

If you still plan to run both versions on different ports, then  
_please_ leave 1.5 on 3050. But there are strong arguments against  
changing the port, see below.


>
>>> I see very much value in the ability to both keep old 1.5 databases
>>> working while at the same time making experiments with 2.0. ...
>>
>> I see your point, but i think this could make many users go crazy.  
>> The
>> only reasonable way to have two different versions running on the  
>> same
>> host is (IMHO) to bind to different ip-addresses.
>
> Unfortunatelly firebird can't bind to specific interface, AFAIK.

Take a look at /etc/firebird2/firebird.conf. Search for  
"RemoteBindAddress". It works.

But it does not work as you might expect. If you change  
"RemoteBindAddress" to something other than 127.0.0.1, you're doomed.  
fbmgr seems to have a hardcoded 'localhost' and port 3050, and no way  
to change this on the command line. As a result you loose the ability  
to shut the server down. I've tested this with SuperServer. I suspect  
other tools (isql, gsec, gfix) will also fail when you try to connect  
to a different Port. AFAIK they all look for the "gds_db" entry in / 
etc/services, which can only be there once.

Next problem is Classic. With Classic, inetd has to open the  
listening port, and inetd can't bind to a specific interface (xinetd  
does this, and i've seen an modified inetd for OpenBSD doing this),  
so RemoteBindAddress is useless with Classic.

I will take a closer look at these issues next week.