Scenario:
Linux-2.2.18/glibc-2.2/mysql-3.23.30-gamma
Setup:
2 Servers, 10.1.2.3 and 10.1.2.4, actual clients are routed to only one of the
systems. This setup allows for automated failover.
from my.cnf of 10.1.2.3
log-bin
server-id = 3
master-host = 10.1.2.4
master-port = 330
master-user = replicate
master-password = <obfuscated>
from my.cnf of 10.1.2.4
log-bin
server-id = 4
master-host = 10.1.2.3
master-port = 330
master-user = replicate
master-password = <obfuscated>
On 10.1.2.4 as user with grant privilege do the following:
grant usage on *.* to ast@'%' identified by 'geheim1';
Everything is ok, ast now may connect to either 10.1.2.3 or 10.1.2.4.
On 10.1.2.4 then do the following:
mysql -uast -pgeheim1
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 341 to server version: 3.23.30-gamma-log
Type 'help;' or '\h' for help. Type '\c' to clear the buffer
mysql> set password=password('123');
Query OK, 0 rows affected (0.00 sec)
mysql> \q
Bye
mysqld on 10.1.2.3 does crash immediately. When trying to restart the daemon
the following happens:
env MYSQL_UNIX_PORT=/var/mysql/socket MYSQL_TCP_PORT=330 \
> /usr/local/mysql/libexec/mysqld \
> --basedir=/usr/local/mysql --datadir=/var/lib/mysql \
> --pid-file=/var/mysql/mysqld.pid --enable-locking \
> --log-slow-queries --log=/dev/null --skip-show-database \
> --skip-name-resolve --user=mysql
/usr/local/mysql/libexec/mysqld: ready for connections
010117 12:33:15 Slave: connected to master '[EMAIL PROTECTED]:330', replicati
on started in log 'pollux-bin.002' at position 3085
mysqld got signal 11;
The manual section 'Debugging a MySQL server' tells you how to use a
stack trace and/or the core file to produce a readable backtrace that may
help in finding out why mysqld died
Attemping backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong
frame pointer (ebp) is NULL, did you compile with
-fomit-frame-pointer? Aborting backtrace
Well, yes, I did compile optimized :-(
CFLAGS=-O3 -fomit-frame-pointer -funroll-loops -fexpensive-optimizations
-fschedule-insns2 -mwide-multiply -march=pentiumpro -mcpu=pentiumpro
-malign-loops=2 -malign-jumps=2 -malign-functions=4
CXXFLAGS=-O3 -fomit-frame-pointer -funroll-loops -fexpensive-optimizations
-fschedule-insns2 -mwide-multiply -march=pentiumpro -mcpu=pentiumpro
-malign-loops=2 -malign-jumps=2 -malign-functions=4
The only way to clear the problem seems to remove all binlogs+binlog
index+master.info and start over again.
This is a severe problem as any authenticated user may use 'set password' to
change his or her password. Note: modifying the mysql.user table on one system
and then doing a 'flush privileges;' on both systems (the flush command is not
replicated) works fine.
The general setup of the two servers involved is for automatic failover in case
of a system crash (proven working the hard way...). Thus a one way replication
scheme is not useable in this case.
Andreas Steinmetz
D.O.M. Datenverarbeitung GmbH
---------------------------------------------------------------------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
