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

Proposed by Hrvoje Matijakovic
Status: Merged
Approved by: Alexey Kopytov
Approved revision: 546
Merged at revision: 546
Proposed branch: lp:~hrvojem/percona-xtrabackup/rn-2.1.0-beta1
Merge into: lp:percona-xtrabackup/2.1
Diff against target: 84 lines (+35/-3)
4 files modified
doc/source/conf.py (+2/-2)
doc/source/installation/compiling_xtrabackup.rst (+1/-0)
doc/source/release-notes/2.1/2.1.0-beta1.rst (+29/-0)
doc/source/xtrabackup_bin/incremental_backups.rst (+3/-1)
To merge this branch: bzr merge lp:~hrvojem/percona-xtrabackup/rn-2.1.0-beta1
Reviewer Review Type Date Requested Status
Alexey Kopytov (community) Approve
Review via email: mp+159633@code.launchpad.net
To post a comment you must log in.
Revision history for this message
Alexey Kopytov (akopytov) :
review: Approve

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
1=== modified file 'doc/source/conf.py'
2--- doc/source/conf.py 2013-04-09 07:24:21 +0000
3+++ doc/source/conf.py 2013-04-18 13:52:25 +0000
4@@ -44,7 +44,7 @@
5
6 # General information about the project.
7 project = u'Percona XtraBackup'
8-copyright = u'2010-2012, Percona Ireland Ltd'
9+copyright = u'2010-2013, Percona Ireland Ltd'
10
11 # The version info for the project you're documenting, acts as replacement for
12 # |version| and |release|, also used in various other places throughout the
13@@ -53,7 +53,7 @@
14 # The short X.Y version.
15 version = '2.1.0'
16 # The full version, including alpha/beta/rc tags.
17-release = '2.1.0-alpha1'
18+release = '2.1.0-beta1'
19
20 # The language for content autogenerated by Sphinx. Refer to documentation
21 # for a list of supported languages.
22
23=== modified file 'doc/source/installation/compiling_xtrabackup.rst'
24--- doc/source/installation/compiling_xtrabackup.rst 2013-03-29 10:33:27 +0000
25+++ doc/source/installation/compiling_xtrabackup.rst 2013-04-18 13:52:25 +0000
26@@ -41,6 +41,7 @@
27 innodb55 5.5 build against InnoDB in MySQL 5.5
28 xtradb51 xtradb build against Percona Server with XtraDB 5.1
29 xtradb55 xtradb55 build against Percona Server with XtraDB 5.5
30+ innodb56 5.6 build against InnoDB in MySQL 5.6
31 ================== ========= ============================================
32
33 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.
34
35=== added file 'doc/source/release-notes/2.1/2.1.0-beta1.rst'
36--- doc/source/release-notes/2.1/2.1.0-beta1.rst 1970-01-01 00:00:00 +0000
37+++ doc/source/release-notes/2.1/2.1.0-beta1.rst 2013-04-18 13:52:25 +0000
38@@ -0,0 +1,29 @@
39+=======================================
40+|Percona XtraBackup| 2.1.0-beta1
41+=======================================
42+
43+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
44+
45+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).
46+
47+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:
48+
49+New features
50+------------
51+
52+ |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).
53+
54+ |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.
55+
56+Bugs Fixed
57+----------
58+
59+ Fixed couple of warnings found in |innobackupex| when all warnings have been made ``FATAL``. Bug fixed :bug:`1116177`.
60+
61+ |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`.
62+
63+ Fixed the typo in the |innobackupex| error output. Bug fixed :bug:`1157225`.
64+
65+ Redundant code has been removed from ``xtrabackup.cc``. Bug fixed :bug:`1162765`.
66+
67+Other bugs fixed: bug fixed :bug:`1158154`, bug fixed :bug:`1166713`.
68
69=== modified file 'doc/source/xtrabackup_bin/incremental_backups.rst'
70--- doc/source/xtrabackup_bin/incremental_backups.rst 2013-04-16 10:35:58 +0000
71+++ doc/source/xtrabackup_bin/incremental_backups.rst 2013-04-18 13:52:25 +0000
72@@ -1,10 +1,12 @@
73+.. _xb_incremental:
74+
75 =====================
76 Incremental Backups
77 =====================
78
79 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.
80
81-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.
82+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.
83
84 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.
85

Subscribers

People subscribed via source and target branches