The row counts do not match.
I can export the data and import it into a new table inside the same database, and the result still has a different number of rows. The backup and production tables have different indexes, but that should not change the data. The servers are in different time zones, but the date ranges come from values inside the database, not the server clock.
I have exported and imported it several ways. Same problem.
This is consulting work I am doing beside Peek. The project includes statistics data, a database cleanup, request-log search, and tests around Amazon's EC2 load balancer. The load-balancer work is interesting. The missing rows are the thing blocking the next step.
I got sick enough to spend Tuesday night and much of Wednesday at the hospital with intense nausea and a high fever. I lost most of the week. I tried to keep working in pieces, which meant checking queries between fever naps, rerunning imports, and sending an update from my phone about what was ready and what was not.
I told the client to count the week as sick and not pay me for it. I would still deliver the outstanding items, and we could pick the load-balancer discussion back up when I was functioning.
I still planned to deliver the outstanding items after I recovered.
I had been using an AWS test environment to compare the EC2 load balancer with running our own load-balancing instance. The question was whether the managed service had improved enough to use in QA and how its throughput compared with a machine we controlled. At the same time, I was normalizing the statistics database and trying to understand why the source and backup disagreed.
Before the week went sideways, I had split the export into six two-week batches and planned to compare them one by one. The dump commands looked right. Rerunning the same files on my local machine did not reproduce the remote problem. I considered whether an interrupted SSH session had damaged an import, but that was still a hypothesis, not an answer.
Then I was sent to London for a quick data-center visit. I am back in the United States now after some weather delay, working on Mountain Time for the rest of this week and trying to close the gap from several directions.
The travel does not explain the row count. The illness does not explain it either. They explain why the investigation is taking longer and why my notes are arriving from three time zones, but the database still has to produce the same number on both sides.
The next useful test is SELECT ... INTO OUTFILE, if I can get an account with permission to run it. That removes another part of the export and import path and gives me a cleaner comparison. If the count still changes, the problem is closer to the data or query. If it holds, one of the tools in the current path is changing the result.
I need to list what I tried, which explanations are less likely, what access I need, and when I can report back. A general update that the database is behaving strangely will not help the client decide what to do next.
I should have sent a clearer status earlier instead of letting the client ask where the deliverables were. I was sick, but I still missed the communication. I have now explained the state, offered the billing adjustment, and returned to the data.
Right now the two tables disagree. The indexes look different. Time zones do not appear relevant. Reimporting locally has produced a different result than the remote path. I need the outfile permission and another clean run.
I will call tomorrow at noon Eastern from Mountain Time. Before then I will ask for the outfile permission and run the clean comparison if access is available. If the row counts still differ, I will bring the exact results and the next diagnostic step to the call.