Replikation und temporärer Tabellen

Hallo,
ich hab hier folgenden Aufbau: Master mit 4.1.21 und einen Slave mit 5.0.41.
Auf dem Master werden u.a. sehr viele temporäre Tabellen angelegt. Diese
werden auch auf den Slave repliziert. Auf dem Slave werden sie scheinbar
aber nicht mehr abgeräumt, jedenfalls bekomme ich auf dem Slave sehr schnell
einen Error 24 (Too many open files) und im Temp Verzeichnis liegen ca. 1400
Dateien von Mysql rum.
Auf dem Master werden die temporären Tabellen schon beim Schließen der
Verbindung weggeräumt und ein explizites DROP wird scheinbar von der
Anwendung nicht immer durchgeführt. Ich vermute, der Slave bekommt daher gar
nicht mit wenn die temporäre Tabelle gelöscht werden soll. Kann das sein?
Gibt es da Infos zu? Ich habe dazu direkt nichts gefunden.

Christian

Re: Replikation und temporärer Tabellen

Christian Schmelzer wrote:
> Hallo,
> ich hab hier folgenden Aufbau: Master mit 4.1.21 und einen Slave mit
> 5.0.41. Auf dem Master werden u.a. sehr viele temporäre Tabellen
> angelegt. Diese werden auch auf den Slave repliziert. Auf dem Slave
> werden sie scheinbar aber nicht mehr abgeräumt, jedenfalls bekomme
> ich auf dem Slave sehr schnell einen Error 24 (Too many open files)
> und im Temp Verzeichnis liegen ca. 1400 Dateien von Mysql rum.
> Auf dem Master werden die temporären Tabellen schon beim Schließen der
> Verbindung weggeräumt und ein explizites DROP wird scheinbar von der
> Anwendung nicht immer durchgeführt. Ich vermute, der Slave bekommt
> daher gar nicht mit wenn die temporäre Tabelle gelöscht werden soll.
> Kann das sein? Gibt es da Infos zu? Ich habe dazu direkt nichts
> gefunden.
>
> Christian

Nachtrag: Also ich hab mal rumrecherchiert. Mysql fügt automatisch das DROP
ein, selbst wenn der Client stirbt. Bei manuellen Tests funktioniert auch
alles fein. Wenn aber richtig "Aktion" los ist, bleiben eben
fehlerhafterweise auf dem Slave mal Temporärdateien übrig und die führen
dann zu den "Too many open files". Auf den Master greifen ca. 6-8 Clients
gleichzeitig zu und schicken jeweils einige GB an Daten auf den Master.
Dabei werden umfangreiche Queries u.a. sehr viel mit temporären Tabellen
durchgeführt. Soweit wird alles auch repliziert, aber eben die temporären
Tabellen werden auf dem Slave nicht immer gelöscht. Aber eben nur manchmal
und manuell nicht reproduzierbar.

Christian

Re: Replikation und temporärer Tabellen

Christian Schmelzer wrote:
> Christian Schmelzer wrote:
>> Hallo,
>> ich hab hier folgenden Aufbau: Master mit 4.1.21 und einen Slave mit
>> 5.0.41. Auf dem Master werden u.a. sehr viele temporäre Tabellen
>> angelegt. Diese werden auch auf den Slave repliziert. Auf dem Slave
>> werden sie scheinbar aber nicht mehr abgeräumt, jedenfalls bekomme
>> ich auf dem Slave sehr schnell einen Error 24 (Too many open files)
>> und im Temp Verzeichnis liegen ca. 1400 Dateien von Mysql rum.
>> Auf dem Master werden die temporären Tabellen schon beim Schließen
>> der Verbindung weggeräumt und ein explizites DROP wird scheinbar von
>> der Anwendung nicht immer durchgeführt. Ich vermute, der Slave
>> bekommt
>> daher gar nicht mit wenn die temporäre Tabelle gelöscht werden soll.
>> Kann das sein? Gibt es da Infos zu? Ich habe dazu direkt nichts
>> gefunden.
>>
>> Christian
>
> Nachtrag: Also ich hab mal rumrecherchiert. Mysql fügt automatisch
> das DROP ein, selbst wenn der Client stirbt. Bei manuellen Tests
> funktioniert auch alles fein. Wenn aber richtig "Aktion" los ist,
> bleiben eben fehlerhafterweise auf dem Slave mal Temporärdateien
> übrig und die führen dann zu den "Too many open files". Auf den
> Master greifen ca. 6-8 Clients gleichzeitig zu und schicken jeweils
> einige GB an Daten auf den Master. Dabei werden umfangreiche Queries
> u.a. sehr viel mit temporären Tabellen durchgeführt. Soweit wird
> alles auch repliziert, aber eben die temporären Tabellen werden auf
> dem Slave nicht immer gelöscht. Aber eben nur manchmal und manuell
> nicht reproduzierbar.
>
> Christian

So, um es noch abzuschließen, auch wenn es so viele Antworten gab :-) Aber
vielleicht hat ja mal jemand das gleiche Problem. Es ist scheinbar ein Bug
in der 4.1.x (jede Version). In der 5.0.41 ist es ok. Und zwar wird bei
abgeschaltetem Autocommit beim Disconnect ein Commit ausgeführt, aber ein
DROP TABLE wird dabei nicht in die Binlogs übernommen. Das war der Fehler.

Christian


Hier noch zum Nachspielen:

mysql> use test;
Database changed
mysql> set autocommit=0;
Query OK, 0 rows affected (0.00 sec)

mysql> create temporary table blub (test text);
Query OK, 0 rows affected (0.00 sec)

mysql> insert into blub values ('A');
Query OK, 1 row affected (0.00 sec)

mysql> drop table blub;
Query OK, 0 rows affected (0.00 sec)

mysql> insert into blub values ('B');
ERROR 1146 (42S02): Table 'test.blub' doesn't exist
mysql> exit
Bye


Man sieht, die Tabelle wurde gelöscht, d.h. DROP wurde ausgeführt.


Ergibt:
mysql> show binlog events\G
*************************** 1. row ***************************
Log_name: binlog.000001
Pos: 4
Event_type: Start
Server_id: 1
Orig_log_pos: 4
Info: Server ver: 4.1.13-standard-log, Binlog ver: 3
*************************** 2. row ***************************
Log_name: binlog.000001
Pos: 79
Event_type: Query
Server_id: 1
Orig_log_pos: 79
Info: use `test`; BEGIN
*************************** 3. row ***************************
Log_name: binlog.000001
Pos: 119
Event_type: Query
Server_id: 1
Orig_log_pos: 79
Info: use `test`; create temporary table blub (test text)
*************************** 4. row ***************************
Log_name: binlog.000001
Pos: 193
Event_type: Query
Server_id: 1
Orig_log_pos: 79
Info: use `test`; insert into blub values ('A')
*************************** 5. row ***************************
Log_name: binlog.000001
Pos: 257
Event_type: Query
Server_id: 1
Orig_log_pos: 257
Info: use `test`; COMMIT
5 rows in set (0.00 sec)


Wo ist das DROP TABLE im binlog???