Hallo, ich habe eine Problem mit einem MySQL Slave
welcher einfach mal mitten drin aufhört sich mit dem Master zu syncen.
Angaben zum Master: http://nopaste.php-q.net/310576
Angaben zum Slave: http://nopaste.php-q.net/310577
kennt einer das Problem? Bzw gibt es eine Möglichkeit ihm dazu zu
bewegen, das er sich bis an die aktuelle Stelle des Masterlogs vorarbeitet?
MFG Heiko
Hier noch was was mir aufgefallen ist:
mysql> show processlist\g
+-------+-------------+-----------+-------------+---------+- -----+------------------------------------------------------ -----------------+------------------------------------------ ---------+
| Id | User | Host | db | Command | Time | State
| Info
|
+-------+-------------+-----------+-------------+---------+- -----+------------------------------------------------------ -----------------+------------------------------------------ ---------+
| 31881 | system user | | NULL | Connect | 1486 | Has
read all relay log; waiting for the slave I/O thread to update it | NULL
|
| 31904 | root | localhost | usr_web34_2 | Query | 80 |
Waiting for the slave SQL thread to advance position |
SELECT MASTER_POS_WAIT('mysql-bin.093', '134681') |
| 31905 | root | localhost | NULL | Query | 0 | NULL
| show
processlist |
+-------+-------------+-----------+-------------+---------+- -----+------------------------------------------------------ -----------------+------------------------------------------ ---------+
3 rows in set (0.00 sec)
Beim versuch ein Syncen mittels MASTER_POS_WAIT zu erzielen passiert
erstmal nichts und in der PROCESSLIST findet man folgendes.
Wiso das Syncen mittels MASTER_POS_WAIT nicht geht weiss ich jetzt.
Der LogRotate Daemon von Debian hat schon die Bin logs zwischen drin
gelöscht (behält nur die 7 neusten).
bleibt nur noch die Frage, wieso es nicht aktuell bleibt.
MFG Heiko
"Heiko (GreenRover) Henning"
> Hallo, ich habe eine Problem mit einem MySQL Slave
> welcher einfach mal mitten drin aufhört sich mit dem Master zu syncen.
>
> Angaben zum Master: http://nopaste.php-q.net/310576
> Angaben zum Slave: http://nopaste.php-q.net/310577
Kann dein Newsreader kein Copy&Paste? Warum kopierst du das nicht
einfach hier rein?
Mach ich halt selber Copy&Paste:
> Slave_IO_Running: No
Der Replikations-Thread der das Binlog vom Master auf den Slave
kopiert, läuft nicht. Ein Grund sollte als Fehlermeldung im MySQL-
Errorlog stehen.
Re: <46927332$0$31635$9b4e6d93@newsspool3.arcor-online.net>
> Der LogRotate Daemon von Debian hat schon die Bin logs zwischen drin
> gelöscht (behält nur die 7 neusten).
Es ist eine total bescheuerte Idee, die MySQL-Binlogs unter die
Kontrolle des normalen Log-Rotators zu stellen. Ich bin mir ziemlich
sicher, daß Debian-Pakete das nicht von Haus aus vorsehen.
Aber wenn der Master-Server sein Binlog nicht mehr findet (weil ihm
das jemand umbenannt hat) dann sagt er das dem I/O-Thread des Slaves
und der bleibt dann stehen. Und der SQL-Thread läuft noch bis zum
Ende des Relay-Logs und bleibt ebenfalls stehen. Was sollen die sonst
auch machen?
> bleibt nur noch die Frage, wieso es nicht aktuell bleibt.
K.A. was du damit sagen willst.
XL
* Heiko (GreenRover) Henning schrieb:
> Der LogRotate Daemon von Debian hat schon die Bin logs zwischen drin
> gelöscht (behält nur die 7 neusten).
Logrotate in Debian fasst die Binary-Logs von MySQL in der Default-
Konfiguration nicht an.
Norbert
Axel Schwenke schrieb:
Danke erstmal für deine Hilfe versuche.
> Kann dein Newsreader kein Copy&Paste? Warum kopierst du das nicht
> einfach hier rein?
Doch, ich finde es bei solch großen Dingen bloß übersichtlicher, wenn es
extern ist.
>
>> Slave_IO_Running: No
>
> Der Replikations-Thread der das Binlog vom Master auf den Slave
> kopiert, läuft nicht. Ein Grund sollte als Fehlermeldung im MySQL-
> Errorlog stehen.
Das Error Log ist aber auf dem Slave so wie auf dem Master leer.
>
> Re: <46927332$0$31635$9b4e6d93@newsspool3.arcor-online.net>
>> Der LogRotate Daemon von Debian hat schon die Bin logs zwischen drin
>> gelöscht (behält nur die 7 neusten).
>
> Es ist eine total bescheuerte Idee, die MySQL-Binlogs unter die
> Kontrolle des normalen Log-Rotators zu stellen. Ich bin mir ziemlich
> sicher, daß Debian-Pakete das nicht von Haus aus vorsehen.
movetecx:~# cat /etc/mysql/debian-log-rotate.conf
# This is the config file for
# /etc/logrotate.d/mysql-server (for normal logs)
# /etc/cron.daily/mysql-server (for binary logs)
# It should be kept in shell script syntax and contain only variables.
#
# Both log file types are rotated daily, whenever "FLUSH LOGS;" is
# issued and when the server (re)starts so do not choose too low numbers.
# Configuring /etc/logrotate.d/mysql-server does not yet work.
# The number of binary log files that are kept. They are rotated daily
# and on "FLUSH LOGS;". A value of 0 disables rotating and is set as default
# for backward compatibility.
KEEP_BINARY_LOGS=50
movetecx:~# cat /etc/cron.daily/mysql-server
#!/bin/bash
#
# This script only rotates the binary logs. The normal logs are rotated
# via /etc/logrotate.d/mysql-server.
#
# The number of binary logs that should be kept can be configured in
# /etc/mysql/debian-log-rotate.conf
#
set -e
set -u
############################################################ ###############
M="/usr/bin/mysql --defaults-file=/etc/mysql/debian.cnf"
MA="/usr/bin/mysqladmin --defaults-file=/etc/mysql/debian.cnf"
tmp=`tempfile`;
my_exit () {
rm $tmp
exit $1
}
test -x /usr/bin/mysqladmin || exit 0
# Read config and see if we should rotate at all.
.. /etc/mysql/debian-log-rotate.conf
if [ "$KEEP_BINARY_LOGS" -eq 0 ]; then
my_exit 0
fi
# Test if the server is up and running.
if ! $MA --silent ping >/dev/null; then
my_exit 0
fi
# Retrieving list of file names. Can fail if no binary logs are in use.
if ! echo 'SHOW MASTER LOGS;' | $M --skip-column-names >$tmp 2>&1; then
if grep -q 'You are not using binary logging' $tmp; then
my_exit 0
else
echo "Unknown problem retrieving MySQL master log filenames in $0."
cat $tmp
my_exit 1
fi
fi
# Test if we have enough log files to rotate and do so if.
if [ `wc -l < $tmp` -gt $KEEP_BINARY_LOGS ]; then
filename=`tail -n $KEEP_BINARY_LOGS $tmp | head -n 1`
echo "PURGE MASTER LOGS TO '$filename';" | $M
fi
my_exit 0
KEEP_BINARY_LOGS habe ich mal von 7 auf 50 erhöht.
Und das ist definitiv ein Debian Standartscript.
Und es macht ja an sich auch Sinn, sich nicht mit den binlogs total zu
zu müllen.
Wenn man jetzt mal von der Standart conf ausgeht, werden die binlogs
eine Woche behalten. Das dürfte doch wohl für den Slave zu schaffen zu
sein, sich in der Zeit zu synchronisieren. (kompletter sync der gesamten
DB hat 6min gedauert)
Deshalb vermute ich irgend ein anderes Problem, weshalb er aufhört zu
syncen. Jedoch ist das error log leer.
Und das Problem besteht bei 2 Server paaren.
Paar 1: master=deiban sarge mysql4 slave=debian etch mysql 5
Paar 2: master=debian etch mysql 5 slave=debian etch mysql 5
MFG Heiko
Heiko (GreenRover) Henning schrieb:
> KEEP_BINARY_LOGS habe ich mal von 7 auf 50 erhöht. Und das ist definitiv
> ein Debian Standartscript.
Das ist es in der Tat, zumindest unter Debian 3.1, mit Logrotate hat das
ganze aber nichts zu tun.
Norbert
"Heiko (GreenRover) Henning"
> Axel Schwenke schrieb:
>
>> Kann dein Newsreader kein Copy&Paste? Warum kopierst du das nicht
>> einfach hier rein?
> Doch, ich finde es bei solch großen Dingen bloß übersichtlicher, wenn es
> extern ist.
Mit dieser Ansicht stehst du wohl ziemlich allein da.
>>> Slave_IO_Running: No
>>
>> Der Replikations-Thread der das Binlog vom Master auf den Slave
>> kopiert, läuft nicht. Ein Grund sollte als Fehlermeldung im MySQL-
>> Errorlog stehen.
> Das Error Log ist aber auf dem Slave so wie auf dem Master leer.
Unter Debian schreibt MySQL das Errorlog ins Syslog. Letztlich landen
so alle Meldungen in /var/log/daemon.log.
>> Re: <46927332$0$31635$9b4e6d93@newsspool3.arcor-online.net>
>>> Der LogRotate Daemon von Debian hat schon die Bin logs zwischen drin
>>> gelöscht (behält nur die 7 neusten).
>>
>> Es ist eine total bescheuerte Idee, die MySQL-Binlogs unter die
>> Kontrolle des normalen Log-Rotators zu stellen. Ich bin mir ziemlich
>> sicher, daß Debian-Pakete das nicht von Haus aus vorsehen.
>
> movetecx:~# cat /etc/mysql/debian-log-rotate.conf
> # This is the config file for
> # /etc/logrotate.d/mysql-server (for normal logs)
> # /etc/cron.daily/mysql-server (for binary logs)
> # The number of binary log files that are kept. They are rotated daily
> # and on "FLUSH LOGS;". A value of 0 disables rotating and is set as default
> # for backward compatibility.
> KEEP_BINARY_LOGS=50
Na also. Der Default ist, die binary logs nicht rotieren zu lassen.
> movetecx:~# cat /etc/cron.daily/mysql-server
> # Test if we have enough log files to rotate and do so if.
> if [ `wc -l < $tmp` -gt $KEEP_BINARY_LOGS ]; then
> filename=`tail -n $KEEP_BINARY_LOGS $tmp | head -n 1`
> echo "PURGE MASTER LOGS TO '$filename';" | $M
> fi
Das sieht jetzt erst mal nicht so dumm aus, weil die Binlogs eben nicht
rotiert, sondern per PURGE MASTER LOGS (vom Server) weggeräumt werden.
Korrekterweise müßte man allerdings erst mal checken, an welchem Log
der Slave gerade arbeitet und würde erst dann entscheiden, welche
Binlogs man den Server löschen läßt. Alternativ könnte man auch PURGE
MASTER LOGS BEFORE ... verwenden und eine bestimmte *Zeitdauer* an
Binlogs vorhalten.
Schließlich gibt es noch eine Abhängigkeit zu Backups. Man kann Binlogs
auch prima für point-in-time recovery verwenden. Dazu würde man das
Binlog direkt beim Backup flushen und mit in das Backup packen.
> KEEP_BINARY_LOGS habe ich mal von 7 auf 50 erhöht.
Laut Kommentar sollte da 0 stehen, nicht 7.
> Und es macht ja an sich auch Sinn, sich nicht mit den binlogs total zu
> zu müllen.
Man sollte es halt nur intelligent machen. Wenn man die Binlogs nur für
die Replikation braucht, kann man das etwa so machen wie ich es hier:
http://forge.mysql.com/snippets/view.php?id=10
mal durchexerziert habe.
> Wenn man jetzt mal von der Standart conf ausgeht, werden die binlogs
> eine Woche behalten. Das dürfte doch wohl für den Slave zu schaffen zu
> sein, sich in der Zeit zu synchronisieren.
Vorausgesetzt, niemand macht FLUSH LOGS. Oder max_binlog_size wird
nicht erreicht. Oder oder oder.
XL
Axel Schwenke schrieb:
> "Heiko (GreenRover) Henning"
>> Das Error Log ist aber auf dem Slave so wie auf dem Master leer.
>
> Unter Debian schreibt MySQL das Errorlog ins Syslog. Letztlich landen so
> alle Meldungen in /var/log/daemon.log.
Seit 5.1.20 gilt das auch für ungepatchte Versionen von MySQL.
http://dev.mysql.com/doc/refman/5.1/en/news-5-1-20.html
Norbert