issue on the slave: SHOW SLAVE STATUS\G and post here
most likely after you reset the master your slave can't synch anymore, because its missing next sequence of replication file. why don't you backup your master with mysqldump and re-issue it ont he new setup (i.e. on MySQL 5.5 instance)? 2013/7/4 Machiel Richards - Gmail <machiel.richa...@gmail.com> > Hi, > > in short what we did was the following: > > - binary logs was written to a 20GB filesystem and due to company > policies we kept expire logs at 7 days. > - system got quite busy over the years so the space was becoming a > problem and thus we had to move to another directory. > - setting that was changed is : log_bin = <new directory> > - old binary logs were moved to the new directory after shutting down > the database > - database started up and continued as normal, however stopped at the > last binary log when it filled up and complained about a corrupted binary > log. > - a flush logs and reset master was done and a new binary log was > created mysql-bin.1 > - however same thing happening here, the binlog file fills up to 100Mb > as configured, then stops without creating a new binary log. > - this is then the point where the replication crashes as well. > > > Output of the queries: > > > mysql> SHOW VARIABLES LIKE '%bin%'; > +-----------------------------**----+----------------------+ > | Variable_name | Value | > +-----------------------------**----+----------------------+ > | binlog_cache_size | 1048576 | > | innodb_locks_unsafe_for_binlog | OFF | > | log_bin | ON | > | log_bin_trust_function_**creators | OFF | > | max_binlog_cache_size | 18446744073709547520 | > | max_binlog_size | 104857600 | > | sync_binlog | 0 | > +-----------------------------**----+----------------------+ > > > mysql> SHOW VARIABLES LIKE '%dir%'; > +----------------------------+**----------------------------+ > | Variable_name | Value | > +----------------------------+**----------------------------+ > | basedir | /usr/ | > | character_sets_dir | /usr/share/mysql/charsets/ | > | datadir | /var/lib/mysql/ | > | innodb_data_home_dir | | > | innodb_log_arch_dir | | > | innodb_log_group_home_dir | ./ | > | innodb_max_dirty_pages_pct | 90 | > | plugin_dir | | > | slave_load_tmpdir | /var/lib/mysql/tmp/ | > | tmpdir | /var/lib/mysql/tmp | > +----------------------------+**----------------------------+ > 10 rows in set (0.00 sec) > > > > > > > Regards > > > > On 07/03/2013 08:29 PM, Rick James wrote: > >> What setting(s) did you change to move to the separate partition? >> SHOW VARIABLES LIKE '%bin%'; >> SHOW VARIABLES LIKE '%dir%'; >> (there may be other VARIABLES worth checking) >> What steps did you take for the move? (Actually move bin.1? Start over? >> etc?) >> >> Consider using expire_logs_days. >> >> 5.0 -- I don't think anything relevant has changed during 4.0 thru 5.6. >> >> -----Original Message----- >>> From: Machiel Richards - Gmail >>> [mailto:machiel.richards@**gmail.com<machiel.richa...@gmail.com> >>> ] >>> Sent: Wednesday, July 03, 2013 3:20 AM >>> To: mysql list >>> Subject: Master not creating new binary log. >>> >>> Hi all >>> >>> I hope all are well. >>> >>> I would like some assistance with something really strange. >>> >>> We currently have a problem with a master slave setup running >>> mysql >>> 5.0. >>> >>> This is one of our legacy servers which are in the planning to >>> be >>> upgraded, however in order for this to be done the replication needs to >>> be >>> up and running. >>> >>> The problem we have currently however is that the binary logs on >>> the master was moved to a seperate partition due to disc space >>> restrictions. >>> >>> A new binlog file called mysql-bin.1 was created and everything >>> seemed to work fine. >>> >>> However, the moment the file reached the file size of 100Mb, it >>> does not go on to create a new binlog file called mysql-bin.2 and the >>> replication fails stating that it is unable to read the binary log file. >>> >>> Thus far we have done a flush logs and reset master , but the >>> same problem occurs, where it creates mysql-bin.1 and the moment it >>> reaches it's max size and suppose to create a new file, it stops and does >>> not create the new one. >>> >>> I really hope this makes sense, and that someone can perhaps >>> point us in the correct direction. >>> >>> Any help would be appreciated. >>> >>> Regards >>> >>> >>> >>> >>> >>> -- >>> MySQL General Mailing List >>> For list archives: http://lists.mysql.com/mysql >>> To unsubscribe: http://lists.mysql.com/mysql >>> >> >> > > -- > MySQL General Mailing List > For list archives: http://lists.mysql.com/mysql > To unsubscribe: http://lists.mysql.com/mysql > >
