IDS Forum

Re: New RFE

Posted By: Art Kagel
Date: Friday, 7 July 2017, at 12:26 a.m.

Madison:

I submit option #4:

4) On converting the table to standard, begin a logged copy of the table to
a new table replicating the copy, then reapply any log records recorded by
changes to the original table, finally rename the tables and drop the
original version.

Done this way the existing replication mechanisms are used to replicate the
table rather than coding something completely new.

Does that sound doable? To me it sounds simpler.

Art

Art S. Kagel, President and Principal Consultant
ASK Database Management
www.askdbmgt.com

Blog: http://informix-myview.blogspot.com/

Disclaimer: Please keep in mind that my own opinions are my own opinions
and do not reflect on the IIUG, nor any other organization with which I am
associated either explicitly, implicitly, or by inference. Neither do
those opinions reflect those of other individuals affiliated with any
entity with which I am affiliated nor those of the entities themselves.

On Thu, Jul 6, 2017 at 10:26 PM, Madison Pruet <madison_pruet@yahoo.com>
wrote:

> I had played around with doing this for ER as well so that we could
> include it with the GRID automatic replication. It might actually be in
> the product if you are connected to the grid when you convert the table
> from RAW to STANDARD.
>
> Now for the technical issue.
>
> The copy of the table to ALL of the secondaries must be done while the
> table is static. This is similar to the issue with index creation with
> HDR/RSS. Until the copy of the index is done to all of the secondary
> servers, the table is locked. With RSS we required index creation logging
> so that we didn't have to deal with the issue of what to do if one of the
> RSS nodes was down. By making the copy of the index pages into the logical
> log, then we didn't require coordination with the secondaries. Also as
> part of that effort, we blocked the client thread until the index copy was
> completed. This was done because of the old problem of creating an index
> on an HDR primary and then getting an error if you tried to immediately
> update the table after you got released from the CREATE INDEX statement.
>
> Of course the logging of the index would be considerably shorter than
> trying to do the same thing with a raw to standard table conversion.
>
> It is very important to understand that until the copy of the table is
> complete on the secondary server then no logs for that table can be applied
> on that secondary. This creates a tremendous coordination problem for
> transfer of the table. The copy of the table MUST be the version
> corresponding the table PRIOR to any logs being applied on that secondary
> server. Otherwise the secondary server would encounter a log apply failure
> which would cause a failure on the secondary server.
>
> To be honest, the only way that I can think of to make this functionality
> work would be to make a static copy of the raw table as it is being
> converted into a standard table and then transfer that copy of the table to
> the secondary server PRIOR to applying any future logs. This is pretty
> much what happens with the INDEX transfer on an HDR pair when you have
> index page logging turned off. Logs can not be applied on the secondary
> until the index is transfered. That's why we suggested having a log
> staging area set up on HDR secondary servers. The logical logs can still
> be sent to the secondary while the index is being transfered and as soon as
> the transfer is completed, then we can start applying the staged logs.
> That way you still have log redundancy during the index transfer.
>
> Of course if a copy of the raw table was kept (and maintained by the
> server) then it would need to be kept until ALL secondary servers had that
> table copied. Remember - we can't apply log pages on the secondary until
> the table would have been transfered.
>
> So - as part of this RFE, which I think is a valid RFE, you need to
> specify what characteristics you would be willing to live with.
>
> 1) Keep a copy of the raw table as of the conversion of the table back to
> standard until ALL secondary servers had a copy of the table
>
> 2) Keep a long term lock on the table until all secondary servers had a
> copy
>
> 3) I guess a third possibility would be to coordinate the copy of the
> table with the apply of logs on the secondary. But that would require
> locking the table as each of the secondary nodes came on line so that a
> static copy could be made.
>
> Madison Pruet
> Retired and Loving it
>
>
> On Thursday, July 6, 2017 1:26 PM, Art Kagel <art.kagel@gmail.com> wrote:
>
>
> Folks:
>
> I have created a new RFE described as follows:
>
> It is significantly faster to load a table in TYPE(RAW) mode than
> TYPE(STANDARD) mode. However, this option is not practical for sites using
> HDR and/or RSS secondary servers for replication as RAW mode tables do not
> replicate forcing the site to break and reestablish replication from
> scratch producing a period of time during which there is no secondary
> backup for the primary server.
>
> But in most of these situations the table being loaded is needed on all
> copies of the server precluding using this method. I would suggest an
> option to the ALTER TABLE <table name> TYPE (STANDARD); that would copy the
> data to the secondaries in the background after altering the primary copy
> of the table to standard.
>
> Suggested syntax:
> ALTER TABLE <table name> TYPE( STANDARD WITH REPLICATION );
>
> Here's the link to the RFE record:
> http://www.ibm.com/developerworks/rfe/execute?
> use_case=viewRfe&CR_ID=107441
>
> If you think this might be useful to you please vote for it.
>
> Art
>
> Art S. Kagel, President and Principal Consultant
> ASK Database Management
> www.askdbmgt.com
>
> Blog: http://informix-myview.blogspot.com/
>
> Disclaimer: Please keep in mind that my own opinions are my own opinions
> and do not reflect on the IIUG, nor any other organization with which I am
> associated either explicitly, implicitly, or by inference. Neither do
> those opinions reflect those of other individuals affiliated with any
> entity with which I am affiliated nor those of the entities themselves.
>
>
>
> _______________________________________________
> Informix-list mailing list
> Informix-list@iiug.org
> http://members.iiug.org/mailman/listinfo/informix-list
>
>
>

IDS Forum is maintained by Administrator with WebBBS 5.12.