>Description: I don't have an absolutely 100% complete description of the problem, but I guess it's easy to figure out what happened... Basically I came to the situation when the slave was down thusly: mysql> show slave status; +-------------------------+-------------+-------------+---------------+----- -------------+----------+---------------+-----------------+----------------- ----+------------+---------------------------------------------------------- ---------------------+--------------+ | Master_Host | Master_User | Master_Port | Connect_retry | Log_File | Pos | Slave_Running | Replicate_do_db | Replicate_ignore_db | Last_errno | Last_error | Skip_counter | +-------------------------+-------------+-------------+---------------+----- -------------+----------+---------------+-----------------+----------------- ----+------------+---------------------------------------------------------- ---------------------+--------------+ | coulds07.netbenefit.com | admin | 3306 | 60 | coulds07-bin.008 | 25262417 | No | | | 4294967295 | error 'unexpected success or fatal error' on query 'create database db2183-2' | 0 | +-------------------------+-------------+-------------+---------------+----- -------------+----------+---------------+-----------------+----------------- ----+------------+---------------------------------------------------------- ---------------------+--------------+ This database didn't exist at the filesystem level (ie. in /var/lib/mysql/ there was no "db2183-2" directory), didn't exist in MySQL (a "use db2183-2" didn't go for it). So I'm surmising that someone attempted to create an illegally named database on the master, and this failed command was incorrectly passed through to the slave, when it should have been trapped, and caused replication to stop. >How-To-Repeat: It's a production system. I really can't afford to try and replicate it, but I'm quite sure that doing a "create database [illegal db name]" on a master server would cause this to happen. I've looked through all the changelogs to see if this bug has been fixed yet, and it doesn't appear to have been. So I thought it was worth reporting it anyway. >Fix: On slave: SET SQL_SLAVE_SKIP_COUNTER=1; SLAVE START; Repeat as necessary depending on how many times moronic user on the master has tried to create the database which has a duff name. >Submitter-Id: <submitter ID> >Originator: root >Organization: Netbenefit Plc >MySQL support: none Synopsis: Replication failure brought on by attempts to create an illegally named database on >Severity: serious >Priority: high >Category: mysql >Class: sw-bug >Release: mysql-3.22.38 (Official MySQL RPM) >Environment: System: Linux version 2.2.13 ([EMAIL PROTECTED]) (gcc version egcs-2.91.60 19981201 (egcs-1.1.1 release)) #3 SMP Fri Jan 7 17:49:10 GMT 2000 Architecture: i686 Some paths: /usr/local/bin/perl /usr/bin/make /usr/bin/gmake /usr/bin/gcc /usr/bin/cc GCC: Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.7.2.3/specs gcc version 2.7.2.3 Compilation info: CC='egcs' CFLAGS='-O6 -fomit-frame-pointer -mpentium' CXX='egcs' CXXFLAGS='-O6 -fomit-frame-pointer -felide-constructors -fno-exceptions -fno-rtti -mpentium' LDFLAGS='' Configure command: ./configure --disable-shared --with-mysqld-ldflags=-all-static --with-client-ldflags=-all-static --enable-assembler --with-mysqld-user=mysql --with-unix-socket-path=/var/lib/mysql/mysql.sock --prefix=/ --exec-prefix=/usr --libexecdir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --localstatedir=/var/lib/mysql --infodir=/usr/info --includedir=/usr/include --mandir=/usr/man '--with-comment=Official MySQL RPM' Perl: This is perl, version 5.004_04 built for i386-linux --------------------------------------------------------------------- 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
