| List: | Commits | « Previous MessageNext Message » | |
| From: | paul.dubois | Date: | November 6 2009 9:39pm |
| Subject: | svn commit - mysqldoc@docsrva: r17511 - in trunk: . refman-4.1 refman-5.0 refman-5.1 refman-5.4 refman-5.5 refman-6.0.sav | ||
| View as plain text | |||
Author: paul Date: 2009-11-06 21:39:46 +0100 (Fri, 06 Nov 2009) New Revision: 17511 Log: r46233@frost: paul | 2009-11-06 14:29:43 -0500 General revisions Modified: trunk/refman-4.1/se-innodb-core.xml trunk/refman-5.0/se-innodb-core.xml trunk/refman-5.1/se-innodb-core.xml trunk/refman-5.4/se-innodb-core.xml trunk/refman-5.5/se-innodb-core.xml trunk/refman-6.0.sav/se-innodb-core.xml Property changes on: trunk ___________________________________________________________________ Name: svk:merge - 07c7e7b4-24e3-4b51-89d0-6dc09fec6bec:/mysqldoc-local/mysqldoc/trunk:27680 07c7e7b4-24e3-4b51-89d0-6dc09fec6bec:/mysqldoc-local/trunk:25547 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:43968 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/trunk:44480 7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:46232 b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218 bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:39036 bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/trunk:39546 + 07c7e7b4-24e3-4b51-89d0-6dc09fec6bec:/mysqldoc-local/mysqldoc/trunk:27680 07c7e7b4-24e3-4b51-89d0-6dc09fec6bec:/mysqldoc-local/trunk:25547 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:43968 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/trunk:44480 7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:46233 b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218 bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:39036 bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/trunk:39546 Modified: trunk/refman-4.1/se-innodb-core.xml =================================================================== --- trunk/refman-4.1/se-innodb-core.xml 2009-11-06 20:39:38 UTC (rev 17510) +++ trunk/refman-4.1/se-innodb-core.xml 2009-11-06 20:39:46 UTC (rev 17511) Changed blocks: 4, Lines Added: 66, Lines Deleted: 50; 8478 bytes @@ -3612,26 +3612,39 @@ <section id="innodb-backup"> - <title>Backing Up and Recovering an <literal>InnoDB</literal> Database</title> + <title>Backing Up and Recovering an <literal role="se">InnoDB</literal> + Database</title> + <indexterm> + <primary>InnoDB</primary> + <secondary>backups</secondary> + </indexterm> + + <indexterm> + <primary>backups</primary> + <secondary>InnoDB</secondary> + </indexterm> + <para> The key to safe database management is making regular backups. </para> <para> <command>InnoDB Hot Backup</command> enables you to back up a - running MySQL database, including <literal>InnoDB</literal> and - <literal>MyISAM</literal> tables, with minimal disruption to - operations while producing a consistent snapshot of the database. - When <command>InnoDB Hot Backup</command> is copying - <literal>InnoDB</literal> tables, reads and writes to both - <literal>InnoDB</literal> and <literal>MyISAM</literal> tables can - continue. During the copying of <literal>MyISAM</literal> tables, - reads (but not writes) to those tables are permitted. In addition, + running MySQL database, including + <literal role="se">InnoDB</literal> and + <literal role="se">MyISAM</literal> tables, with minimal + disruption to operations while producing a consistent snapshot of + the database. When <command>InnoDB Hot Backup</command> is copying + <literal role="se">InnoDB</literal> tables, reads and writes to + both <literal role="se">InnoDB</literal> and + <literal role="se">MyISAM</literal> tables can continue. During + the copying of <literal role="se">MyISAM</literal> tables, reads + (but not writes) to those tables are permitted. In addition, <command>InnoDB Hot Backup</command> supports creating compressed backup files, and performing backups of subsets of - <literal>InnoDB</literal> tables. In conjunction with MySQL’s - binary log, users can perform point-in-time recovery. + <literal role="se">InnoDB</literal> tables. In conjunction with + MySQL’s binary log, users can perform point-in-time recovery. <command>InnoDB Hot Backup</command> is commercially licensed by Innobase Oy. For a more complete description of <command>InnoDB Hot Backup</command>, see @@ -3645,56 +3658,51 @@ <para> If you are able to shut down your MySQL server, you can make a binary backup that consists of all files used by - <literal>InnoDB</literal> to manage its tables. Use the following - procedure: + <literal role="se">InnoDB</literal> to manage its tables. Use the + following procedure: </para> <orderedlist> <listitem> <para> - Shut down your MySQL server and make sure that it shuts down - without errors. + Shut down the MySQL server and make sure that it stops without + errors. </para> </listitem> <listitem> <para> - Copy all your data files (<filename>ibdata</filename> files - and <filename>.ibd</filename> files) into a safe place. + Copy all <literal role="se">InnoDB</literal> data files + (<filename>ibdata</filename> files and + <filename>.ibd</filename> files) into a safe place. </para> </listitem> <listitem> <para> - Copy all your <filename>ib_logfile</filename> files to a safe - place. + Copy all the <filename>.frm</filename> files for + <literal role="se">InnoDB</literal> tables to a safe place. </para> </listitem> <listitem> <para> - Copy your <filename>my.cnf</filename> configuration file or - files to a safe place. + Copy all <literal role="se">InnoDB</literal> log files + (<filename>ib_logfile</filename> files) to a safe place. </para> </listitem> <listitem> <para> - Copy all the <filename>.frm</filename> files for your - <literal>InnoDB</literal> tables to a safe place. + Copy your <filename>my.cnf</filename> configuration file or + files to a safe place. </para> </listitem> </orderedlist> <para> - Replication works with <literal>InnoDB</literal> tables, so you - can use MySQL replication capabilities to keep a copy of your - database at database sites requiring high availability. - </para> - - <para> In addition to making binary backups as just described, you should also regularly make dumps of your tables with <command>mysqldump</command>. The reason for this is that a binary @@ -3703,28 +3711,35 @@ corruption becomes easier. Also, because the format is simpler, the chance for serious data corruption is smaller. <command>mysqldump</command> also has a - <option role="mysqldump">--single-transaction</option> option that - you can use to make a consistent snapshot without locking out - other clients. See <xref linkend="backup-policy"/>. + <option role="mysqldump">--single-transaction</option> option for + making a consistent snapshot without locking out other clients. + See <xref linkend="backup-policy"/>. </para> <para> - To be able to recover your <literal>InnoDB</literal> database to - the present from the binary backup just described, you have to run - your MySQL server with binary logging turned on. To achieve - point-in-time recovery after restoring a backup, you can apply - changes from the binary log that occurred after the backup was - made. See <xref linkend="point-in-time-recovery"/>. + Replication works with <literal role="se">InnoDB</literal> tables, + so you can use MySQL replication capabilities to keep a copy of + your database at database sites requiring high availability. </para> <para> + To be able to recover your <literal role="se">InnoDB</literal> + database to the present from the time at which the binary backup + was made, you must run your MySQL server with binary logging + turned on. To achieve point-in-time recovery after restoring a + backup, you can apply changes from the binary log that occurred + after the backup was made. See + <xref linkend="point-in-time-recovery"/>. + </para> + + <para> To recover from a crash of your MySQL server, the only requirement - is to restart it. <literal>InnoDB</literal> automatically checks - the logs and performs a roll-forward of the database to the - present. <literal>InnoDB</literal> automatically rolls back - uncommitted transactions that were present at the time of the - crash. During recovery, <command>mysqld</command> displays output - something like this: + is to restart it. <literal role="se">InnoDB</literal> + automatically checks the logs and performs a roll-forward of the + database to the present. <literal role="se">InnoDB</literal> + automatically rolls back uncommitted transactions that were + present at the time of the crash. During recovery, + <command>mysqld</command> displays output something like this: </para> <programlisting> @@ -3752,12 +3767,13 @@ </programlisting> <para> - If your database gets corrupted or your disk fails, you have to do - the recovery from a backup. In the case of corruption, you should - first find a backup that is not corrupted. After restoring the - base backup, do the recovery from the binary log files using - <command>mysqlbinlog</command> and <command>mysql</command> to - restore the changes that occurred after the backup was made. + If your database becomes corrupted or disk failure occurs, you + must perform the recovery using a backup. In the case of + corruption, you should first find a backup that is not corrupted. + After restoring the base backup, do a point-in-time recovery from + the binary log files using <command>mysqlbinlog</command> and + <command>mysql</command> to restore the changes that occurred + after the backup was made. </para> <indexterm> Modified: trunk/refman-5.0/se-innodb-core.xml =================================================================== --- trunk/refman-5.0/se-innodb-core.xml 2009-11-06 20:39:38 UTC (rev 17510) +++ trunk/refman-5.0/se-innodb-core.xml 2009-11-06 20:39:46 UTC (rev 17511) Changed blocks: 4, Lines Added: 66, Lines Deleted: 50; 8478 bytes @@ -3794,26 +3794,39 @@ <section id="innodb-backup"> - <title>Backing Up and Recovering an <literal>InnoDB</literal> Database</title> + <title>Backing Up and Recovering an <literal role="se">InnoDB</literal> + Database</title> + <indexterm> + <primary>InnoDB</primary> + <secondary>backups</secondary> + </indexterm> + + <indexterm> + <primary>backups</primary> + <secondary>InnoDB</secondary> + </indexterm> + <para> The key to safe database management is making regular backups. </para> <para> <command>InnoDB Hot Backup</command> enables you to back up a - running MySQL database, including <literal>InnoDB</literal> and - <literal>MyISAM</literal> tables, with minimal disruption to - operations while producing a consistent snapshot of the database. - When <command>InnoDB Hot Backup</command> is copying - <literal>InnoDB</literal> tables, reads and writes to both - <literal>InnoDB</literal> and <literal>MyISAM</literal> tables can - continue. During the copying of <literal>MyISAM</literal> tables, - reads (but not writes) to those tables are permitted. In addition, + running MySQL database, including + <literal role="se">InnoDB</literal> and + <literal role="se">MyISAM</literal> tables, with minimal + disruption to operations while producing a consistent snapshot of + the database. When <command>InnoDB Hot Backup</command> is copying + <literal role="se">InnoDB</literal> tables, reads and writes to + both <literal role="se">InnoDB</literal> and + <literal role="se">MyISAM</literal> tables can continue. During + the copying of <literal role="se">MyISAM</literal> tables, reads + (but not writes) to those tables are permitted. In addition, <command>InnoDB Hot Backup</command> supports creating compressed backup files, and performing backups of subsets of - <literal>InnoDB</literal> tables. In conjunction with MySQL’s - binary log, users can perform point-in-time recovery. + <literal role="se">InnoDB</literal> tables. In conjunction with + MySQL’s binary log, users can perform point-in-time recovery. <command>InnoDB Hot Backup</command> is commercially licensed by Innobase Oy. For a more complete description of <command>InnoDB Hot Backup</command>, see @@ -3827,56 +3840,51 @@ <para> If you are able to shut down your MySQL server, you can make a binary backup that consists of all files used by - <literal>InnoDB</literal> to manage its tables. Use the following - procedure: + <literal role="se">InnoDB</literal> to manage its tables. Use the + following procedure: </para> <orderedlist> <listitem> <para> - Shut down your MySQL server and make sure that it shuts down - without errors. + Shut down the MySQL server and make sure that it stops without + errors. </para> </listitem> <listitem> <para> - Copy all your data files (<filename>ibdata</filename> files - and <filename>.ibd</filename> files) into a safe place. + Copy all <literal role="se">InnoDB</literal> data files + (<filename>ibdata</filename> files and + <filename>.ibd</filename> files) into a safe place. </para> </listitem> <listitem> <para> - Copy all your <filename>ib_logfile</filename> files to a safe - place. + Copy all the <filename>.frm</filename> files for + <literal role="se">InnoDB</literal> tables to a safe place. </para> </listitem> <listitem> <para> - Copy your <filename>my.cnf</filename> configuration file or - files to a safe place. + Copy all <literal role="se">InnoDB</literal> log files + (<filename>ib_logfile</filename> files) to a safe place. </para> </listitem> <listitem> <para> - Copy all the <filename>.frm</filename> files for your - <literal>InnoDB</literal> tables to a safe place. + Copy your <filename>my.cnf</filename> configuration file or + files to a safe place. </para> </listitem> </orderedlist> <para> - Replication works with <literal>InnoDB</literal> tables, so you - can use MySQL replication capabilities to keep a copy of your - database at database sites requiring high availability. - </para> - - <para> In addition to making binary backups as just described, you should also regularly make dumps of your tables with <command>mysqldump</command>. The reason for this is that a binary @@ -3885,28 +3893,35 @@ corruption becomes easier. Also, because the format is simpler, the chance for serious data corruption is smaller. <command>mysqldump</command> also has a - <option role="mysqldump">--single-transaction</option> option that - you can use to make a consistent snapshot without locking out - other clients. See <xref linkend="backup-policy"/>. + <option role="mysqldump">--single-transaction</option> option for + making a consistent snapshot without locking out other clients. + See <xref linkend="backup-policy"/>. </para> <para> - To be able to recover your <literal>InnoDB</literal> database to - the present from the binary backup just described, you have to run - your MySQL server with binary logging turned on. To achieve - point-in-time recovery after restoring a backup, you can apply - changes from the binary log that occurred after the backup was - made. See <xref linkend="point-in-time-recovery"/>. + Replication works with <literal role="se">InnoDB</literal> tables, + so you can use MySQL replication capabilities to keep a copy of + your database at database sites requiring high availability. </para> <para> + To be able to recover your <literal role="se">InnoDB</literal> + database to the present from the time at which the binary backup + was made, you must run your MySQL server with binary logging + turned on. To achieve point-in-time recovery after restoring a + backup, you can apply changes from the binary log that occurred + after the backup was made. See + <xref linkend="point-in-time-recovery"/>. + </para> + + <para> To recover from a crash of your MySQL server, the only requirement - is to restart it. <literal>InnoDB</literal> automatically checks - the logs and performs a roll-forward of the database to the - present. <literal>InnoDB</literal> automatically rolls back - uncommitted transactions that were present at the time of the - crash. During recovery, <command>mysqld</command> displays output - something like this: + is to restart it. <literal role="se">InnoDB</literal> + automatically checks the logs and performs a roll-forward of the + database to the present. <literal role="se">InnoDB</literal> + automatically rolls back uncommitted transactions that were + present at the time of the crash. During recovery, + <command>mysqld</command> displays output something like this: </para> <programlisting> @@ -3934,12 +3949,13 @@ </programlisting> <para> - If your database gets corrupted or your disk fails, you have to do - the recovery from a backup. In the case of corruption, you should - first find a backup that is not corrupted. After restoring the - base backup, do the recovery from the binary log files using - <command>mysqlbinlog</command> and <command>mysql</command> to - restore the changes that occurred after the backup was made. + If your database becomes corrupted or disk failure occurs, you + must perform the recovery using a backup. In the case of + corruption, you should first find a backup that is not corrupted. + After restoring the base backup, do a point-in-time recovery from + the binary log files using <command>mysqlbinlog</command> and + <command>mysql</command> to restore the changes that occurred + after the backup was made. </para> <indexterm> Modified: trunk/refman-5.1/se-innodb-core.xml =================================================================== --- trunk/refman-5.1/se-innodb-core.xml 2009-11-06 20:39:38 UTC (rev 17510) +++ trunk/refman-5.1/se-innodb-core.xml 2009-11-06 20:39:46 UTC (rev 17511) Changed blocks: 4, Lines Added: 66, Lines Deleted: 50; 8478 bytes @@ -4907,26 +4907,39 @@ <section id="innodb-backup"> - <title>Backing Up and Recovering an <literal>InnoDB</literal> Database</title> + <title>Backing Up and Recovering an <literal role="se">InnoDB</literal> + Database</title> + <indexterm> + <primary>InnoDB</primary> + <secondary>backups</secondary> + </indexterm> + + <indexterm> + <primary>backups</primary> + <secondary>InnoDB</secondary> + </indexterm> + <para> The key to safe database management is making regular backups. </para> <para> <command>InnoDB Hot Backup</command> enables you to back up a - running MySQL database, including <literal>InnoDB</literal> and - <literal>MyISAM</literal> tables, with minimal disruption to - operations while producing a consistent snapshot of the database. - When <command>InnoDB Hot Backup</command> is copying - <literal>InnoDB</literal> tables, reads and writes to both - <literal>InnoDB</literal> and <literal>MyISAM</literal> tables can - continue. During the copying of <literal>MyISAM</literal> tables, - reads (but not writes) to those tables are permitted. In addition, + running MySQL database, including + <literal role="se">InnoDB</literal> and + <literal role="se">MyISAM</literal> tables, with minimal + disruption to operations while producing a consistent snapshot of + the database. When <command>InnoDB Hot Backup</command> is copying + <literal role="se">InnoDB</literal> tables, reads and writes to + both <literal role="se">InnoDB</literal> and + <literal role="se">MyISAM</literal> tables can continue. During + the copying of <literal role="se">MyISAM</literal> tables, reads + (but not writes) to those tables are permitted. In addition, <command>InnoDB Hot Backup</command> supports creating compressed backup files, and performing backups of subsets of - <literal>InnoDB</literal> tables. In conjunction with MySQL’s - binary log, users can perform point-in-time recovery. + <literal role="se">InnoDB</literal> tables. In conjunction with + MySQL’s binary log, users can perform point-in-time recovery. <command>InnoDB Hot Backup</command> is commercially licensed by Innobase Oy. For a more complete description of <command>InnoDB Hot Backup</command>, see @@ -4940,56 +4953,51 @@ <para> If you are able to shut down your MySQL server, you can make a binary backup that consists of all files used by - <literal>InnoDB</literal> to manage its tables. Use the following - procedure: + <literal role="se">InnoDB</literal> to manage its tables. Use the + following procedure: </para> <orderedlist> <listitem> <para> - Shut down your MySQL server and make sure that it shuts down - without errors. + Shut down the MySQL server and make sure that it stops without + errors. </para> </listitem> <listitem> <para> - Copy all your data files (<filename>ibdata</filename> files - and <filename>.ibd</filename> files) into a safe place. + Copy all <literal role="se">InnoDB</literal> data files + (<filename>ibdata</filename> files and + <filename>.ibd</filename> files) into a safe place. </para> </listitem> <listitem> <para> - Copy all your <filename>ib_logfile</filename> files to a safe - place. + Copy all the <filename>.frm</filename> files for + <literal role="se">InnoDB</literal> tables to a safe place. </para> </listitem> <listitem> <para> - Copy your <filename>my.cnf</filename> configuration file or - files to a safe place. + Copy all <literal role="se">InnoDB</literal> log files + (<filename>ib_logfile</filename> files) to a safe place. </para> </listitem> <listitem> <para> - Copy all the <filename>.frm</filename> files for your - <literal>InnoDB</literal> tables to a safe place. + Copy your <filename>my.cnf</filename> configuration file or + files to a safe place. </para> </listitem> </orderedlist> <para> - Replication works with <literal>InnoDB</literal> tables, so you - can use MySQL replication capabilities to keep a copy of your - database at database sites requiring high availability. - </para> - - <para> In addition to making binary backups as just described, you should also regularly make dumps of your tables with <command>mysqldump</command>. The reason for this is that a binary @@ -4998,28 +5006,35 @@ corruption becomes easier. Also, because the format is simpler, the chance for serious data corruption is smaller. <command>mysqldump</command> also has a - <option role="mysqldump">--single-transaction</option> option that - you can use to make a consistent snapshot without locking out - other clients. See <xref linkend="backup-policy"/>. + <option role="mysqldump">--single-transaction</option> option for + making a consistent snapshot without locking out other clients. + See <xref linkend="backup-policy"/>. </para> <para> - To be able to recover your <literal>InnoDB</literal> database to - the present from the binary backup just described, you have to run - your MySQL server with binary logging turned on. To achieve - point-in-time recovery after restoring a backup, you can apply - changes from the binary log that occurred after the backup was - made. See <xref linkend="point-in-time-recovery"/>. + Replication works with <literal role="se">InnoDB</literal> tables, + so you can use MySQL replication capabilities to keep a copy of + your database at database sites requiring high availability. </para> <para> + To be able to recover your <literal role="se">InnoDB</literal> + database to the present from the time at which the binary backup + was made, you must run your MySQL server with binary logging + turned on. To achieve point-in-time recovery after restoring a + backup, you can apply changes from the binary log that occurred + after the backup was made. See + <xref linkend="point-in-time-recovery"/>. + </para> + + <para> To recover from a crash of your MySQL server, the only requirement - is to restart it. <literal>InnoDB</literal> automatically checks - the logs and performs a roll-forward of the database to the - present. <literal>InnoDB</literal> automatically rolls back - uncommitted transactions that were present at the time of the - crash. During recovery, <command>mysqld</command> displays output - something like this: + is to restart it. <literal role="se">InnoDB</literal> + automatically checks the logs and performs a roll-forward of the + database to the present. <literal role="se">InnoDB</literal> + automatically rolls back uncommitted transactions that were + present at the time of the crash. During recovery, + <command>mysqld</command> displays output something like this: </para> <programlisting> @@ -5047,12 +5062,13 @@ </programlisting> <para> - If your database gets corrupted or your disk fails, you have to do - the recovery from a backup. In the case of corruption, you should - first find a backup that is not corrupted. After restoring the - base backup, do the recovery from the binary log files using - <command>mysqlbinlog</command> and <command>mysql</command> to - restore the changes that occurred after the backup was made. + If your database becomes corrupted or disk failure occurs, you + must perform the recovery using a backup. In the case of + corruption, you should first find a backup that is not corrupted. + After restoring the base backup, do a point-in-time recovery from + the binary log files using <command>mysqlbinlog</command> and + <command>mysql</command> to restore the changes that occurred + after the backup was made. </para> <indexterm> Modified: trunk/refman-5.4/se-innodb-core.xml =================================================================== --- trunk/refman-5.4/se-innodb-core.xml 2009-11-06 20:39:38 UTC (rev 17510) +++ trunk/refman-5.4/se-innodb-core.xml 2009-11-06 20:39:46 UTC (rev 17511) Changed blocks: 4, Lines Added: 66, Lines Deleted: 50; 8478 bytes @@ -4612,26 +4612,39 @@ <section id="innodb-backup"> - <title>Backing Up and Recovering an <literal>InnoDB</literal> Database</title> + <title>Backing Up and Recovering an <literal role="se">InnoDB</literal> + Database</title> + <indexterm> + <primary>InnoDB</primary> + <secondary>backups</secondary> + </indexterm> + + <indexterm> + <primary>backups</primary> + <secondary>InnoDB</secondary> + </indexterm> + <para> The key to safe database management is making regular backups. </para> <para> <command>InnoDB Hot Backup</command> enables you to back up a - running MySQL database, including <literal>InnoDB</literal> and - <literal>MyISAM</literal> tables, with minimal disruption to - operations while producing a consistent snapshot of the database. - When <command>InnoDB Hot Backup</command> is copying - <literal>InnoDB</literal> tables, reads and writes to both - <literal>InnoDB</literal> and <literal>MyISAM</literal> tables can - continue. During the copying of <literal>MyISAM</literal> tables, - reads (but not writes) to those tables are permitted. In addition, + running MySQL database, including + <literal role="se">InnoDB</literal> and + <literal role="se">MyISAM</literal> tables, with minimal + disruption to operations while producing a consistent snapshot of + the database. When <command>InnoDB Hot Backup</command> is copying + <literal role="se">InnoDB</literal> tables, reads and writes to + both <literal role="se">InnoDB</literal> and + <literal role="se">MyISAM</literal> tables can continue. During + the copying of <literal role="se">MyISAM</literal> tables, reads + (but not writes) to those tables are permitted. In addition, <command>InnoDB Hot Backup</command> supports creating compressed backup files, and performing backups of subsets of - <literal>InnoDB</literal> tables. In conjunction with MySQL’s - binary log, users can perform point-in-time recovery. + <literal role="se">InnoDB</literal> tables. In conjunction with + MySQL’s binary log, users can perform point-in-time recovery. <command>InnoDB Hot Backup</command> is commercially licensed by Innobase Oy. For a more complete description of <command>InnoDB Hot Backup</command>, see @@ -4645,56 +4658,51 @@ <para> If you are able to shut down your MySQL server, you can make a binary backup that consists of all files used by - <literal>InnoDB</literal> to manage its tables. Use the following - procedure: + <literal role="se">InnoDB</literal> to manage its tables. Use the + following procedure: </para> <orderedlist> <listitem> <para> - Shut down your MySQL server and make sure that it shuts down - without errors. + Shut down the MySQL server and make sure that it stops without + errors. </para> </listitem> <listitem> <para> - Copy all your data files (<filename>ibdata</filename> files - and <filename>.ibd</filename> files) into a safe place. + Copy all <literal role="se">InnoDB</literal> data files + (<filename>ibdata</filename> files and + <filename>.ibd</filename> files) into a safe place. </para> </listitem> <listitem> <para> - Copy all your <filename>ib_logfile</filename> files to a safe - place. + Copy all the <filename>.frm</filename> files for + <literal role="se">InnoDB</literal> tables to a safe place. </para> </listitem> <listitem> <para> - Copy your <filename>my.cnf</filename> configuration file or - files to a safe place. + Copy all <literal role="se">InnoDB</literal> log files + (<filename>ib_logfile</filename> files) to a safe place. </para> </listitem> <listitem> <para> - Copy all the <filename>.frm</filename> files for your - <literal>InnoDB</literal> tables to a safe place. + Copy your <filename>my.cnf</filename> configuration file or + files to a safe place. </para> </listitem> </orderedlist> <para> - Replication works with <literal>InnoDB</literal> tables, so you - can use MySQL replication capabilities to keep a copy of your - database at database sites requiring high availability. - </para> - - <para> In addition to making binary backups as just described, you should also regularly make dumps of your tables with <command>mysqldump</command>. The reason for this is that a binary @@ -4703,28 +4711,35 @@ corruption becomes easier. Also, because the format is simpler, the chance for serious data corruption is smaller. <command>mysqldump</command> also has a - <option role="mysqldump">--single-transaction</option> option that - you can use to make a consistent snapshot without locking out - other clients. See <xref linkend="backup-policy"/>. + <option role="mysqldump">--single-transaction</option> option for + making a consistent snapshot without locking out other clients. + See <xref linkend="backup-policy"/>. </para> <para> - To be able to recover your <literal>InnoDB</literal> database to - the present from the binary backup just described, you have to run - your MySQL server with binary logging turned on. To achieve - point-in-time recovery after restoring a backup, you can apply - changes from the binary log that occurred after the backup was - made. See <xref linkend="point-in-time-recovery"/>. + Replication works with <literal role="se">InnoDB</literal> tables, + so you can use MySQL replication capabilities to keep a copy of + your database at database sites requiring high availability. </para> <para> + To be able to recover your <literal role="se">InnoDB</literal> + database to the present from the time at which the binary backup + was made, you must run your MySQL server with binary logging + turned on. To achieve point-in-time recovery after restoring a + backup, you can apply changes from the binary log that occurred + after the backup was made. See + <xref linkend="point-in-time-recovery"/>. + </para> + + <para> To recover from a crash of your MySQL server, the only requirement - is to restart it. <literal>InnoDB</literal> automatically checks - the logs and performs a roll-forward of the database to the - present. <literal>InnoDB</literal> automatically rolls back - uncommitted transactions that were present at the time of the - crash. During recovery, <command>mysqld</command> displays output - something like this: + is to restart it. <literal role="se">InnoDB</literal> + automatically checks the logs and performs a roll-forward of the + database to the present. <literal role="se">InnoDB</literal> + automatically rolls back uncommitted transactions that were + present at the time of the crash. During recovery, + <command>mysqld</command> displays output something like this: </para> <programlisting> @@ -4752,12 +4767,13 @@ </programlisting> <para> - If your database gets corrupted or your disk fails, you have to do - the recovery from a backup. In the case of corruption, you should - first find a backup that is not corrupted. After restoring the - base backup, do the recovery from the binary log files using - <command>mysqlbinlog</command> and <command>mysql</command> to - restore the changes that occurred after the backup was made. + If your database becomes corrupted or disk failure occurs, you + must perform the recovery using a backup. In the case of + corruption, you should first find a backup that is not corrupted. + After restoring the base backup, do a point-in-time recovery from + the binary log files using <command>mysqlbinlog</command> and + <command>mysql</command> to restore the changes that occurred + after the backup was made. </para> <indexterm> Modified: trunk/refman-5.5/se-innodb-core.xml =================================================================== --- trunk/refman-5.5/se-innodb-core.xml 2009-11-06 20:39:38 UTC (rev 17510) +++ trunk/refman-5.5/se-innodb-core.xml 2009-11-06 20:39:46 UTC (rev 17511) Changed blocks: 4, Lines Added: 66, Lines Deleted: 50; 8478 bytes @@ -4583,26 +4583,39 @@ <section id="innodb-backup"> - <title>Backing Up and Recovering an <literal>InnoDB</literal> Database</title> + <title>Backing Up and Recovering an <literal role="se">InnoDB</literal> + Database</title> + <indexterm> + <primary>InnoDB</primary> + <secondary>backups</secondary> + </indexterm> + + <indexterm> + <primary>backups</primary> + <secondary>InnoDB</secondary> + </indexterm> + <para> The key to safe database management is making regular backups. </para> <para> <command>InnoDB Hot Backup</command> enables you to back up a - running MySQL database, including <literal>InnoDB</literal> and - <literal>MyISAM</literal> tables, with minimal disruption to - operations while producing a consistent snapshot of the database. - When <command>InnoDB Hot Backup</command> is copying - <literal>InnoDB</literal> tables, reads and writes to both - <literal>InnoDB</literal> and <literal>MyISAM</literal> tables can - continue. During the copying of <literal>MyISAM</literal> tables, - reads (but not writes) to those tables are permitted. In addition, + running MySQL database, including + <literal role="se">InnoDB</literal> and + <literal role="se">MyISAM</literal> tables, with minimal + disruption to operations while producing a consistent snapshot of + the database. When <command>InnoDB Hot Backup</command> is copying + <literal role="se">InnoDB</literal> tables, reads and writes to + both <literal role="se">InnoDB</literal> and + <literal role="se">MyISAM</literal> tables can continue. During + the copying of <literal role="se">MyISAM</literal> tables, reads + (but not writes) to those tables are permitted. In addition, <command>InnoDB Hot Backup</command> supports creating compressed backup files, and performing backups of subsets of - <literal>InnoDB</literal> tables. In conjunction with MySQL’s - binary log, users can perform point-in-time recovery. + <literal role="se">InnoDB</literal> tables. In conjunction with + MySQL’s binary log, users can perform point-in-time recovery. <command>InnoDB Hot Backup</command> is commercially licensed by Innobase Oy. For a more complete description of <command>InnoDB Hot Backup</command>, see @@ -4616,56 +4629,51 @@ <para> If you are able to shut down your MySQL server, you can make a binary backup that consists of all files used by - <literal>InnoDB</literal> to manage its tables. Use the following - procedure: + <literal role="se">InnoDB</literal> to manage its tables. Use the + following procedure: </para> <orderedlist> <listitem> <para> - Shut down your MySQL server and make sure that it shuts down - without errors. + Shut down the MySQL server and make sure that it stops without + errors. </para> </listitem> <listitem> <para> - Copy all your data files (<filename>ibdata</filename> files - and <filename>.ibd</filename> files) into a safe place. + Copy all <literal role="se">InnoDB</literal> data files + (<filename>ibdata</filename> files and + <filename>.ibd</filename> files) into a safe place. </para> </listitem> <listitem> <para> - Copy all your <filename>ib_logfile</filename> files to a safe - place. + Copy all the <filename>.frm</filename> files for + <literal role="se">InnoDB</literal> tables to a safe place. </para> </listitem> <listitem> <para> - Copy your <filename>my.cnf</filename> configuration file or - files to a safe place. + Copy all <literal role="se">InnoDB</literal> log files + (<filename>ib_logfile</filename> files) to a safe place. </para> </listitem> <listitem> <para> - Copy all the <filename>.frm</filename> files for your - <literal>InnoDB</literal> tables to a safe place. + Copy your <filename>my.cnf</filename> configuration file or + files to a safe place. </para> </listitem> </orderedlist> <para> - Replication works with <literal>InnoDB</literal> tables, so you - can use MySQL replication capabilities to keep a copy of your - database at database sites requiring high availability. - </para> - - <para> In addition to making binary backups as just described, you should also regularly make dumps of your tables with <command>mysqldump</command>. The reason for this is that a binary @@ -4674,28 +4682,35 @@ corruption becomes easier. Also, because the format is simpler, the chance for serious data corruption is smaller. <command>mysqldump</command> also has a - <option role="mysqldump">--single-transaction</option> option that - you can use to make a consistent snapshot without locking out - other clients. See <xref linkend="backup-policy"/>. + <option role="mysqldump">--single-transaction</option> option for + making a consistent snapshot without locking out other clients. + See <xref linkend="backup-policy"/>. </para> <para> - To be able to recover your <literal>InnoDB</literal> database to - the present from the binary backup just described, you have to run - your MySQL server with binary logging turned on. To achieve - point-in-time recovery after restoring a backup, you can apply - changes from the binary log that occurred after the backup was - made. See <xref linkend="point-in-time-recovery"/>. + Replication works with <literal role="se">InnoDB</literal> tables, + so you can use MySQL replication capabilities to keep a copy of + your database at database sites requiring high availability. </para> <para> + To be able to recover your <literal role="se">InnoDB</literal> + database to the present from the time at which the binary backup + was made, you must run your MySQL server with binary logging + turned on. To achieve point-in-time recovery after restoring a + backup, you can apply changes from the binary log that occurred + after the backup was made. See + <xref linkend="point-in-time-recovery"/>. + </para> + + <para> To recover from a crash of your MySQL server, the only requirement - is to restart it. <literal>InnoDB</literal> automatically checks - the logs and performs a roll-forward of the database to the - present. <literal>InnoDB</literal> automatically rolls back - uncommitted transactions that were present at the time of the - crash. During recovery, <command>mysqld</command> displays output - something like this: + is to restart it. <literal role="se">InnoDB</literal> + automatically checks the logs and performs a roll-forward of the + database to the present. <literal role="se">InnoDB</literal> + automatically rolls back uncommitted transactions that were + present at the time of the crash. During recovery, + <command>mysqld</command> displays output something like this: </para> <programlisting> @@ -4723,12 +4738,13 @@ </programlisting> <para> - If your database gets corrupted or your disk fails, you have to do - the recovery from a backup. In the case of corruption, you should - first find a backup that is not corrupted. After restoring the - base backup, do the recovery from the binary log files using - <command>mysqlbinlog</command> and <command>mysql</command> to - restore the changes that occurred after the backup was made. + If your database becomes corrupted or disk failure occurs, you + must perform the recovery using a backup. In the case of + corruption, you should first find a backup that is not corrupted. + After restoring the base backup, do a point-in-time recovery from + the binary log files using <command>mysqlbinlog</command> and + <command>mysql</command> to restore the changes that occurred + after the backup was made. </para> <indexterm> Modified: trunk/refman-6.0.sav/se-innodb-core.xml =================================================================== --- trunk/refman-6.0.sav/se-innodb-core.xml 2009-11-06 20:39:38 UTC (rev 17510) +++ trunk/refman-6.0.sav/se-innodb-core.xml 2009-11-06 20:39:46 UTC (rev 17511) Changed blocks: 4, Lines Added: 66, Lines Deleted: 50; 8490 bytes @@ -4367,26 +4367,39 @@ <section id="innodb-backup"> - <title>Backing Up and Recovering an <literal>InnoDB</literal> Database</title> + <title>Backing Up and Recovering an <literal role="se">InnoDB</literal> + Database</title> + <indexterm> + <primary>InnoDB</primary> + <secondary>backups</secondary> + </indexterm> + + <indexterm> + <primary>backups</primary> + <secondary>InnoDB</secondary> + </indexterm> + <para> The key to safe database management is making regular backups. </para> <para> <command>InnoDB Hot Backup</command> enables you to back up a - running MySQL database, including <literal>InnoDB</literal> and - <literal>MyISAM</literal> tables, with minimal disruption to - operations while producing a consistent snapshot of the database. - When <command>InnoDB Hot Backup</command> is copying - <literal>InnoDB</literal> tables, reads and writes to both - <literal>InnoDB</literal> and <literal>MyISAM</literal> tables can - continue. During the copying of <literal>MyISAM</literal> tables, - reads (but not writes) to those tables are permitted. In addition, + running MySQL database, including + <literal role="se">InnoDB</literal> and + <literal role="se">MyISAM</literal> tables, with minimal + disruption to operations while producing a consistent snapshot of + the database. When <command>InnoDB Hot Backup</command> is copying + <literal role="se">InnoDB</literal> tables, reads and writes to + both <literal role="se">InnoDB</literal> and + <literal role="se">MyISAM</literal> tables can continue. During + the copying of <literal role="se">MyISAM</literal> tables, reads + (but not writes) to those tables are permitted. In addition, <command>InnoDB Hot Backup</command> supports creating compressed backup files, and performing backups of subsets of - <literal>InnoDB</literal> tables. In conjunction with MySQL’s - binary log, users can perform point-in-time recovery. + <literal role="se">InnoDB</literal> tables. In conjunction with + MySQL’s binary log, users can perform point-in-time recovery. <command>InnoDB Hot Backup</command> is commercially licensed by Innobase Oy. For a more complete description of <command>InnoDB Hot Backup</command>, see @@ -4400,56 +4413,51 @@ <para> If you are able to shut down your MySQL server, you can make a binary backup that consists of all files used by - <literal>InnoDB</literal> to manage its tables. Use the following - procedure: + <literal role="se">InnoDB</literal> to manage its tables. Use the + following procedure: </para> <orderedlist> <listitem> <para> - Shut down your MySQL server and make sure that it shuts down - without errors. + Shut down the MySQL server and make sure that it stops without + errors. </para> </listitem> <listitem> <para> - Copy all your data files (<filename>ibdata</filename> files - and <filename>.ibd</filename> files) into a safe place. + Copy all <literal role="se">InnoDB</literal> data files + (<filename>ibdata</filename> files and + <filename>.ibd</filename> files) into a safe place. </para> </listitem> <listitem> <para> - Copy all your <filename>ib_logfile</filename> files to a safe - place. + Copy all the <filename>.frm</filename> files for + <literal role="se">InnoDB</literal> tables to a safe place. </para> </listitem> <listitem> <para> - Copy your <filename>my.cnf</filename> configuration file or - files to a safe place. + Copy all <literal role="se">InnoDB</literal> log files + (<filename>ib_logfile</filename> files) to a safe place. </para> </listitem> <listitem> <para> - Copy all the <filename>.frm</filename> files for your - <literal>InnoDB</literal> tables to a safe place. + Copy your <filename>my.cnf</filename> configuration file or + files to a safe place. </para> </listitem> </orderedlist> <para> - Replication works with <literal>InnoDB</literal> tables, so you - can use MySQL replication capabilities to keep a copy of your - database at database sites requiring high availability. - </para> - - <para> In addition to making binary backups as just described, you should also regularly make dumps of your tables with <command>mysqldump</command>. The reason for this is that a binary @@ -4458,28 +4466,35 @@ corruption becomes easier. Also, because the format is simpler, the chance for serious data corruption is smaller. <command>mysqldump</command> also has a - <option role="mysqldump">--single-transaction</option> option that - you can use to make a consistent snapshot without locking out - other clients. See <xref linkend="backup-policy"/>. + <option role="mysqldump">--single-transaction</option> option for + making a consistent snapshot without locking out other clients. + See <xref linkend="backup-policy"/>. </para> <para> - To be able to recover your <literal>InnoDB</literal> database to - the present from the binary backup just described, you have to run - your MySQL server with binary logging turned on. To achieve - point-in-time recovery after restoring a backup, you can apply - changes from the binary log that occurred after the backup was - made. See <xref linkend="point-in-time-recovery"/>. + Replication works with <literal role="se">InnoDB</literal> tables, + so you can use MySQL replication capabilities to keep a copy of + your database at database sites requiring high availability. </para> <para> + To be able to recover your <literal role="se">InnoDB</literal> + database to the present from the time at which the binary backup + was made, you must run your MySQL server with binary logging + turned on. To achieve point-in-time recovery after restoring a + backup, you can apply changes from the binary log that occurred + after the backup was made. See + <xref linkend="point-in-time-recovery"/>. + </para> + + <para> To recover from a crash of your MySQL server, the only requirement - is to restart it. <literal>InnoDB</literal> automatically checks - the logs and performs a roll-forward of the database to the - present. <literal>InnoDB</literal> automatically rolls back - uncommitted transactions that were present at the time of the - crash. During recovery, <command>mysqld</command> displays output - something like this: + is to restart it. <literal role="se">InnoDB</literal> + automatically checks the logs and performs a roll-forward of the + database to the present. <literal role="se">InnoDB</literal> + automatically rolls back uncommitted transactions that were + present at the time of the crash. During recovery, + <command>mysqld</command> displays output something like this: </para> <programlisting> @@ -4507,12 +4522,13 @@ </programlisting> <para> - If your database gets corrupted or your disk fails, you have to do - the recovery from a backup. In the case of corruption, you should - first find a backup that is not corrupted. After restoring the - base backup, do the recovery from the binary log files using - <command>mysqlbinlog</command> and <command>mysql</command> to - restore the changes that occurred after the backup was made. + If your database becomes corrupted or disk failure occurs, you + must perform the recovery using a backup. In the case of + corruption, you should first find a backup that is not corrupted. + After restoring the base backup, do a point-in-time recovery from + the binary log files using <command>mysqlbinlog</command> and + <command>mysql</command> to restore the changes that occurred + after the backup was made. </para> <indexterm>
| Thread | ||
|---|---|---|
| • svn commit - mysqldoc@docsrva: r17511 - in trunk: . refman-4.1 refman-5.0 refman-5.1 refman-5.4 refman-5.5 refman-6.0.sav | paul.dubois | 6 Nov 2009 |
© 1995-2008 MySQL AB, 2008-2009 Sun Microsystems, Inc.
Page generated in 0.909 sec. using MySQL 5.1.14-beta-log