Using an older MySQL binlog filename (with position zero)? Risks? Downsides?
I have a surprise for you

Every position within a binary log is based on the filesize of the binary log as of the moment an SQL statement was written.

What is even more interesting about this concept is the fact that header for binary logs differ in start position (There is no such thing as a literal position 0)

These are the starting points for replication from a Master's empty binary log


107 for MySQL 5.5
106 for MySQL 5.1
98 for MySQL 5.0 and back


I first wrote about this back on Feb 4, 2011

Here is a suggested course of action


If the relay logs still exists on the Slave


find the last relay log
run mysqlbinlog against that relay log
locate the timestamp of the moment you performed the mysqldump
Take that timestamp and locate the same timestamp in the master's binary logs\
Near the master's copy of the timestamp in the appropriate  should be the position
Whatever master binary log you selected, use that binary log in the CHANGE MASTER TO command on the Slave
Whatever position you found in the master binary log you selected, use that position in the CHANGE MASTER TO command on the Slave



That's the best way to minimize any data collision due to duplcaiet keys

Just to be sure, on the Slave add this to my.cnf

[mysqld]
slave-skip-errors=1062


Then restart mysql. This will bypass all duplicate key collisions after running START SLAVE;. When Seconds_Behind_Master reaches 0, remove that line and restart mysql on the Slave. Everything in terms of MySQL Replication should be fine from there.