Master not creating new binary log in MySql

Question

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.

Answer 1

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. I don't think anything relevant has changed during 4.0 thru 5.6.

Comments

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 =
 - 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)