I think your simple topology where Master has 2 slaves is the best approach to have just one single-point of failure however due to our network topology slave1 is currently the only allowed server that can access our DMZ from inside our network. Master is in DMZ, Slave1 is inside our network, and Slave2 is in a separate DMZ for Disaster Recovery. Slave1 has access to both DMZs.

I realize if Slave1 becomes corrupted for any reason so will Slave2, but until I can have both slaves access our Master, this current setup seemed to be the only solution...
Thanks for your response!!!

 Slave1 <--- Master ---> Slave2

So, this instructions for adding a new slave (Slave2) to the replication will not fit your case of daisy chained slaves. You will have configure Slave1 to log to its own binary log any updates that are received from a master server. Here is MySQL documentation for --log-slave-updates option. Slave1 in your case must be both, a master and a slave at the same time.

Master ---> Slave1 ---> Slave2

I've read its more practical to have the slaves replicate directly to the master for single-point of failure. However our network topology requires this for our disaster recover solution.

So I already have Master to --> slave replication working, however to now replicate the slave1 to new slave2, would I simply follow these instructions and use master.info to reflect my slave1?

-Furosh

If anyone else should stumble across this page, here's what you need to do differently:

At step 1, after you have stopped the original slave and used the show slave status\G command, make a note of the Relay_Master_Log_File and Exec_Master_Log_Pos. Ignore step 3 and step 6. At step 9, issue the following commands:

reset slave;

change master to master_host='[master host]',master_user='[slave username]',master_password='[slave password]',master_log_file='[Relay_Master_Log_File]',master_log_pos=[Exec_Master_Log_Pos];

start slave;

If you can't remember your slave username or password, then it is on line 4 and 5 in the mysql-master.info file on the original slave.

"Error No. 1045 indicates that the user trying to connect to the master is not properly authenticated. Check if user has been given sufficient privileges at the master server."

Hope this short info will give the right direction to solve the problem.

"Slave_IO_State", "Master_Host", "Master_User", "Master_Port", "Connect_Retry", "Master_Log_File",
"Read_Master_Log_Pos", "Relay_Log_File", "Relay_Log_Pos", "Relay_Master_Log_File", "Slave_IO_Running", "Slave_SQL_Running", "Replicate_Do_DB", "Replicate_Ignore_DB", "Replicate_Do_Table", "Replicate_Ignore_Table", "Replicate_Wild_Do_Table", "Replicate_Wild_Ignore_Table", "Last_Errno", "Last_Error", "Skip_Counter", "Exec_Master_Log_Pos", "Relay_Log_Space", "Until_Condition", "Until_Log_File", "Until_Log_Pos", "Master_SSL_Allowed", "Master_SSL_CA_File", "Master_SSL_CA_Path", "Master_SSL_Cert", "Master_SSL_Cipher", "Master_SSL_Key", "Seconds_Behind_Master", "Master_SSL_Verify_Server_Cert",
"Last_IO_Errno", "Last_IO_Error", "Last_SQL_Errno", "Last_SQL_Error"

"Connecting to master", "192.168.0.226", "hyden", "3306", "60", "master-bin.000001",
"106", "C70-relay-bin.000001", "4", "master-bin.000001", "No", "Yes", "my_db", "", "", "", "", "", "0", "", "0", "106", "106", "None", "", "0", "No", "", "", "", "", "", NULL, "No",
"1045", "error connecting to master 'hyden@192.168.0.226:3306' - retry-time: 60 retries: 86400", "0", ""

regards

My process was the same but I did a CHANGE MASTER TO as well.

One thing I had to do after i did the GRANT REPLICATION ... line was to do a FLUSH PRIVILEGES on the master as well.