Hallo,
ich möchte einen laufenden mysql-Server replizieren.
In der my.cnf habe ich

[mysqld]
log-bin
server-id=1
binlog-do-db=database

Die Datenbank 'database' wird sekündlich mit Daten gefüttert.
Leider gibt aber ein 'SHOW MASTER STATUS\G' immer dieselbe Position im
Logfile aus:

File: mysql-bin.000002
Position: 98
Bin_Do_DB: database
Binlog_Ignore_DB:

Da die Datenbank aber stetig wächst, stellt sich die Frage, warum das
Logging nicht funktioniert.

Mit freundlichen Grüßen
Christoph

--
Christoph Nickel
c.nickel [at] bp-aachen.net

Christoph Nickel <C.Nickel [at] bp-aachen.net> wrote:

> ich möchte einen laufenden mysql-Server replizieren.
> In der my.cnf habe ich
>
> [mysqld]
> log-bin
> server-id=1
> binlog-do-db=database
>
> Die Datenbank 'database' wird sekündlich mit Daten gefüttert.
> Leider gibt aber ein 'SHOW MASTER STATUS\G' immer dieselbe Position im
> Logfile aus:
>
> File: mysql-bin.000002
> Position: 98
> Bin_Do_DB: database
> Binlog_Ignore_DB:
>
> Da die Datenbank aber stetig wächst, stellt sich die Frage, warum das
> Logging nicht funktioniert.

Hast du mal ins Errorlog geschaut? Vielleicht gabs ja einen Fehler,
das File anzulegen. 98 ist jedenfalls die "richtige" Startposition
nach dem Header des Binlogs.

Ein weiterer Stolperstein: binlog-do-db filtert anhand der aktuell
ausgewählten Datenbank. Also würde z.B.

mysql> use test;
mysql> update database.foo set bar='baz';

*nicht* ins Binlog geschrieben, obwohl es Daten in der `database`
Datenbank verändert.


XL

Axel Schwenke schrieb:
>
> Ein weiterer Stolperstein: binlog-do-db filtert anhand der aktuell
> ausgewählten Datenbank. Also würde z.B.
>
> mysql> use test;
> mysql> update database.foo set bar='baz';
>
> *nicht* ins Binlog geschrieben, obwohl es Daten in der `database`
> Datenbank verändert.


Ähm, Axel? Das ist wirklich wahr sein und ist nicht als
major-critical-blocker-bug eingeordnet? Das macht doch den Sinn der
Auswahl vollkommen widersinnig.

Grüße

Dirk

Dirk Brosowski <dirk_brosowski [at] web.de> wrote:
> Axel Schwenke schrieb:
>>
>> Ein weiterer Stolperstein: binlog-do-db filtert anhand der aktuell
>> ausgewählten Datenbank. Also würde z.B.
>>
>> mysql> use test;
>> mysql> update database.foo set bar='baz';
>>
>> *nicht* ins Binlog geschrieben, obwohl es Daten in der `database`
>> Datenbank verändert.
>
> Ähm, Axel? Das ist wirklich wahr sein und ist nicht als
> major-critical-blocker-bug eingeordnet? Das macht doch den Sinn der
> Auswahl vollkommen widersinnig.

Jein. Es ist so dokumentiert. Also ist es zumindest kein Bug :-)
Allerdings schränkt es den Wert dieser Option tatsächlich ein.

Die replicate-{do,ignore}- Optionen auf Slave-Seite können aber
bis auf einzelne Tabellen einschränken. Im Zweifelsfall sollte
man lieber alles ins Binlog kippen[1] und auf dem Slave filtern.


[1] das ist auch hilfreich, wenn man das Binlog für point-in-time
recovery verwenden möchte.

XL