It is now since 14 hours that mysql3 is cutting out every 2 monutes for between 1 and 10 minutes and so far all we get as answers is - We are monitoring!
May I suggest that maybe something more drastically is done instead of “monitoring”? I can monitor something going down and back up and back down myself, for that I do not need “365x24x7” support.
What really annoys me is that when I get after 12 hours of that happening the second time on live chat (and 10 hours after I post a support ticket) all I get is:
" We have just noticed the problem and our manager is actually even working from home on it, but it is holiday here in India, so I do not know what we can do"
Point 1) That is a blatant lie, as I put in a support ticket 10 hours before as well as informed support of the issues already 10 hours before that via live chat and Jodohost’s own Jodopulse records and shows the downtimes for the last 10 hours constantly on their own website
Point 2) I have no problem if a second level issue is shifted down in priority because of a holiday in India, however when a server goes down and clients are involved with unavailable websites (just with my Reseller account over 20 website of my clients are down), than I would consider this an emergency, expecially if that is going on now since over 14 hours.
Point 3) We as resellers hang in the air with nothing to tell our clients and nothing we can do, so it may be a nice idea to update this forum under Network Outages for the sake of the people who actually make Jodohost the money.
Ok, yes I am mad, but it still is not way to handle it’s partners!
Please let me know point me to the ticket# where this was said. I’ll sure talk to this tech. They were all indeed aware of the temp fix to be applied.
Tickets were indeed processed much slower because we were only on minimal staff (as already mentioned in our holiday announcement email and post).
This caused a major delay in identification and escalation of the issue.
People on chat are not techs mostly and their escalations to techs are queued. This added to the delay due to less available tech headcount.
The issue was intermittent and the DB causing this was accessing it only for a second. Our automated per minutes check failed to locate it because it happened to access between the checks. Even if it collided with the check, the queries from this user in execution didn’t look harmful. Even when we identified, it doesn’t looks possible from the first look how this query can crash the whole DB server.
You are right. It should be and will be taken care of in future. I was too certainly not happy when made aware that no post was made for the incident.
What I than not understand is, why I could monitor the whole problems on Jodopulse with DOWNTIME 7M etc… written clearly on it?? So it definitely was more than in between 1 minute checks… longest I monitored was 13 minutes, while the shortest was maybe 1.5 minutes, but I certainly could monitor all the outages all the time on Jodopulse.
Couldn’t find exact same words (as in your original post) in this ticket that I did find inappropriate. Still I apologize for the incident.
We are talking about different things. Downtime is not equal to the bad query in progress. Again, as I already mentioned, the checks are per minute, but the bad query( with this DB in bad state) was running for just a second or less, causing the DB server to crash and there are 60 such seconds per minute. One can’t easily monitor queries being executed per second if the connection is being immediately closed.
If you look at my original post, the wording were in the LIVE CHAT, and I would be happy to forward you the Chat Scripts from Manish if you need them, as I saved them!
On the other hand, I think I made my point clear and hope we get something good out of it with actions being taken the next time…
I’ll indeed talk to him on this. You are quite clear on your points and they are noted. I’m just attempting to clarify our stand without any intention to deny the incident.
It was first such incident for us and we hope to be much faster in resolving them if it repeats.