GT.M Replicator

Help
Adrian G
2007-05-08
2012-12-29
  • Adrian G
    Adrian G
    2007-05-08

    Hello

    Can one instance of replicator can replicate more then one database, or I need to create an instance for each database?

    Thanks

     
    • Hi,

      A replication instance consists of an entire MUMPS global variable name space, which can consist of multiple database files, all of which are replicated together.

      Thanks,
      Narayanan.

       
    • Adrian G
      Adrian G
      2007-05-08

      Great news, but how can I do it, for example:

      SOURCE:
      gtmgbldir=/cav/gtm/cav/cav.gld; export gtmgbldir

      gtm_repl_instance=/cav/gtm/$ade.gld; export gtm_repl_instance

      /cav/gtm/mupip set -FILE $/cav/gtm/cav/cav.dat -replication=ON

      /cav/gtm/mupip replicate -source -start -secondary=192.168.77.26:3000 \ log=/var/log/gtmreplicatesource.log -instsecondary=adebck

      RECEIVER:
      gtmgbldir=/cav/gtm/cav/cav.gld; export gtmgbldir
      gtm_repl_instance=/cav/gtm/$adebck.gld; export gtm_repl_instance

      /cav/gtm/mupip set -FILE /cav/gtm/cav/cav.dat -replication=ON

      /cav/gtm/mupip replicate -source -start -passive \ -log=/var/log/gtmreplicatesourcepassive.log -instsecondary=ade

      /cav/gtm/mupip replicate -receiver -start -updateresync \ -listenport=3000 -log=/var/log/gtmreplicatereceiver.log

      The above example work without problem with one database, the problem is that I can't
      add more then one path to "$gtmgbldir" and GT.M replication need the "$gtmgbldir" parameter. I try to add:
      gtmgbldir=/cav/gtm/cav/cav.gld /cav/gtm/acc/acc.gld; export gtmgbldir
      or gtmgbldir="/cav/gtm/cav/cav.gld /cav/gtm/acc/acc.gld"; export gtmgbldir
      or gtmgbldir="/cav/gtm/*.gld"; export gtmgbldir
      but without success, it alway fail with the error:

      %GTM-E-ZGBLDIRACC, Cannot access global directory $gtmgbldir.  .
      %GTM-E-FILENOTFND, File  not found
      Tue May  8 16:38:29 2007 : Source server exiting...

      %GTM-E-ZGBLDIRACC, Cannot access global directory /cav/gtm/*.gld.  Retaining .
      %SYSTEM-E-ENO2, No such file or directory
      Tue May  8 16:39:47 2007 : Source server exiting...

      Thanks

       
      • Assuming each of your .gld files corresponds to non-intersecting database files, you need to create a replication instance file for each of them separately and start as many sets of replication servers (one for each .gld file).

        Thanks,
        Narayanan.

         
    • Just to clarify a bit. If you have multiple global directories that point to  the same set of database files (say, because of security design), they should use the same instance to insure proper operation under all circumstances. If you have multiple global directories that are not intersecting in their database files, it's generally better (but not necessary) to use separate instances for both operational and performance reasons.

      Roger

       
    • Adrian G
      Adrian G
      2007-05-09

      Thanks for the answer.

      I'm going to create an instance for each database.

      A question: when I try to check the data on the receiver server I get:
      %GTM-E-SCNDDBNOUPD, Database Updates not allowed on the secondary
                      At M source location SETM+1^MM
      I understand this error, I want to know if I can replicate and on the same time to allow
      updates on the receiver server?
      The reason that I want to to this is because I want to give other to test if the
      replication is working by log in to the secondary server and do some query.

      One more thing:
      When I start the source server, I run:
      /cav/gtm/mupip set -FILE /cav/gtm/cav/cav.dat -replication=ON
      It's right to run when you stop the source server:
      /cav/gtm/mupip set -FILE /cav/gtm/cav/cav.dat -replication=OFF ?

       
      • Updates are unconditionally disabled on the secondary in replicated database files. But they are still allowed on unreplicated database files that are part of the same replication instance. So you can create a separate region/segment/database file as part of the same global directory and have that non-journaled and non-replicated and use that for updates on the secondary. This will not intersect with the replicated updates coming in from the primary.

        To answer your other question, you do not need to run mupip set -replication=ON every time the source server is started. You need to do this ONLY once when you want to turn on replication and journaling. The same way, there is no need to turn replication OFF every time the source server is stopped. In fact, it is better NOT to do this. Every time replication is turned OFF and back ON, a new set of journal files are created and previous journal file links are cut so there is no way you can roll back to a previous state of the database in case you want to.

        Narayanan.

         
    • Adrian G
      Adrian G
      2007-05-10

      Big Thanks, great answer

      "The same way, there is no need to turn replication OFF every time the source server is stopped"
      I only turn on and off when the linux server is restart/or start.
      I don't need to turn replication on when I start the linux server, or shutdwon/power off?

       
      • There is no need to turn replication OFF/ON when the linux server is restarted. Replication properties are stored in the database file header so it is persistent across reboots.

        Narayanan.

         
    • Adrian G
      Adrian G
      2007-05-10

      Great, it's working.

      Now, the last problem:

      Before I run mumps -direct I need to do:

      gtm_repl_instance=/cav/gtm/INSTANCE.gld; export gtm_repl_instance

      and of course:
      gtmroutines="/cav/gtm/adi/ /cav/gtm/"; export gtmroutines
      gtmgbldir="/cav/gtm/adi/adi.gld"; export gtmgbldir

      Now, I use "%ZUCIMAP" to set "gtmroutines" and "gtmgbldir" inside mumps.
      My question is, how can I set "gtm_repl_instance" inside mumps?

      Thanks.

       
    • Adrian:

      Have you checked out $ZTRNLNM()?

      Roger

       
    • Adrian G
      Adrian G
      2007-05-11

      Yep, just check it and you can obtain the value of any environment variable through the $ZTRNLNM() function but I didn't find out how to set the value of any environment variable through the $ZTRNLNM() function.

      For exemple:

      GTM>W $ztrnlnm("gtm_repl_instance")
      /adi/gtm/ovd.gld
      GTM>

      I need to set "gtm_repl_instance"="/adi/gtm/ovx.gld"

       
    • Adrian:

      If you can't set it up before invoking GT.M or need to change it on the fly, I think you're going to need an external call. I wouldn't be surprised if someone has already implemented this - you might try asking in a thread about external calls. There was a $Z-function in VMS to do the analogous thing but it would take an enhancement to the Unix versions.

      Roger

       
    • Adrian:

      Potential bad news, my earlier response mentioned changing the instance on the fly - that won't work.

      The replication instance file name "$gtm_repl_instance" is used by a GT.M process to create/attach to a journal pool the first time an update happens to a replicated database. Once GT.M process has attached to a journal pool, it cannot attach to any other journal pool or replication instance.

      Roger

       
    • Adrian G
      Adrian G
      2007-05-12

      Not sure. it's true that "The replication instance file name "$gtm_repl_instance" is used by a GT.M process to create/attach to a journal pool the first time an update happens to a replicated database" but this is only true for the source/receiver server, it's not true for mumps -dircet because from my test, I run two instance for two different database and then use:

      gtm_repl_instance="/adi/gtm/ovx.gld"; export gtm_repl_instance
      mumps -dircet
      GTM>S ^TEST="123"

      gtm_repl_instance="/adi/gtm/tst.gld"; export gtm_repl_instance
      mumps -dircet
      GTM>S ^TEST="123"

      This work without problems, it update and replicate two different database.

       
      • Steven Estes
        Steven Estes
        2007-05-12

        Adrian,

        I'm not really understanding what configuration you are trying to create but there definitely are some rules in setting up replication. Only in the last couple of releases have some of these rules started to be enforced. Some of these rules are:

        1) One set of replication servers per defined instance.

        2) A given instance may have as many databases as you need to define and in fact, most installations do use only a single instance per "environment" with that instance having all databases necessary. There may be multiple instances on a box but the environments of those instances do not intersect.

        3) The gtm_repl_instance environment var defines which global directory is being replicated by the servers and defines to the GTM processes which databases are replicated in that instance. Mumps processes most certainly do attach to the journal pool related to the instance since they are the ones creating the journal data that gets replicated.

        4) A GTM process may use a different global directory from the instance ($gtmgbldir) but the databases defined in that global directory, if replicated, MUST all belong to the same instance. This is one area that was not enforced until sometime this year (V5.1 or V5.2 but I don't remember right now). But attempting to reference more than one replicated instance on an unenforced version will cause database and/or journal file corruption because of #5

        5) For the life of a GTM process, it can only ever attach to ONE instance. There is no capability of closing the instance to use a different one, which would be exceptionally expensive to do in terms of system resources due to all the syncing and database closure that would be required.

        The example in your post seems to show two different mumps processes using two different instances and I assume two different global directories. This is perfectly legal. But one process cannot access both instances nor can it switch on the fly.

        I think I stated that all correctly. But it is awfully early on a Saturday morning and I have not had a caffeine infusion yet.. ;-)

        Steve

         
    • Adrian:

      A clarification to Steve's points - since replication is about updates, a single process can read from database files outside its instance. However, if it tries to update outside its instance it gets a REPLMISMATCH error. If you try "outside" updates in a version before REPLMISMATCH was introduced, the sequence number gaps give the source service a headache and cause REPLBRKNTRANS errors. The newer error is intended to be more helpful in describing the cause.

      Roger