← Back to branch summary

~akopytov/percona-xtrabackup/bug950334-2.0

« back to all changes in this revision

Viewing changes to innobackupex

  • Committer: jenkins at percona
  • Date: 2013-01-22 00:55:28 UTC
  • mfrom: (499.1.1 bug1100008-2.0)
  • Revision ID: jenkins@jenkins.percona.com-20130122005528-vxvh5975fozm58j3
Merge lp:~hrvojem/percona-xtrabackup/bug1100008-2.0

Show diffs side-by-side

added added

removed removed

Lines of Context:
innobackupex
2695
2695
#  MariaDB 5.1.* - xtrabackup
2696
2696
#  MariaDB 5.2.* - xtrabackup
2697
2697
#  MariaDB 5.3.* - xtrabackup
2698
 
#  Percona Server >= 11.0 - xtrabackup
 
2698
#  Percona Server 5.0 - xtrabackup_51
 
2699
#  Percona Server 5.1 - xtrabackup
 
2700
#  Percona Server 5.5 - xtrabackup_55
2699
2701
#  MySQL 5.5.* - xtrabackup_55
2700
2702
#  MariaDB 5.5.* - xtrabackup_55
2701
2703
 
2971
2973
 
2972
2974
=item --no-lock
2973
2975
 
2974
 
Use this option to disable table lock with "FLUSH TABLES WITH READ LOCK". Use it only if ALL your tables are InnoDB and you DO NOT CARE about the binary log position of the backup.
 
2976
Use this option to disable table lock with "FLUSH TABLES WITH READ LOCK". Use it only if ALL your tables are InnoDB and you DO NOT CARE about the binary log position of the backup. This option shouldn't be used if there are any DDL statements being executed or if any updates are happening on non-InnoDB tables (this includes the system MyISAM tables in the mysql database), otherwise it could lead to an inconsistent backup. If you are considering to use --no-lock because your backups are failing to acquire the lock, this could be because of incoming replication events preventing the lock from succeeding. Please try using --safe-slave-backup to momentarily stop the replication slave thread, this may help the backup to succeed and you then don't need to resort to using this option.
2975
2977
 
2976
2978
=item --no-timestamp
2977
2979
 
2992
2994
 
2993
2995
=item --redo-only
2994
2996
 
2995
 
This option is passed directly to xtrabackup's --apply-log-only option. This forces xtrabackup to skip the "rollback" phase and do a "redo" only. This is necessary if the backup will have incremental changes applied to it later. See the xtrabackup documentation for details. 
 
2997
This option should be used when preparing the base full backup and when merging all incrementals except the last one. This option is passed directly to xtrabackup's --apply-log-only option. This forces xtrabackup to skip the "rollback" phase and do a "redo" only. This is necessary if the backup will have incremental changes applied to it later. See the xtrabackup documentation for details. 
2996
2998
 
2997
2999
=item --remote-host=HOSTNAME 
2998
3000