Creating new server from existing one

Hi, I need to stand up a 2nd Informix server on the same host, but, with a different name. I plan to use the same exact dbspaces/chunks as the source server, but, obviously with a different server name. The existing server hosts a large database instance which cannot be recreated very quickly. Thus the intention to copy the existing dbspaces. Is creating a 2nd server as "simple" as renaming the various files in the alternate $INFORMIXDIR, and replacing any config references to the source server to the new one? Any pointers, or advice in this matter would be greatly appreciated. Thanks in advance. #Informix

you could use your ontape backup and build the new server with ontape -r -rename -p <-oldpath> -o 0 -n <newpath> -o 0Regards Rainer ------------------------------ Rainer von Bongartz ------------------------------

Daanii, Use the same $INFORMIXDIR but create one more $ONCONFIG file ( set the environment accordingly, obviously). Then do as Rainer suggested Ifxclone is another way of doing it Eric Eric Vercelletto KandooERP Founder and Community Manager www: https://kandooerp.org IBM Champion 2013,2014,2015,2016,2017,2018,2019,2020 Mob : +33(0)626 52 50 68 skype: begooden-it Google Hangout: eric.vercelletto@begooden-it.com Email: ericv@kandooerp.org

Danil: Here are a few things you should know about this: The two instances can share the same $INFORMIXDIR The ONCONFIG file must have a different name for each instance In the ONCONFIG file the following parameters must be different: SERVERNUM DBSERVERNAME DBSERVERALIASES DRALIAS (if set)The two instances can share an sqlhosts file. They MUST share a single file (or two otherwise identical files) if they will need to be able to query each other - optional otherwise. If different files, use the SQLHOSTS or INFORMIXSQLHOSTS environment variable to identify which sqlhosts file to use for clients connected to one instance or the other. The chunk paths CANNOT be the same on the two instances! The dbspace names can be the same, but the paths must be different (OK different unless both are using relative paths which is not best practice)! OK, advice: I'm not certain of the purpose of this 2nd server on the same host. If you intend for this to be a DR server in case you lose the main server, I have some questions: If you install again into a separate INFORMIXDIR, then, depending on how you replicate you MAY have to pay additional licensing fees to remain compliant with IBM requirements. Be careful. This scheme gives you no protection against losing the entire server host, nor against losing the storage it is attached to and the two servers will presumably be sharing! Why not a separate DR server? If you have a separate DR server then you can use HDR to maintain a complete and up-to-date copy of the primary server which is easy to implement and maintain and does not require a separate license for the HDR secondary! How do you plan to maintain this second server in sync with the primary? If ER then you may run into the license issues I mentioned above. I suppose you could do a physical restore (ontape -p) then use continuous log restore (ontape -C), but that is cumbersome to manage and maintain. You COULD use HDR with this I suppose, and HDR secondary does not require additional licenses if it is not accessed while the primary is online, but then, again, what's the advantage? 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.

Hello Daniil, I am not sure if I understood the question correctly. To use chunks of the same file name in different instances on the same host, you must use relative path names. In my case, I have configured Primary, HDR, and RSS instances that use relative paths for testing purposes (using ontape), but I haven't seen customers using relative paths on production servers. (Of course, there may be customers who use it that way) To change an existing chunk from an absolute path name to a relative path, I need to stop the instance and change it to a relative path name, but I think it is a burdensome task as it may take a long time to get downtime. ------------------------------ SangGyu Jeong Software Engineer Infrasoft Seoul Korea, Republic of ------------------------------

Thanks everyone. Waiting for a few spare cycles to digest the various responses. Apologies for the somewhat misleading requirements. I did mean to have a "copy" of the chunks from the source server (I quoted copy because they're effectively pointing to the same inodes). To elaborate my situation a bit more: The servers are basically for testing and development purposes, so test-dev convenience prioritizes over performance in this instance We're primarily interested in snapshot and restore capability, particularly one that offers fast restore So, both servers would be snapshots of a well known state, and would be restored back to this state often (i.e. test-dev pipeline) The way the restore mechanism is currently implemented, requires snapshoting INFORMIXDIR (in addition to the chunks directory); we'd prefer a cleaner separation of an entire server+instance to mitigate the possibility of devs tripping over each other if modifying anything in INFORMIXDIR - basically, they can do whatever they want with their server+instance and not impact anyone else The dataset we're dealing with has to be a copy of the full size production database, so simply rebuilding a new server each time we restore as part of a pipeline/workflow is logistically untennable, especially given the requirement for fast restore The licensing will be fine Daniil

if you have used relative path, then you can have many instances on same server using same $INFORMIXDIR and one unique $ONCONFIG for each instance. And if you are using relative path then yes you have to restore backup with rename option. Regards, Gaurav ------------------------------ Gaurav Kumar ------------------------------

In response to Ranier's suggestion: Good start but it's difficult to substitute new file names on just the command line. What I did for Onyx in 2013, pulling it off backup files sent from Texas, was to set up a file of: 'cause you can't supply new names to 200 chunk files in the command line. Suppose you call this file new-names.txt. So the restore command would look more like Of course, you need to guarantee that the new chunk files already exist and that NONE of them overlap (and certainly not coincide) with any of the files on the old server. If you're using cooked file chunks, see if you can get all the new files in a totally different mounted file system. Raw devices? OK, see if you can create them in a different controller. What's the quickest way to get a list of the chunk files? onstat -d, and chop off the DBspaces portion of the output. It won't help for the symlinks, though. I wrote a Perl script that would help you get that information as well and I see I have not gotten around to posting it to IIUG. It's called spaces.pl and it depends on two other of my modules: Data::UNLreport (in CPAN) and DBspaces.pm (in a shared folder on my Google drive). Good luck. And, of course, make sure your old system is backed up, level-0, before you try any of this. Stuff happens. :-( -- Jacob S

Okay, so I'm getting the following error when attempting to start the 2nd server: 13:43:05 B-tree scanner index compression level set to med. 13:43:05 Physical Recovery Started at Page (2:76121). 13:43:05 Physical Recovery Complete: 1041 Pages Examined, 775 Pages Restored. 13:43:05 Logical Recovery Started. 13:43:05 100 recovery worker threads will be started. 13:43:05 Transaction Not Found. 13:43:05 Log Record: log = 458, pos = 0x28017e4, type = OLDRSAM:HUPBEF(42), trans = 56 13:43:06 Cannot Rollforward from Checkpoint. 13:43:07 oninit: Fatal error in shared memory initialization 13:43:07 IBM Informix Dynamic Server Stopped. 13:43:07 mt_shm_remove: WARNING: may not have removed all/correct segments From my limited research the shared memory errors are apparently a red herring. It would seem the real problem is the " Transaction Not Found " and " Cannot Rollforward from Checkpoint " notifications. Now, I've copied the entire INFORMIXDIR, and chunk files to a directory dedicated to the 2nd server. The only changes I've made are in renaming and/or editing the onconfig, sqlhosts, and env files so that they refer to the 2nd server. Aside from the aforementioned changes, the 2nd server is an exact copy of a snapshot of the source server (snapshot taken while the server was shutdown). I can restore to the snapshot and start the source server fine (every time) if I don't make any of the 2nd server changes. According to this relatively old post: * http://members.iiug.org/forums/ids/index.cgi/noframes/read/36151 I can force the server to the next log (whatever that means). Is it possible to "reset" the logs and/or checkpoint on the source server before taking another ("better"?) snapshot?

Update: For anyone interested, I ended up containerizing the servers (using LXD). So far, it seems to work well, and restoring the database to a model state appears to add little (if any noticeable) latency to the previous process. The only curious thing I noticed was that the logging state hadn't been duplicated when I copied INFORMIXDIR. The containers are persistent, so updating the model state via ontape resolved that (we snapshot, then restore to model for common case work flow). However, this implies that logging state determination is calculated using data outside of INFORMIXDIR (including the chunk files) (?)

Hi, "(I quoted copy because they're effectively pointing to the same inodes)." Instances cannot point to the same inodes, the writes will get mixed up and the instances will corrupt one another. Each instance has to point to it's own set of inodes. Having said that snapshots can be taken and then used to create a new volume with a copy of the data. If the underlying array can de-dupe the storage between the 2 volumes then this works fine. Especially if the 2 volumes are thinly provisioned as well! You would have to have each instance in a seperate VM or container so the pathnames are the same across instances. The same can be done for $INFORMIXDIR as well, or this could just be stored once in a central tar/cpio/zip file and unpacked as needed. David. ------------------------------ David Williams ------------------------------

The logging state for the database is stored within the chunk files. Are you sure you are snapshoting/restoring the whole instance? ------------------------------ David Williams ------------------------------

Yes, it's a bit strange. I certainly hope the whole instance is being copied! I may run a basic integrity check against the original snapshot.