Unsupported Screen Size: The viewport size is too small for the theme to render properly.

Source Target Conflicts And Precedence.

forums forums SQLyog Sync tools, Migration, Scheduled Backup and Notifications Source Target Conflicts And Precedence.

  • This topic is empty.
Viewing 5 reply threads
  • Author
    Posts
    • #24484
      peterlaursen
      Participant

      I am not sure I understand every detail (or rather : I am sure I do not ..)

      the terms MASTER and SLAVE do not make sense with SQLyog synchronisation. Synchronisation is not replication! We use the terms SOURCE and TARGET – NOT MASTER and SLAVE.

      The only 'conflict rule' currently supported by SQLyog/SJA is 'source overwrites target'.

    • #24485
      tjmcd
      Member
      peterlaursen wrote on Jul 6 2007, 07:47 PM:
      I am not sure I understand every detail (or rather : I am sure I do not ..)

      the terms MASTER and SLAVE do not make sense with SQLyog synchronization. Synchronization is not replication! We use the terms SOURCE and TARGET – NOT MASTER and SLAVE.

      The only 'conflict rule' currently supported by SQLyog/SJA is 'source overwrites target'.

      Sorry,

      MASTER and SLAVE are arbitrary designations — for explanatory purposes only — denoting … I'll try again …

      • Our primary db hosted (remotely) at ourdomain.com [MASTER],
      • AND numerous mirror dbs hosted locally on numerous tablet pc's in the field (SLAVES)
      • with intermittent connectivity which precludes them from working from primary or MASTER exclusively

        so necessitating frequent synchronization

      And yes, that is my understanding 'source overwrites target' which is the root of the problem.

      Would be nice to be able to indicate SOURCE overwrites TARGET WHERE … else TARGET overwrites SOURCE

      Otherwise, updated records on target WILL BE OVERWRITTEN by those that have NOT been updateed on source.

    • #24486
      tjmcd
      Member

      Or… might one run 2 two-way syncjobs …

      One with MASTER as socurce AND something like

      `soruce.date_modified`>`target.date_modified`

      for each table in the job …

      AND One with SLAVE as socurce AND something like

      `soruce.date_modified`>`target.date_modified`

      ????? 🙄

    • #24487
      peterlaursen
      Participant

      We are considering various other 'conflict resolving rules' – including one based on a 'most recent TIMESTAMP on update CURRENT_TIMESTAMP'. We are not able to do it overnight! It is complicated actually!

    • #24488
      tjmcd
      Member
      peterlaursen wrote on Jul 7 2007, 08:22 AM:
      We are considering various other 'conflict resolving rules' – including one based on a 'most recent TIMESTAMP on update CURRENT_TIMESTAMP'. We are not able to do it overnight! It is complicated actually!

      Okay, Great News.

      Meanwhile, you avoid my inquiry regarding a work-around.

      Please,

      any suggestions on how we might make use of http-tunneling (SQLyog's or

      third party php compatible ) to facilitate automation of our little

      work-around would be greatly appreciated.

      Surely I'm not the only one to have suggested such a work around,

      which is quite viable especially given a more flexible/workable tunneling

      solution which would eliminate the need for AN ADDITIONAL and otherwise

      SUPERFLUOUS DATABASE (as originally described).

      Regards

      TJ

    • #24489
      peterlaursen
      Participant

      it I knew a workaround out of my head, I would have told of corse.

      But I do not understand how this is related to HTTP-tunnel. I think the connection type (direct. SSH or HTTP) does not matter?

      there have been lot of requests about improving DATA SYNC. Including several requests that we should implement a magician in SQLyog. Unfortunately MySQL AB provides no API for this ….

      By saying so I did not mean to be 'nosy', but basically traditional SQL databases like MySQL are NOT designed as distributed databases!

      An option you could consider is to connect to a (central) server using a connection from every tablet based on 3G Mobile Phone technology.

Viewing 5 reply threads
  • You must be logged in to reply to this topic.