SEARCH
NEW RPMS
DIRECTORIES
ABOUT
FAQ
VARIOUS
BLOG
DONATE


YUM REPOSITORY

 
 
Changelog for xtrabackup-debugsource-2.1.4-34.3.i586.rpm :
Fri Aug 16 14:00:00 2013 mhruseckyAATTsuse.cz
- fix build on Factory

* percona-xtrabackup-2.1.x-mysql-5.6.11-srv_buf_size.patch

Fri Aug 9 14:00:00 2013 andreas.stiegerAATTgmx.de
- update to 2.1.4
This package drops MySQL 5.1 support.
- New features:

* introduce additional options to handle the locking during
FLUSH TABLES WITH READ LOCK to reduce read-only times.

* speed up the backup process by not stopping slave thread when
copying non-InnoDB data when innobackupex --no-lock option

* add option innobackupex --decrypt

* and option innobackupex --decompress

* rebase to MySQL 5.5.30, 5.6.11
- Bugs fixed:

* During the backup process loading tablespaces was started
before the log copying, this could lead to a race between the
datafiles state in the resulting backup and xtrabackup_logfile.
Tablespace created at a sensitive time would be missing in both
the backup itself and as the corresponding log record in
xtrabackup_logfile, so it would not be created on innobackupex
- -apply-log either

* innobackupex did not encrypt non-InnoDB files when doing local
(i.e. non-streaming) backups.

* Difference in behavior between InnoDB 5.5 and 5.6 codebases in
cases when a newly created tablespace has uninitialized first
page at the time when XtraBackup opens it while creating a list
of tablespaces to backup would cause assertion error.

* xbcrypt could sometimes fail when reading encrypted stream from
a pipe or network.

* innobackupex could not prepare the backup if there was no
xtrabackup_binary file in the backup directory and the
xtrabackup binary was not specified explicitly with innobackupex
- -ibbackup option.

* innobackupex would terminate with an error if innobackupex
- -safe-slave-backup option was used for backing up the master

* Under some circumstances XtraBackup could fail on a backup
prepare with innodb_flush_method=O_DIRECT when XFS filesystem was
being used

* Percona XtraBackup didn’t recognize checkpoint #0 as a valid
checkpoint on xtrabackup --prepare which would cause an error.

* Percona XtraBackup didn’t recognize the O_DIRECT_NO_FSYNC value
for innodb_flush_method which was introduced in MySQL 5.6.7.

* innobackupex would terminate if innobackupex --galera-info option
was specified when backing up non-galera server.
- Packaging changes:

* refresh percona-xtrabackup-2.0.2-nodoc.patch to
percona-xtrabackup-2.1.x-nodoc.patch

* drop MySQL 5.1 support

* now requires qpress rather than recommending it because
innobackupex now calls it directly

Thu May 23 14:00:00 2013 andreas.stiegerAATTgmx.de
- update to 2.1.3
- bugs fixed:

* 2.1.2 would hang when performing State Snapshot Transfer
only affects users of XtraDB Cluster

Wed May 22 14:00:00 2013 andreas.stiegerAATTgmx.de
- update to 2.1.2
- bugs fixed:

* Using DBD::MySQL package for server communication instead of
spawning the mysql command line client introduced a regression
which caused innobackupex --galera-info to fail.

* The format of xtrabackup_galera_info was missing the \":\"
separator between the values of wsrep_local_state_uuid and
wsrep_last_committed.

* innobackupex automatic version detection did not work correctly
for latest Percona Server and MySQL 5.1 releases which could
cause innobackupex to fail.

* When backing up a server that is not a replication slave with
the innobackupex --slave-info option, innobackupex failed with
a fatal error. Replaced the fatal error with a diagnostic
message about innobackupex --slave-info being ignored in such a
case.

* Low values for wait_timeout on the server could cause server to
close the connection while backup is being taken.

Wed May 15 14:00:00 2013 andreas.stiegerAATTgmx.de
- 2.1.1, first GA release of 2.1 series
- new features:

* compact backups - backups can now be configured to use less
disk space by omitting secondary index pages and rebuilding
them during prepare phase

* encrypted backukups - encryption of backup data, new command
line utility xbcrypt
- removed features:

* support for InnoDB 5.0 and InnoDB 5.1-builtin removed
(InnoDB 5.1 plugin remains)

* option --remote-host removed
- bugs fixed:

* innobackupex now supports empty arguments to --password option
- packaging changes:

* MySQL 5.1 binary named \"xtrabackup\" correctly

* add build dependency libgcrypt-devel for xbcrypt

* add runtime dependency perl(DBD::mysql fox innobackupex)

* drop xtrabackup-automake-1.13.patch, committed upstream

Tue May 7 14:00:00 2013 andreas.stiegerAATTgmx.de
- update to 2.0.7 [bnc#818819]
- new features:

* implemented full support for new MySQL 5.6 features

* implemented support for the InnoDB Buffer Pool Preloading

* Time interval between checks done by log copying thread is now
configurable by innobackupex --log-copy-interval.

* now stores the GTID value in the xtrabackup_binlog_info with
MySQL and Percona Server 5.6 with the GTID mode enabled.

* --export now supports transportable tablespaces in MySQL 5.6
- bugs fixed

* innobackupex could crash when taking the 5.6 backup due to
linking the wrong SSL library

* Percona XtraBackup would crash when preparing the 5.6 backup
with partitioned tables. Bug fixed #1169169.

* Tables that were dropped between taking a full backup and an
incremental one were present in the full backup directory, and
were not removed when incremental backups has been merged

* Percona XtraBackup would leave stale xtrabackup_tmp
* files in
the datadir after applying incremental backups.

* Fixed couple of warnings found in innobackupex when all warnings
have been made FATAL.

* If there are thousands of tables and slow IO then XtraBackup
can spend a lot of time opening all the tablespaces. Optimization
has been implemented and XtraBackup now avoids loading
non-relevant tablespaces when partial backup is being taken
which speeds up the backup process.

* Percona XtraBackup didn’t initialize per-thread data in the
log copying thread which could cause XtraBackup to crash.

* Percona XtraBackup would fail when preparing the MySQL 5.6 backup
if the log files were bigger than 4G on the source server.

* Due to different implementation in MySQL 5.6 error messages were
not printed to stderr directly. Because of that all InnoDB error
or diagnostic messages are never printed by xtrabackup_56

* innobackupex would still run with FLUSH TABLES WITH READ LOCK
even if xtrabackup would fail when copying logs. Fixed by
terminating xtrabackup process immediately on log copying failure

* innobackupex would fail if the SQL_MODE was set to ANSI_QUOTES.

* Missing space_id from
*.ibd.meta would lead to assertion. Fixed
by replacing the assertion with the error message.

* Fixed the typo in the innobackupex error output.

* When building from source innodb56 target didn’t have an option to
disable DTrace like innodb55 has. Fixed by adding
- DENABLE_DTRACE=OFF build option for innodb56 as well.

* innobackupex wasn’t handling the innodb_data_file_path option
which could cause backup to fail.

* Redundant code has been removed from xtrabackup.cc.

Thu Mar 21 13:00:00 2013 andreas.stiegerAATTgmx.de
- update to 2.0.6 [bnc#810880]
- new features:
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).
- bugs fixed:

* Individual InnoDB tablespaces with size less than 1MB were extended
to 1MB on the backup prepare operation. This led to a large increase
in disk usage in cases when there are many small InnoDB tablespaces.

* Fixed the issue that caused databases corresponding to inaccessible
datadir subdirectories to be ignored by XtraBackup without warning
or error messages. This was happening because InnoDB code silently
ignored datadir subdirectories it could not open.

* Under some circumstances XtraBackup could fail to copy a tablespace
with a high --parallel option value and a low innodb_open_files value.

* Fixed a regression that caused individual partition backups to fail
when used with --include option in innobackupex or the --tables
option in xtrabackup.

* innobackupex didn’t add the file-per-table setting for table-
independent backups. Fixed by making XtraBackup auto-enable
innodb_file_per_table when the --export option is used.

* Under some circumstances XtraBackup could fail on a backup prepare
with innodb_flush_method=O_DIRECT.

* innobackupex did not pass the --tmpdir option to the xtrabackup
binary resulting in the server’s tmpdir always being used for
temporary files.

* XtraBackup has improved the error reporting for unrecognized server
versions.

* innobackupex would fail when --no-lock and --rsync were used in
conjunction.

* Fix a regression that caused xtrabackup_pid file to remain in the
temporary dir after execution.

* Unnecessary debug messages have been removed from the XtraBackup
output

Fri Mar 15 13:00:00 2013 andreas.stiegerAATTgmx.de
- fix path of MySQL 5.5 xtrabackup binary [bnc#809505]

Wed Mar 13 13:00:00 2013 pgajdosAATTsuse.cz
- builds with automake 1.13

* automake-1.13.patch

Mon Jan 28 13:00:00 2013 andreas.stiegerAATTgmx.de
- fix SLE build
- suggest installation of qpress to uncompress backups created
with optional --compress

Thu Jan 24 13:00:00 2013 andreas.stiegerAATTgmx.de
- update to 2.0.5
- new features:
+ New option --defaults-extra-file to read options before the
standard defaults-file, e.g. for separate username/passwords
crontab or a script somewhere in the system.
- bugs fixed:
+ In case of streaming backups, innobackupex would resume the
XtraBackup process and then wait for it to finish before
running UNLOCK TABLES. This caused database to be unnecessarily
locked with FLUSH TABLES WITH READ LOCK. Innobackupex now waits
only till log copying is finished to unlock the databases.
+ innobackupex error messages referencing the data directory
have been extended to show the path of the data directory
mentioned in the error message.
+ Partitioned tables were not correctly handled by the
- -databases, --include, --tables-file options of innobackupex,
and by the --tables and --tables-file options of XtraBackup.
+ When built-in compression was used, XtraBackup was doing
unbuffered writes to the destination file or stream in very
small chunks which in return caused inefficient I/O.
+ Unnecessary long sleep() in innobackupex lead to FLUSH TABLES
WITH READ LOCK taking too long.
+ If innobackupex would crash it would leave the xtrabackup_suspended
file on the filesystem. This could then cause innobackupex to think
XtraBackup has suspended itself the moment it started, and then when
XtraBackup actually does suspend itself, innobackupex would wait for
it to end and wouldn’t re-remove the suspend file, leading to a wait
deadlock.
+ innobackupex would fail to recognize MariaDB 5.2 and MariaDB 5.3
- add perl requirements for innobackupex for completeness

Wed Dec 5 13:00:00 2012 andreas.stiegerAATTgmx.de
- update to 2.0.4
+ a regression introduced in XtraBackup 2.0.2 caused incremental
backups to fail because the init parameter values were not
normalized to the values used inside InnoDB
+ a regression introduced in traBackup 2.0.2 didn’t take the
separate doublewrite tablespace into an account
+ XtraBackup was handling the separate doublewrite buffer file
incorrectly. File path of the doublewrite buffer wasn’t added
to the backup-my.cnf and after the restore old doublewrite buffer
file was used instead of one made during the prepare stage
+ XtraBackup now accepts the --innodb=force option, previously it
would throw an error if the option was set
+ Option safe-slave-backup wasn’t working correctly
+ In case safe-slave-backup-timeout was reached when using the
safe-slave-backup option, SQL_THREAD was left in stopped state
causing the slave thread to lag behind. This was fixed by
checking the initial SQL_THREAD state and starting it before
terminating with a timeout error and starting the SQL_THREAD
only if it was running initially.
+ In case of streaming backups, innobackupex would resume the
Xtrabackup process and then wait for it to finish before running
UNLOCK TABLES. This caused database to be unnecessarily locked
with FLUSH TABLES WITH READ LOCK. Innobackupex now waits only
till log copying is finished to unlock the databases
+ XtraBackup would fail on --apply-log when filesystem didn’t
support Linux AIO
+ XtraBackup binary would ignore innodb_use_native_aio when it’s
specified either in my.cnf or as a command line option
+ XtraBackup would print a warning message during the prepare
stage about innodb_file_io_threads being deprecated, even if the
variable wasn’t set
+ XtraBackup Galera tests can now be run concurrently

Tue Oct 2 14:00:00 2012 andreas.stiegerAATTgmx.de
- update to 2.0.3
- new features:

* innobackupex now supports new --move-back option that can be used
instead of --copy-back in case there isn’t enough free disk space
on the server to copy files. As this option removes backup files,
it must be used with caution.
- bug fixes:

* Symlink for innobackupex-1.5.1 binary has been broken in the
previous version of XtraBackup.

* XtraBackup 2.0.2 was not backwards compatible which caused
incremental backups created with previous versions to fail on
prepare.

* Fix a regression that may potentially lead to a 5x increase in
disk space occupied by incremental backups.

* Fix a regression which caused incorrect handling of compressed
tablespaces with the page size of 16K, that were created between
the last full or incremental and the next incremental backup.
- packaging changes:

* improve upgrade from generic packages

Tue Aug 14 14:00:00 2012 andreas.stiegerAATTgmx.de
- update to 2.0.2

* Fixed false positive test suite failures with grep 2.10

* Incremental backup would fail if a tablespace was created
between full and incremental backups.

* Assertion error in creating a compressed tablespace at delta
apply time has been fixed.

* If the table was renamed after the full backup, but before the
incremental backup has been taken, incremental backups would
fail when being prepared.

* When the variable innodb_log_block_size was set to 4096, backups
would fail in the prepare stage.

* Additional incremental backup tests have been added for the
incremental backup data page copy.
- update percona-xtrabackup-2.0.2-nodoc.patch

Sat Aug 4 14:00:00 2012 andreas.stiegerAATTgmx.de
- add xtrabackup-nodoc.sh to source package - removes documentation
from pristine upstream source packages when maintaining package.
Not used during build or in binary package.

Fri Aug 3 14:00:00 2012 andreas.stiegerAATTgmx.de
- remove documentation from MySQL and xtrabackup tarballs due to license

Sat Jul 7 14:00:00 2012 andreas.stiegerAATTgmx.de
- update to 2.0.1:

* After creating a full compressed backup, performing a
compressed/uncompressed incremental backup would fail because
xtrabackup_checkpoints was compressed. This has been fixed by
omitting xtrabackup_checkpoints from compression, so that a full
backup could be used for incremental backups without decompression.

* --copy-back was copying compressed
*.qp files as well. This has been
fixed by skipping the compressed files while copying the data back.

* Streaming backups with --stream=tar would fail if the file size was
bigger than 8GB. Fixed by changing the libarchive format from USTAR
to restricted PAX which supports bigger file sizes.

* innobackupex was calling the tar utility unconditionally when
streaming ib_lru_dump and xtrabackup_galera_info. Which led to a
broken stream when the xbstream format was used.

* when --compress was used together with --stream=tar, xtrabackup was
silently creating a broken backup. Now it fails with an error
instead, suggesting to either use xbstream, or don\'t use compression
at all.

* --safe-slave-backup was resulting in incorrect binlog info, because
in some cases innobackupex confused the response from SHOW SLAVE
STATUS with the one from SHOW MASTER STATUS.

* xbstream would sometimes fail while extracting the backup.

* innodb_data_file_path was not written to backup-my.cnf, this was a
regression introduced in previous version.

* XtraBackup would fail to find the datadir when using mysqld_multi.
This was fixed by adding new option --defaults-group, to both
innobackupex and xtrabackup, now it can be specified which section
of my.cnf to handle.

* InnoDB tables with names containing: opt, par, CSV, MYD were backed
up twice. These tables were backed up by xtrabackup binary and by
innobackupex script. Regular expression for filtering database
directory contents was fixed.

* When run innobackupex with --apply-log, it was reading configuration
from the server configuration file instead of backup-my.cnf in
backup directory.

* innobackupex could copy files to a wrong directory when merging an
incremental backup to a full one.

* Incremental backups were not working correctly with --stream=tar.
This was fixed by making --incremental-lsn incompatible with
- -stream=tar. XtraBackup will fail with an error message suggesting
to use --stream=xbstream.

* innobackupex failed to copy-back backup if destination dir wasn\'t
empty. Exceptions were added for my.cnf and master.inf` as
XtraBackup doesn\'t backup those files, so it won\'t overwrite
anything.

* innobackupex --copy-back could skip some files when copying from a
Windows filesystem mounted over NFS.

* XtraBackup binary was leaking file descriptors on --backup. This was
fixed by reusing the existing file descriptor so no leak occurs.

* There were no source files in tar.gz archive for Percona XtraBackup
2.0.0.

* XtraBackup|binary could fail with the log block checksum mismatch\"
error when reading an partially written log block.

Tue May 29 14:00:00 2012 andreas.stiegerAATTgmx.de
- cmake >= 2.6.3 is the actual minimum requirement, fixes 11.4

Mon May 28 14:00:00 2012 andreas.stiegerAATTgmx.de
- remove HTML documentation in favour of online documentation
to fix factory build, also simplifies license.
- require cmake >= 2.8.5 to catch this requirement in OBS earlier
when building for SLE

Wed Apr 25 14:00:00 2012 andreas.stiegerAATTgmx.de
- add mysql-5.1.59.tar.gz
- add mysql-5.5.17.tar.gz
- add .changes file
- build with RPM_OPT_FLAGS
- update project URL
- add HTML documentation built from source
- update to upstream 2.0.0:

* Percona XtraBackup can now save Galera replication information while
performing a backup when given the --galera-info option to innobackupex.

* XtraBackup now supports compressed backups. These backups can be done in a
parallel way, thus utilizing multiple CPU cores if needed. In previous
versions, compression was only possible with streaming backups + external
(usually single-threaded) compression utilities, which also had a number of
other limitations (e.g. could not be used with parallel file copying, it was
required to uncompress the entire backup to restore a single table).

* Percona XtraBackup now supports streaming incremental backups. In previous
versions streaming backups were performed by the innobackupex script but
incremental backups were done by the xtrabackup binary which calculated deltas
by scanning data files. Which meant those two feature were mutually exclusive,
i.e. one couldn’t do streaming incremental backups.

* As part of the backup, the LRU dump is now included as well.

* Support for compiling and running Percona XtraBackup against debug versions of
InnoDB. This is only for very advancedusers.
- For fixes included in previous releases, see
http://www.percona.com/doc/percona-xtrabackup/release-notes.html

Tue Jun 9 14:00:00 2009 lenzAATTgrimmer.com
- Update to version 0.7

Thu Apr 30 14:00:00 2009 lenzAATTgrimmer.com
- Update to version 0.6

Thu Apr 9 14:00:00 2009 lenzAATTgrimmer.com
- Initial package added to the openSUSE Build Service (Version 0.5)
Fri Mar 13 00:00:00 UTC 2009 - Vadim Tkachenko
- initial release