Merge lp:~hrvojem/percona-xtrabackup/rn-2.1.0-beta1 into lp:percona-xtrabackup/2.1

[Hrvoje Matijakovic]

[Alexey Kopytov (akopytov)]

review: Approve

=== modified file 'doc/source/conf.py'
--- doc/source/conf.py	2013-04-09 07:24:21 +0000
+++ doc/source/conf.py	2013-04-18 13:52:25 +0000
@@ -44,7 +44,7 @@
 
 # General information about the project.
 project = u'Percona XtraBackup'
-copyright = u'2010-2012, Percona Ireland Ltd'
+copyright = u'2010-2013, Percona Ireland Ltd'
 
 # The version info for the project you're documenting, acts as replacement for
 # |version| and |release|, also used in various other places throughout the
@@ -53,7 +53,7 @@
 # The short X.Y version.
 version = '2.1.0'
 # The full version, including alpha/beta/rc tags.
-release = '2.1.0-alpha1'
+release = '2.1.0-beta1'
 
 # The language for content autogenerated by Sphinx. Refer to documentation
 # for a list of supported languages.

=== modified file 'doc/source/installation/compiling_xtrabackup.rst'
--- doc/source/installation/compiling_xtrabackup.rst	2013-03-29 10:33:27 +0000
+++ doc/source/installation/compiling_xtrabackup.rst	2013-04-18 13:52:25 +0000
@@ -41,6 +41,7 @@
   innodb55           5.5		build against InnoDB in MySQL 5.5
   xtradb51           xtradb     build against Percona Server with XtraDB 5.1
   xtradb55           xtradb55   build against Percona Server with XtraDB 5.5
+  innodb56           5.6        build against InnoDB in MySQL 5.6
   ================== =========  ============================================
 
 Note that the script must be executed from the base directory of |Xtrabackup| sources, and that directory must contain the packages with the source code of the codebase selected. This may appear cumbersome, but if the variable ``AUTO_LOAD="yes"`` is set, the :command:`build.sh` script will download all the source code needed for the build.

=== added file 'doc/source/release-notes/2.1/2.1.0-beta1.rst'
--- doc/source/release-notes/2.1/2.1.0-beta1.rst	1970-01-01 00:00:00 +0000
+++ doc/source/release-notes/2.1/2.1.0-beta1.rst	2013-04-18 13:52:25 +0000
@@ -0,0 +1,29 @@
+=======================================
+|Percona XtraBackup| 2.1.0-beta1
+=======================================
+
+Percona is glad to announce the release of |Percona XtraBackup| 2.1.0-beta1 on April 22nd 2013. Downloads are available from our download site `here <http://www.percona.com/downloads/XtraBackup/2.1.0/>`_. For this BETA release, we will not be making APT and YUM repositories available, just base deb and RPM packages
+
+This is an *BETA* quality release and is not intended for production. If you want a high quality, Generally Available release, the current Stable version should be used (currently 2.0.6 in the 2.0 series at the time of writing).
+
+This release contains all of the features and bug fixes in :doc:`Percona XtraBackup 2.0.6 </release-notes/2.0/2.0.6>`, plus the following:
+
+New features
+------------
+
+ |Percona XtraBackup| has implemented basic support for |MySQL| 5.6, |Percona Server| 5.6 and *MariaDB* 10.0. Basic support means that these versions are are recognized by |XtraBackup|, and that backup/restore works as long as no 5.6-specific features are used (such as ``GTID``, remote/transportable tablespaces, separate undo tablespace, 5.6-style buffer pool dump files).
+
+ |Percona XtraBackup| can use `XtraDB changed page tracking <http://www.percona.com/doc/percona-server/5.5/management/changed_page_tracking.html>`_ feature to perform the :ref:`xb_incremental` now.
+
+Bugs Fixed
+----------
+
+ Fixed couple of warnings found in |innobackupex| when all warnings have been made ``FATAL``. Bug fixed :bug:`1116177`.
+
+ |innobackupex| is using ``SHOW MASTER STATUS`` to obtain binlog file and position. This could trigger a bug if the server being backed up was standalone server (neither master nor slave in replication) and binlog information wasn't available. Fixed by not creating :file:`xtrabackup_binlog_info` file when binlog isn't available. Bug fixed :bug:`1168513`.
+
+ Fixed the typo in the |innobackupex| error output. Bug fixed :bug:`1157225`.
+
+ Redundant code has been removed from ``xtrabackup.cc``. Bug fixed :bug:`1162765`.
+
+Other bugs fixed: bug fixed :bug:`1158154`, bug fixed :bug:`1166713`.

=== modified file 'doc/source/xtrabackup_bin/incremental_backups.rst'
--- doc/source/xtrabackup_bin/incremental_backups.rst	2013-04-16 10:35:58 +0000
+++ doc/source/xtrabackup_bin/incremental_backups.rst	2013-04-18 13:52:25 +0000
@@ -1,10 +1,12 @@
+.. _xb_incremental:
+
 =====================
  Incremental Backups
 =====================
 
 Both |xtrabackup| and |innobackupex| tools supports incremental backups, which means that it can copy only the data that has changed since the last full backup. You can perform many incremental backups between each full backup, so you can set up a backup process such as a full backup once a week and an incremental backup every day, or full backups every day and incremental backups every hour.
 
-Incremental backups work because each InnoDB page (usually 16kb in size) contains a log sequence number, or :term:`LSN`. The :term:`LSN` is the system version number for the entire database. Each page's :term:`LSN` shows how recently it was changed. An incremental backup copies each page whose :term:`LSN` is newer than the previous incremental or full backup's :term:`LSN`. There are two algorithms in use to find the set of such pages to be copied. The first one, available with all the server types and versions, is to check the page :term:`LSN` directly by reading all the data pages. The second one, available with |Percona Server|, is to enable the changed page tracking feature on the server, which will note the pages as they are being changed. This information will be then written out in a compact separate so-called bitmap file. The |xtrabackup| binary will use that file to read only the data pages it needs for the incremental backup, potentially saving many read requests. The latter algorithm is enabled by default if the |xtrabackup| binary finds the bitmap file. It is possible to specify :option:`--incremental-force-scan` to read all the pages even if the bitmap data is available.
+Incremental backups work because each InnoDB page (usually 16kb in size) contains a log sequence number, or :term:`LSN`. The :term:`LSN` is the system version number for the entire database. Each page's :term:`LSN` shows how recently it was changed. An incremental backup copies each page whose :term:`LSN` is newer than the previous incremental or full backup's :term:`LSN`. There are two algorithms in use to find the set of such pages to be copied. The first one, available with all the server types and versions, is to check the page :term:`LSN` directly by reading all the data pages. The second one, available with |Percona Server|, is to enable the `changed page tracking <http://www.percona.com/doc/percona-server/5.5/management/changed_page_tracking.html>`_ feature on the server, which will note the pages as they are being changed. This information will be then written out in a compact separate so-called bitmap file. The |xtrabackup| binary will use that file to read only the data pages it needs for the incremental backup, potentially saving many read requests. The latter algorithm is enabled by default if the |xtrabackup| binary finds the bitmap file. It is possible to specify :option:`--incremental-force-scan` to read all the pages even if the bitmap data is available.
 
 Incremental backups do not actually compare the data files to the previous backup's data files. In fact, you can use :option:`--incremental-lsn` to perform an incremental backup without even having the previous backup, if you know its :term:`LSN`. Incremental backups simply read the pages and compare their :term:`LSN` to the last backup's :term:`LSN`. You still need a full backup to recover the incremental changes, however; without a full backup to act as a base, the incremental backups are useless.