Willkommen bei Entwickler-Forum.
Ergebnis 1 bis 5 von 5
  1. #1
    Stammgast
    Registriert seit
    03.08.2007
    Beiträge
    204

    Standard eines von mehreren Schemata wird nicht repliziert

    Hallo,

    ich habe einen MySQL-Server mit einem guten Dutzend Schemata, manche sollen repliziert werden, manche nicht. Dies realisiere ich über diverse replicate-wild-do-table = schema.% - Einträge in der my.ini des Slaves. Funktioniert alles wie es soll. Abgesehen von einem Schema, welches einfach nicht repliziert wird. Woran kann das liegen? Es gibt keinen Filter in der my.ini des Masters, und ein entsprechender replicate-wild-do-table-Eintrag beim Slave ist selbstverständlich vorhanden. Gibt es weitere Konfigurationsmöglichkeiten, um die Replikation eines Schemas zu verhindern? Oder irgendwelche wilden Konstellationen, die das verhindern könnten? Stehe vor einem Rätsel.

    Weiß jemand Rat?

    Dave
    Geändert von Dave_Bowman (05.04.2012 um 09:39 Uhr)

  2. #2
    Stammgast
    Registriert seit
    03.08.2007
    Beiträge
    204

    Standard

    Ja, sorry, dass ich das Thema nochmal anspreche. Hat wirklich niemand eine Idee? Offenbar funktioniert die Replikation prinzipiell, denn Änderungen, die ich mit der Workbench auf dem Master vornehme, werden repliziert. Scheinbar sind 'nur' alle Änderungen betroffen, die innerhalb eines bestimmten Programms vorgenommen werden. Also scheint das an diesem Programm zu liegen. Der ConnectionString jedoch sieht völlig normal aus, es werden keine zusätzlichen exotischen Parameter übergeben, Standard-Schema ist das betreffende, und die Applikation funktioniert ja auch auf dem Master, alle Änderungen werden korrekt auf Platte geschrieben. Nur irgendwie so, dass die Replikation diese Änderungen ignoriert. Habe zwischenzeitlich auf Eigenheiten beim binlog-Format (MIXED) getippt, aber dann würden diese Probleme ja auch in anderen Schemata vorkommen.

    ... ich kapier's nicht ... jemand noch eine Idee?

    Dave

    Edit: Der Vollständigkeit halber hier der ConnectionString: DRIVER={MySQL ODBC 3.51 Driver};SERVER=localhost;PORT=xx;DATABASE=knw;USER =root;PASSWORD=pw;

  3. #3
    Aufsteiger
    Registriert seit
    26.02.2003
    Ort
    Schweiz, 3629
    Beiträge
    62

    Standard

    Hmm, du verbindest aus einer Applikation über den Root User?

    Geh mal dieses Dokument durch:
    http://dev.mysql.com/doc/refman/5.1/...ion-rules.html

    Was meint ein "SHOW MASTER STATUS;" (auf dem Slave natürlich)?

  4. #4
    Stammgast
    Registriert seit
    03.08.2007
    Beiträge
    204

    Standard

    Das Dokument bin ich schon durchgegangen, wenn auch nicht detailliert. Im Grunde aber würden ja die Kriterien auf alle Schemata zutreffen, das Problem tritt aber nur bei einem auf. Ein Schema von 13. Alle anderen 12 werden wunderbar repliziert. Auch würde dann die Tatsache, dass Änderungen in der Workbench übernommen werden, keine Rolle spielen. Oder?

    Ja, das mit dem 'root' ist mir bewußt. Ist hier aber gängige Praxis.

    Ich meine, dass es was mit der Applikation zu tun haben muss. Würde ich zumindest sagen ...

    Master Status ist leer, weil wir auf dem Slave kein BinLog führen.

  5. #5
    Stammgast
    Registriert seit
    03.08.2007
    Beiträge
    204

    Standard

    [Problem erledigt]

    nur für's Protokoll, ich habe das Rätsel gelöst ...

    ... es lag am Dump, der (immer gleich) mittels Batch in der Nacht erstellt wurde. Irgendwann wurde ein Schema vom Server entfernt, welches jedoch noch in der Batch als zu dumpendes Schema enthalten war. Die Folge: Der Dump wurde insofern abgebrochen, als dass alle weiteren Schemata ignoriert wurden (betraf aber nur dieses eine letzte). Also wurde nie ein neuer Dump dieses Schemas auf dem Backup-Server eingespielt. Das erklärt, warum meine Änderungen auf dem Server immer repliziert wurden, die Checksummen dennoch nie stimmten und ich also auf das Programm als Fehlerursache schloss.

 

 

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •