Re: ER and inplace upgrade 7.31 to 9.40

1) Drain the queue 2) run cdr stop 3) migrate the server to 9.4 4) Add the sbspace for the queue 5) modify onconfig to point to the new sbspace 6) run cdrcon 7) run cdr start ER migration is an external process because the server must be on 9.4 with the sbspace existing prior to running the conversion script. Yes, you need to have an sbspace because the stable queue is in an sbspace on 9.x. We moved the queue to an sbspace rather than using the 7.x partition blobs because we could treate the sbspace as a file. That means that we only have to have a single row per transaction instead of multiple rows (one per buffer) plus the blob which contained the row data. Also, by using sblobs, the space is reclaimed when the queues drain, unlike what happens with the 7.x stable queue. This process is described in the migration guide. "Andrew Hamm" <ahamm@mail.com> wrote in message news:<2t90hoF1sngogU1@uni-berlin.de>... > Hi folks > > I need to upgrade 7.31 to 9.40 on servers which partake in Enterprise > Replication. We did a test server, and it barfed because of a few things: > > 1) needs new parameters in $ONCONFIG (minor, could have avoided this with > a bit of RTFM on the release notes) > > 2) lack of new attached sbspaces caused cryptic but total failure. It > appears that the sbspaces MUST be attached to run ER? > > We have a production server to upgrade next, so it must go smoothly. The > first one was a bit of a hunt-the-snark exercise to find out what was > screwing up so it's hard to draw simple rules after all the tail-chasing > and confusion. > > Basically, what's an effective ritual for this upgrade? > > Is it true that the new sbspaces must exist? The ER guide for 9.40 says, > on page 4-14, > > Important: Before starting Enterprise Replication, you must create at > least one > sbspace for spooled row data and set the CDR_QDATA_SBSPACE configuration > parameter to its location. > > We have no UDT's or other data types that are to be replicated; so this > rule seems a bit harsh. > > When initialising a server to ER with 7.31, you use a --send and --recv > parameters to specify the send queue and the recv queue. Now it seems that > 9.40 has combined these into a single dbspace that is defined with a new > CDR_QHDR_DBSPACE. What will happen during the upgrade? We have only > defined a send q in the 7 engines. Can we expect the upgrade to map that > into the $ONCONFIG in this parameter? If not, ........... we need to > manage the movement of the q spaces. > > So for the upgrade, we have two possible plans - one is hard but hedges > all bets we can think of, the other is faster and keeps the other server > online for users, but we're not sure it's reasonable. > > HARD WAY: > > * stop users on both machines (of course) so there's no data changes > > * delete replicants. > > * cdr delete server to remove the server that's about to be upgraded; > performed twice in the usual manner; once on the server being deleted, and > once on another server to clean up it's catalog. The other server can stay > defined as an ER server; albeit a lonely friendless one. > > * reclaim the sendq (actually, leave it in place to be used for the > CDR_QHDR_DBSPACE). If we had a sendq and a recvq then I guess we'd have to > consolidate them. > > * shutdown the engine. > > * re-start the engine using 9.40 and allow it to perform the upgrade > conversion. > > * create the apparently mandatory sbspaces. > > * shutdown again > > * modify $ONCONFIG for the new CDR parameters (some old ones are removed, > some new ones are added) > > * bring the engine online. > > * (re)define the server to be a replication server, synchronising to the > other ER server > > * define all the replicants again > > > QUICKER WAY: (not sure if this plan is workable) > > * stop all users only on the engine to be upgraded. > > * suspend replication on both servers. > > * shutdown the server being upgraded. > > * bring it up TO QUIESCENT MODE using the 9.40 software, let it perform > the conversions. > > * reclaim the old queue dbspaces (consolidate if necessary etc) > > * attach the new sbspaces > > * shutdown to offine > > * edit $ONCONFIG for new CDR parameters > > * bring to online mode - hopefully replication is still working despite > potential confusion with the old send q, and the newly attached sbspaces > > * resume replication > > > Can this shorter ritual work? If so it means that the OTHER server can > continue to have users; it will accumulate changes in it's sendq and > deliver them once replication is resumed. > > Thanks in advance, Madison (or anyone else who's been there, done that) > > PS - the IDS Administrator's guide, page 4-13, in Figure 4-2, "Operating > Modes" contains this Freudan slip: > > "Maintenance mode Online mode with access restricted to users root and > informix. Users cannot initiate maintenance mode. The database server uses > this mode." > > but I cannot see any other mention of this. Is this perhaps a > sneak-preview of the future?