A MySQL host in a slave configuration is in the testing phase before being put into production as a primary server for a specific workload. To make an estimate about how it is going to perform, the idea was born to simply use the current productive master's queries and replay them on the slave. The imminent issues that arise are the following:
- the slave already is replaying the master's binlogs, so only SELECT statements should be considered for execution
- it needs to happen multi-threaded and in near-realtime (or at least in the same pacing as at the master) to get meaningful figures out of the whole process
Although I know about the general log, I do not see an easy way to meet both requirements. The first would require a more-or-less sophisticated parser to prevent execution of edgy things changing data like a SELECT [...] INTO. As for the second, I know about Percona Playback which is capable of parallel execution and query-pacing, but it only would take the slow query log format (at least for the pacing feature), which is even harder to parse. It also won't process in real time (e.g. the mysql-slow log piped from cat or nc).
As this does not sound too far-fetched as a requirement, I wonder how the other DBAs are managing this.
This option ensures that each query takes at least Query_time (from slow query log) to execute, which, I assume, means that it won't be able to make use oftcpdumpcaps. Also, pcap data is even more difficult to pre-process than the slow query log.