Your only hope in this scenario is to have the PROCESS privilege.
The SUPER privilege allows you to kill processes. Naturally, you don't want that. On the other hand, the PROCESS privilege allows you to see the processlist.
According to the MySQL Documentation on the PROCESS Privilege
The PROCESS privilege pertains to display of information about the
threads executing within the server (that is, information about the
statements being executed by sessions). The privilege enables use of
SHOW PROCESSLIST or mysqladmin processlist to see threads belonging to
other accounts; you can always see your own threads.
OK, Big Deal. The PROCESS Privilege lets you see the Process List. How does that help?
You can quickly detect a mysqldump in progress when you run SHOW PROCESSLIST;
and see a pattern like this in the Info field:
SELECT /*!40001 SQL_NO_CACHE */ * FROM
If you have the PROCESS Privilege and are running MySQL 5.1+, you can run this query:
select COUNT(1) mysqldumpThreads
from information_schema.processlist
where info like 'SELECT /*!40001 SQL_NO_CACHE */%';
Here is a sample output:
mysql> select COUNT(1) mysqldumpThreads
-> from information_schema.processlist
-> where info like 'SELECT /*!40001 SQL_NO_CACHE */%';
+------------------+
| mysqldumpThreads |
+------------------+
| 1 |
+------------------+
1 row in set (0.00 sec)
All you need to do is query for that number. If you get a nonzero, mysqldump must be running.
Give it a Try !!!
Assuming we're talking about a full or differential backup, a marker is placed at the start of the backup process. At the end of the backup process, any transactions that committed during the process are rolled forward into the backup. Any transactions that are not completed are marked as rolled back within the backup. So, the short answer to your question is, all completed transactions from the beginning to the end of the backup process. During a restore operation, the final step is the cleanup of these transactions.
Best Answer
Let me address each of your three Questions
QUESTION #1
ANSWER TO QUESTION #1
Depends on the default settings you allow and what setting you use to override. The
--opt
parameter is enabled by default. That enables--add-drop-table
,--add-locks
,--create-options
,--quick
,--extended-insert
,--lock-tables
,--set-charset
, and--disable-keys
.If you have a database with all InnoDB tables or a mix of InnoDB tables and read-only MyISAM tables, you can just use
--single-transaction
. This will create a clean point-in-time snapshot of all tables involved in the mysqldump. Any INSERT/UPDATE/DELETE queries against an InnoDB table will not interfere with the point-in-time consistency of the mysqldump.By the way, --single-transaction is mutually exclusive to --lock-all-tables. Thus, using --single-transaction will disable --lock-all-tables.
QUESTION #2
ANSWER TO QUESTION #2
You could take the time if you do mysqlbinlog at different times of the day. You could save yourself some off that housekeeping information by simply running
FLUSH LOGS;
orFLUSH BINARY LOGS;
the same time every night. For example, you could script a cronjob to runFLUSH LOGS;
at 11:59 PM like thisThat way you can logically group together all binary logs that have the same date when formulating any needed incremental backup.
You do not have record times or positions in this respect: If you include the option
--master-data=2
in the mysqldump, the log file and position at recorded as a comment on line 22 of the mysqldump output.QUESTION #3
ANSWER TO QUESTION #3
Here is where you have to be very careful. As I mentioned earlier, if you have a database with all InnoDB tables or a mix of InnoDB tables and read-only MyISAM tables, you can use --single-transaction and every table involved in the mysqldump will exist in the same point-in-time.
What Can Go Wrong #1
If you are performing INSERT/UPDATE/DELETE queries against a MyISAM table during the mysqldump, then the MyISAM tables will not be point-in-time consistent.
What Can Go Wrong #2
If you are performing ALTER TABLE, DROP TABLE, RENAME TABLE, or TRUNCATE TABLE against any table (MyISAM or InnoDB), consistent mysqldumps are no longer isolated. The transaction you issued with --single-transaction is released (made null and void) and all tables afterward can no longer the point-in-time consistent.
If one of these occur, recording start times or position is rendered useless.