Re: ER and inplace upgrade 7.31 to 9.40

See below... "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? There are several reasons that we switched to using sbspaces rather the older table space. The tablespace required creating a transaction header for each spooled transaction, a sperate buffer row for the buffers within the transaction, and a partition blob for the data within each of the buffers. With 9.3+, we only have to create the transaction row and the smart blob for the data. With pre 9.3, the tablespace could only grow. Now the bulk of the data is in a blobspace and the space is returned to the blobspace as the spooled transaction is removed from the spool. That means that it's easier to use things like onstat -d to determine the consumption of the queue. Also, since the access to the smartblob is very similar to fileio, we are able to reload data from the queue as we needed it. With the older tablespace blobs, we had to reload the entire transaction from the blobs in order to process the transaction. By being able to use blobspaces for the spool, we are able to reload only the part of the transaction that we need - thus minimizing system impact. With pre 9.3, we had to be more careful about the recieve queue space and the send queue space because they were in tablespace blobs. By moving them to smartblobs, they can share the space because smartblobs return the space to the blobspace, unlike tablespace blobs. > > 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. See above for the reasoning for using sblobs rather than the older tablespace blobs. Basically much better resource utilization. Also, (by the way) with 9.4, we have the option to have multiple smartblob spaces. The idea being that we can hash between the spaces and equalize usage between them - and improve spooling performance. > > 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 keep a record of what they were in 7.31 in case of a subsequent reversion. Otherwise, we remove the column from the server definition. The old send/receive queue table had to provide space for both the buffer records and the tablespace blob containing the replicated rows. Those tables are dropped during the conversion process. New tables will be created. The key thing is that the new table will be MUCH smaller than the 7.31 table because we are not having to provide space for the tablespace blobs. > 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 Good > > * 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. This is not necessary. The cdr conversion program will convert all of the 7.31 metadata into the 9.x format. Takes about 10-15 seconds to run. It is necessary to drain the queues, however. > > * 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. Again - not necessary as the cdrcon program that is documented in the release notes does the necessary conversion. I would suggest running 'cdr stop' at this point, however... > > * shutdown the engine. I'd suggest updating the $ONCONFIG file at this point. > > * re-start the engine using 9.40 and allow it to perform the upgrade > conversion. > > * create the apparently mandatory sbspaces. yep... > > * shutdown again not necessary if you've already updated the onconfig file. > > * 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 Not necessary. cdrcon does the necessary conversion. > > > QUICKER WAY: (not sure if this plan is workable) > > * stop all users only on the engine to be upgraded. > > * suspend replication on both servers. (or run cdr stop once the send queue is drained.) > > * 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 Why not do this prior to starting the 9.4 system? > > * 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. Yes - but you need to run concdr (the program that converts the syscdr database to the 9.4 format. Please check the migration guide... Yes - the other servers can still run the prior servers... > > Thanks in advance, Madison (or anyone else who's been there, done that) > > PS - the IDS Administrator's guide, page 4-13, in Fig