Thanks, brablc, I really appreciate your input. For future generations, here’s what we did that worked for a 5.0 master with 5.6 slaves on RHEL / Centos stuck on old_passwords and secure_auth off:
set the slave in my.cnf: old_passwords = 0 and skip_secure_auth . service mysqld restart it just to make sure that the changes have taken effect.
For what it’s worth, setting innodb_flush_log_at_trx_commit=0 on the slave for import can speed it up from a 3 day import to 6 hours. (120GB dump file on a 16 core 6-disk machine with 192GB RAM). Disabling binlog can make it faster, as well, by greatly reducing needless disk writes as you import. Make sure to set trx_commit back to 1 or 2 after you are done importing.
On the master, we retain the old_passwords = 1 and secure_auth=OFF settings as needed for the legacy setup. Legacy blows; upgrading both the master version and passwords is definitely worthwhile if you can. But if you cannot for whatever reason, read on.
Import your full dump to the slave. You won’t be able to import the mysql tables, including user, without doing the upgrade process, but adding a few new users again to the cleanly installed 5.6 slave isn’t a big deal. Enable binlogs and change the trx_commit setting back as mentioned above. Restart the slave mysql process.
Do your usual SET MASTER to MASTER_PASSWORD=‘yourpassword’ … settings on the slave. Make sure to set the password as it will store the password on the slave to the new password format locally on the slave.
On the master, run set old_passwords=0; GRANT REPLICATION SLAVE,REPLICATION CLIENT ON . TO ‘your5.6replicationuser’@‘yourIPrange’ IDENTIFIED BY ‘yourreplicationuserpassword’;
On the slave, start slave and then show slave status. It should be connected and working perfectly (the time behind the master should be counting down as it catches up) assuming your firewalls are set up properly and your dump import was done correctly.
On the master, run set old_passwords=1; You should be all done. Good luck.