If the esg user was already used for replication, you shouldn't need to grant privileges again. Login to the master server with he esg user, and execute show grants. This will confirm whether or not the esg user has REPLICATION SLAVE privilege.
If you don't already have it, get the root password set to something you know. That will be helpful for troubleshooting and setup/resync.
If you are unsure of the replication state, execute SHOW SLAVE STATUS and check the fields SLAVE_SQL_Running and SLAVE_IO_Running. If either of those are NO, then check the status for Error messages and #'s. If Replication is down, then that may be a cause of missing data.
If your SLAVE threads are running, check Seconds_Behind_Master. If that is not 0 (or something relatively close to 0), then your slave is behind, and that could be the missing data.
If the slave is up to date, and your missing some data, another possible cause is that another user with write privileges accidentally inserted/updated/deleted on the Slave instead of the master. Yes, this does happen.
Another possibility is data inconsistency from using Statement Based Replication, as opposed to Row Based Replication. Check show global variable like 'bingo_format' to determine if you're using statement or row based replication.
Beyond that, you might need to break your question down a bit more to understand what you're doing (rebuilding rep, vs restarting) and focusing in on one piece at a time.
Best Answer
mysqldumpreads the database, but does not write to it. It writes a text file you can look at.You will find that those options remove certain settings relating character set, engine, auto_increment, etc. These may make the generated SQL more compatible with some other database vendor or MySQL/MariaDB version.
The syntax I found was more like