MySQL Bugs: #64255: Add Last_Error_Datetime to show slave status

Bug #64255	Add Last_Error_Datetime to show slave status
Submitted:	7 Feb 2012 22:49	Modified:	21 Oct 2013 9:18
Reporter:	Richard Lynch	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: Replication	Severity:	S4 (Feature request)
Version:		OS:	Any
Assigned to:		CPU Architecture:	Any

Description:
As I look at a failed "show slave status" (again), I'm often wondering:

Exactly WHEN did this thing error out?

I can do date math and work it out from now() and seconds behind master, once I restart it, and get a rough idea when I have a number instead of NULL, but that could be pretty far off the mark given how fast replication rips through the relay log.

Or I could queue up two queries in a row to start slave; show slave status \G and then do the data math, but that's still going to be "off" a bit.

I think it would be Really Nifty (tm) to have a Last_Error_Datetime corresponding to the Last_Error.

Or even TWO datetime stamps, one in MASTER time, and one in SLAVE, since they could potentially differ quite a bit in some use cases.

How to repeat:
Errrr.  Do an INSERT on a slave and watch it crash and burn.

Thank you for the feature request.

Please, check http://dev.mysql.com/doc/refman/5.6/en/show-slave-status.html. Do you really need anything else in addition to Last_IO_Error_Timestamp and Last_SQL_Error_Timestamp columns added in 5.6.3?

I've changed this to Docs/Verified and assigned to myself for handling the docs part of the issue, will return bug to previous state after I'm done.

Thank you for your bug report. This issue has been addressed in the documentation. The updated documentation will appear on our website shortly, and will be included in the next release of the relevant products.

Set category/status/assignee back to Server:Replication/Need Feedback/[none] after fixing docs issue.

Sorry I missed the feature additions!

The MASTER timestamp at the time of the error would be useful information, I should think...

It might make a difference to one's forensics if the slave was DAYS behind the master when it failed, versus << 30 seconds.

Yes, your monitoring should have caught that...

This issue was fixed in 5.6.1 by the fix for BUG#43525. Closed.