List:Commits« Previous MessageNext Message »
From:john.russell Date:November 17 2010 5:15pm
Subject:svn commit - mysqldoc@docsrva: r23808 - trunk/dynamic-docs/glossary
View as plain text  
Author: jrussell
Date: 2010-11-17 18:15:54 +0100 (Wed, 17 Nov 2010)
New Revision: 23808

Log:
Updated some of the backup terminology now that MEB is available.


Modified:
   trunk/dynamic-docs/glossary/innodb.xml


Modified: trunk/dynamic-docs/glossary/innodb.xml
===================================================================
--- trunk/dynamic-docs/glossary/innodb.xml	2010-11-17 16:18:09 UTC (rev 23807)
+++ trunk/dynamic-docs/glossary/innodb.xml	2010-11-17 17:15:54 UTC (rev 23808)
Changed blocks: 15, Lines Added: 72, Lines Deleted: 60; 11460 bytes

@@ -437,8 +437,9 @@
     <def ver="3.5">
 
       <para>
-        The InnoDB Hot Backup product version 3.5 and above supports
-        backing up tablespaces that use the Barracuda file format.
+        The <emphasis role="bold">MySQL Enterprise Backup</emphasis>
+        product version 3.5 and above supports backing up tablespaces
+        that use the Barracuda file format.
       </para>
 
     </def>

@@ -582,10 +583,11 @@
         <literal>mysqlbinlog</literal> command.
       </para>
       <para>
-        For the InnoDB Hot Backup product, the file name of the binary
-        log and the current position within the file are important
-        details. To record this information for the master server when
-        taking a backup in a replication context, you can specify the
+        For the <emphasis role="bold">MySQL Enterprise Backup</emphasis>
+        product, the file name of the binary log and the current
+        position within the file are important details. To record this
+        information for the master server when taking a backup in a
+        replication context, you can specify the
         <literal>--slave-info</literal> option.
       </para>
       <para>

@@ -800,7 +802,8 @@
         products include more than one feature related to compression:
         table data can be kept in a compressed format during database
         operation; data can be compressed as part of a backup operation
-        with the InnoDB Hot Backup product.
+        with the <emphasis role="bold">MySQL Enterprise
+        Backup</emphasis> product.
       </para>
       <para>
         When InnoDB table data is compressed, the compression applies to

@@ -820,8 +823,9 @@
         turned on.
       </para>
       <para>
-        The compression feature of the InnoDB Hot Backup product makes a
-        compressed copy of each tablespace, changing the extension from
+        The compression feature of the <emphasis role="bold">MySQL
+        Enterprise Backup</emphasis> product makes a compressed copy of
+        each tablespace, changing the extension from
         <literal>.ibd</literal> to <literal>.ibz</literal>. Compressing
         the backup data allows you to keep more backups on hand, and
         reduces the time to transfer backups to a different server. The

@@ -1068,16 +1072,18 @@
         <literal>[mysqld]</literal> section of the file.
       </para>
       <para>
-        When you use the InnoDB Hot Backup product, you typically use
-        two configuration files: one that specifies where the data comes
-        from and how it is structured (which could be the original
-        configuration file for your real server), and a stripped-down
-        one containing only a small set of options that specify where
-        the backup data goes and how it is structured. The configuration
-        files used with the InnoDB Hot Backup product must contain
-        certain options that are typically left out of regular
-        configuration files, so you might need to add some options to
-        your existing configuration file for use with InnoDB Hot Backup.
+        When you use the <emphasis role="bold">MySQL Enterprise
+        Backup</emphasis> product, you typically use two configuration
+        files: one that specifies where the data comes from and how it
+        is structured (which could be the original configuration file
+        for your real server), and a stripped-down one containing only a
+        small set of options that specify where the backup data goes and
+        how it is structured. The configuration files used with the
+        <emphasis role="bold">MySQL Enterprise Backup</emphasis> product
+        must contain certain options that are typically left out of
+        regular configuration files, so you might need to add some
+        options to your existing configuration file for use with
+        <emphasis role="bold">MySQL Enterprise Backup</emphasis>.
       </para>
 
     </def>

@@ -1280,9 +1286,9 @@
         <emphasis role="bold">system tablespace</emphasis>.
       </para>
       <para>
-        Because the InnoDB Hot Backup product always backs up the system
-        tablespace, all backups include the contents of the data
-        dictionary.
+        Because the <emphasis role="bold">MySQL Enterprise
+        Backup</emphasis> product always backs up the system tablespace,
+        all backups include the contents of the data dictionary.
       </para>
 
     </def>

@@ -2046,15 +2052,16 @@
         InnoDB to operate on InnoDB tables.
       </para>
       <para>
-        These files are backed up by the InnoDB Hot Backup product.
-        These files must not be modified by an <literal>ALTER
-        TABLE</literal> operation while the backup is taking place,
-        which is why backups that include non-InnoDB tables perform a
-        <literal>FLUSH TABLES WITH READ LOCK</literal> operation to
-        freeze such activity while backing up the
-        <literal>.FRM</literal> files. Restoring a backup can result in
-        <literal>.FRM</literal> files being created, changed, or removed
-        to match the state of the database at the time of the backup.
+        These files are backed up by the <emphasis role="bold">MySQL
+        Enterprise Backup</emphasis> product. These files must not be
+        modified by an <literal>ALTER TABLE</literal> operation while
+        the backup is taking place, which is why backups that include
+        non-InnoDB tables perform a <literal>FLUSH TABLES WITH READ
+        LOCK</literal> operation to freeze such activity while backing
+        up the <literal>.FRM</literal> files. Restoring a backup can
+        result in <literal>.FRM</literal> files being created, changed,
+        or removed to match the state of the database at the time of the
+        backup.
       </para>
 
     </def>

@@ -2105,11 +2112,12 @@
         This mode is the default setting in MySQL 5.5.5 and higher.
       </para>
       <para>
-        The InnoDB Hot Backup product is more flexible for tables that
-        are in their own files. For example, tables can be excluded from
-        a backup, but only if they are in separate files. Thus, this
-        setting is suitable for tables that are backed up less
-        frequently or on a different schedule.
+        The <emphasis role="bold">MySQL Enterprise Backup</emphasis>
+        product is more flexible for tables that are in their own files.
+        For example, tables can be excluded from a backup, but only if
+        they are in separate files. Thus, this setting is suitable for
+        tables that are backed up less frequently or on a different
+        schedule.
       </para>
 
     </def>

@@ -2438,7 +2446,7 @@
     <def>
 
       <para>
-        A licensed backup product, now known as
+        A licensed backup product, superceded in MySQL 5.1 and above by
         <emphasis role="bold">MySQL Enterprise Backup</emphasis>.
       </para>
 

@@ -2631,7 +2639,8 @@
         <emphasis role="bold">system tablespace</emphasis>. This option
         is needed to take full advantage of many other features, such as
         such as table compression in the InnoDB Plugin, or backups of
-        named tables in InnoDB Hot Backup.
+        named tables in <emphasis role="bold">MySQL Enterprise
+        Backup</emphasis>.
       </para>
       <para>
         This option was once static, but can now be set using the

@@ -3159,13 +3168,13 @@
         InnoDB during crash recovery and for managing the buffer pool.
       </para>
       <para>
-        In the InnoDB Hot Backup product, you can specify an LSN to
-        represent the point in time from which to take an
-        <emphasis role="bold">incremental backup</emphasis>. The
-        relevant LSN is displayed by the output of the
-        <literal>ibbackup</literal> command. Once you have the LSN
-        corresponding to the time of a full backup, you can specify that
-        value to take a subsequent incremental backup, whose output
+        In the <emphasis role="bold">MySQL Enterprise Backup</emphasis>
+        product, you can specify an LSN to represent the point in time
+        from which to take an <emphasis role="bold">incremental
+        backup</emphasis>. The relevant LSN is displayed by the output
+        of the <literal>ibbackup</literal> command. Once you have the
+        LSN corresponding to the time of a full backup, you can specify
+        that value to take a subsequent incremental backup, whose output
         contains another LSN for the next incremental backup.
       </para>
 

@@ -3504,11 +3513,11 @@
     <def>
 
       <para>
-        A licensed product, formerly known as InnoDB Hot Backup, that
-        performs <emphasis role="bold">hot backups</emphasis> of MySQL
-        databases. It offers the most efficiency and flexibility when
-        backing up <emphasis role="bold">InnoDB</emphasis> tables, but
-        can also back up MyISAM and other kinds of tables.
+        A licensed product, superceding InnoDB Hot Backup, that performs
+        <emphasis role="bold">hot backups</emphasis> of MySQL databases.
+        It offers the most efficiency and flexibility when backing up
+        <emphasis role="bold">InnoDB</emphasis> tables, but can also
+        back up MyISAM and other kinds of tables.
       </para>
 
     </def>

@@ -4563,9 +4572,10 @@
         fix a corrupted database, to return to some earlier point in
         time, or (in a <emphasis role="bold">replication</emphasis>
         context) to set up a new <emphasis role="bold">slave
-        database</emphasis>. In the InnoDB Hot Backup product, this
-        operation is performed by the <literal>--copy-back</literal>
-        option of the <literal>innobackup</literal> command.
+        database</emphasis>. In the <emphasis role="bold">MySQL
+        Enterprise Backup</emphasis> product, this operation is
+        performed by the <literal>--copy-back</literal> option of the
+        <literal>innobackup</literal> command.
       </para>
 
     </def>

@@ -5429,10 +5439,11 @@
       </para>
       <para>
         Keeping all table data in the system tablespace has implications
-        for the InnoDB Hot Backup product (backing up one large file
-        rather than several smaller files), and prevents you from using
-        certain InnoDB features that require the newer
-        <emphasis role="bold">Barracuda</emphasis> file format. on the
+        for the <emphasis role="bold">MySQL Enterprise Backup</emphasis>
+        product (backing up one large file rather than several smaller
+        files), and prevents you from using certain InnoDB features that
+        require the newer <emphasis role="bold">Barracuda</emphasis>
+        file format. on the
       </para>
 
     </def>

@@ -6057,9 +6068,10 @@
         supported on all the same Microsoft Windows versions as MySQL.
       </para>
       <para>
-        The InnoDB Hot Backup product is available on Windows, although
-        the <literal>innobackup</literal> Perl script is not part of the
-        Windows edition of the product.
+        The <emphasis role="bold">MySQL Enterprise Backup</emphasis>
+        product is available on Windows, although the
+        <literal>innobackup</literal> command is not part of the Windows
+        edition of the product.
       </para>
 
     </def>


Thread
svn commit - mysqldoc@docsrva: r23808 - trunk/dynamic-docs/glossaryjohn.russell17 Nov