If you have followed the instructions, and your replication setup is not working, first check the following:
Check the error log for messages. Many users have lost time by not doing this early enough.
Is the master logging to the binary log? Check with SHOW MASTER STATUS. If it is, Position will be non-zero. If not, verify that you have given the master log-bin option and have set server-id.
Is the slave running? Do SHOW SLAVE STATUS and check that the Slave_IO_Running and Slave_SQL_Running values are both Yes. If not, verify slave options
If the slave is running, did it establish a connection with the master? Do SHOW PROCESSLIST, find the I/O and SQL threads (see Replication Implementation Details to see how they display), and check their State column. If it says Connecting to master, verify the privileges for the replication user on the master, master hostname, your DNS setup, whether the master is actually running, whether it is reachable from the slave.
If the slave was running before but now has stopped, the reason usually is that some query that succeeded on the master failed on the slave. This should never happen if you have taken a proper snapshot of the master, and never modify the data on the slave outside of the slave thread. If it does, it is a bug; read below on how to report it.
If a query on that succeeded on the master refuses to run on the slave, and it does not feasible to do a full database resync (that is, to delete the slave's database and copy a new snapshot from the master), try the following:
First see if the slave's table was different from the master's. Understand how it happened (it may be a bug: read the Changelogs in the online MySQL manual as http://www.mysql.com/documentation to check if this is a known bug and if it is fixed yet). Then make the slave's table identical to the master's and run START SLAVE.
If the above does not work or does not apply, try to understand if it would be safe to make the update manually (if needed) and then ignore the next query from the master.
If you have decided you can skip the next query, issue the following statements:
mysql> SET GLOBAL SQL_SLAVE_SKIP_COUNTER = n; mysql> START SLAVE;
The value of n should be 1 if the query does not use AUTO_INCREMENT or LAST_INSERT_ID(). Otherwise, the value should be 2. The reason for using a value of 2 for queries that use AUTO_INCREMENT or LAST_INSERT_ID() is that they take two events in the binary log of the master.
Make sure you are not running into an old bug by upgrading to the most recent version.
If you are sure the slave started out perfectly in sync with the master, and no one has updated the tables involved outside of slave thread, report the bug.