MySQLdump Exclude master-data

MySQLmysql-5.6mysqldumpreplication

Is it possible to exclude the master data from a mysql dump? From the manual it seems like the only options are commented out or present. I don't need the data at all because it is going to a static system. Commented out will work but just wondering if 0 or some other value would make it not present?

Use this option to dump a master replication server to produce a dump file that can be used to set up another server as a slave of the master. It causes the dump output to include a CHANGE MASTER TO statement that indicates the binary log coordinates (file name and position) of the dumped server. These are the master server coordinates from which the slave should start replicating after you load the dump file into the slave.

If the option value is 2, the CHANGE MASTER TO statement is written as an SQL comment, and thus is informative only; it has no effect when the dump file is reloaded. If the option value is 1, the statement is not written as a comment and takes effect when the dump file is reloaded. If no option value is specified, the default value is 1.

–https://dev.mysql.com/doc/refman/8.0/en/mysqldump.html#option_mysqldump_master-data

My plan was to use:

mysqldump --skip-lock-tables --single-transaction --flush-logs --hex-blob --master-data=0 ...

but from the above entry that would put the CHANGE MASTER TO as an uncommented command.

Best Answer

Use `grep -v` with `--master-data=2`

mysqldump --skip-lock-tables --single-transaction --flush-logs --hex-blob --master-data=2 | grep -v "^-- CHANGE MASTER TO" > dump.sql

GIVE IT A TRY !!!

Related Solutions

MySQL Master Port Disabled from Public IP – Log Not Refreshing

The basic problem stems from the Slave's IO Thread. Sometimes, it has the nasty habit of playing dumb and not properly checking or pinging the master.

MySQL 5.5's semisynchronous replication allows you to have the master time itself out and degrade back to asynchronous replication. Slaves running semisynchronous replication should have a more sensitive IO Thread now.

Concerning your particular situation, you are using MySQL 5.0.24 ??? That's a very old version. There are two bug reports (Bug1 and Bug2) discussing this.

It just dawned on me that you asked this question earlier and DTest answered it. Giving credit where credit is due, the bug reports came from his answer.

It would be nice to to be informed when the Public IP is being disabled from Slave access. That way, you could run STOP SLAVE; on the slave in advance.

You also asked is there a way to come to know the master status from the slave, when this type of behavior occurs.

Here is a typical SHOW SLAVE STATUS\G

mysql> show slave status\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 10.64.80.136
                  Master_User: replicant
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000019 <<------
          Read_Master_Log_Pos: 277892198 <<------
               Relay_Log_File: relay-bin.000058
                Relay_Log_Pos: 37535484
        Relay_Master_Log_File: mysql-bin.000019 <<------
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB:
          Replicate_Ignore_DB:
           Replicate_Do_Table:
       Replicate_Ignore_Table:
      Replicate_Wild_Do_Table:
  Replicate_Wild_Ignore_Table:
                   Last_Errno: 0
                   Last_Error:
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 277892198 <<------
              Relay_Log_Space: 277892637 <<------
              Until_Condition: None
               Until_Log_File:
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File:
           Master_SSL_CA_Path:
              Master_SSL_Cert:
            Master_SSL_Cipher:
               Master_SSL_Key:
        Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error:
               Last_SQL_Errno: 0
               Last_SQL_Error:
1 row in set (0.00 sec)

Please note the following:

Master_Log_File : Log file from Master whose latest SQL was last copied to relay logs
Read_Master_Log_Pos : Log position within Master_Log_File whose latest SQL was last copied to relay logs
Relay_Master_Log_File : Log file from Master whose SQL was last executed from the relay logs
Exec_Master_Log_Pos : Log position within Relay_Master_Log_File whose SQL was last executed from the relay logs

If none of these value are moving, that could mean the all SQL is processed or that the slave is currently processing an SQL statement in the SQL thread that came from position Exec_Master_Log_Pos of the Master Log Relay_Master_Log_File.

Now, look at Relay_Log_Space. This number represents the sum total of all filesizes for all relay logs. If Slave_IO_Running is Yes and Relay_Log_Space is not changing, then go check the master by running SHOW MASTER STATUS;. It should like something like this:

mysql> show master status;
+------------------+-----------+--------------+------------------+
| File             | Position  | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+-----------+--------------+------------------+
| mysql-bin.000019 | 682563021 |              |                  |
+------------------+-----------+--------------+------------------+
1 row in set (0.00 sec)

If the Master's (File,Position) of SHOW MASTER STATUS; is beyond the Slave's (Master_Log_File,Read_Master_Log_Pos) of SHOW SLAVE STATUS\G, then the IO Thread on the Slave is dead for intents and purposes, even if Slave_IO_Running is Yes.

Mysql – Update MySQL slave when changing the hostname/IP of master

Once you change the MASTER_HOST, everything else needs to change with it.

The "dark back-alley" approach you just suggested is exactly what to do.

Warning: Some systems use "mysqld" versus "mysql". 
The --skip-slave-restart "option" may not available without editing your
/etc/init.d/mysqld script to include this as a new option. 
If used, it will still start the slave upon startup.</p>

On the Slave, run these four lines:

cd /var/lib/mysql  
service mysql stop  
cp master.info master.info.bak
wc -l < master.info

The last line echoes the number of lines in master.info

Next, vi master.info and change the IP address.

Next, run wc -l < master.info and make sure the linecount is still the same

Next, start mysql without starting replication

service mysql start --skip-slave-start

SHOW SLAVE STATUS\G

If the IP address you added appears, then run

START SLAVE; SELECT SLEEP(5);
SHOW SLAVE STATUS\G

If you see Slave_IO_Running : Yes and Slave_SQL_Running : Yes, Congratulations !!!

Give it a Try !!!