To answer the original poster of this thread, it would help if you could
post more details about what happened such as error messages and mysqld
versions. My hunch is that the binlog got corrupted and the slave choked
on it. Did you try issuing 'SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1' (omit
GLOBAL if your mysqld version is <4.0)? If the latter didn't help, you
should be fine starting slaving again with 'CHANGE MASTER TO ...' and
specifying the binlog and position manually, which is what you may have
ended up doing. When the master daemon restarts (or crashes) the binlog
automatically gets rotated (IE a new binlog is started). The first
position in a new binlog is '4'.
As for the other posters in this thread with frequent replication
problems, I would be concerned if that's the case. I have found that it is
very rare for replication to break just by itself, most of the time it's a
misconfiguration or users sending updates directly to the slave. We have
replication setups that generate up to 4gigs of binlog data daily, and
none of them have ever broken just by themselves. It's always been a
misconfiguration, IE user error.
Hope this helps!
Flying Crocodile Inc, Unix Systems Administrator