| List: | Commits | « Previous MessageNext Message » | |
| From: | mcbrown | Date: | February 7 2007 11:26am |
| Subject: | svn commit - mysqldoc@docsrva: r4836 - branches/repupdate/5.1 | ||
| View as plain text | |||
Author: mcbrown Date: 2007-02-07 11:26:07 +0100 (Wed, 07 Feb 2007) New Revision: 4836 Log: Committing a final version before I merge back in to the main tree. Modified: branches/repupdate/5.1/replication-configuration.xml branches/repupdate/5.1/replication-implementation.xml branches/repupdate/5.1/replication-notes.xml branches/repupdate/5.1/replication-solutions.xml Modified: branches/repupdate/5.1/replication-configuration.xml =================================================================== --- branches/repupdate/5.1/replication-configuration.xml 2007-02-06 23:55:31 UTC (rev 4835) +++ branches/repupdate/5.1/replication-configuration.xml 2007-02-07 10:26:07 UTC (rev 4836) Changed blocks: 12, Lines Added: 23, Lines Deleted: 29; 5178 bytes @@ -109,7 +109,7 @@ <section id="replication-howto"> - <title>How to Set Up Replication [TODO:Check]</title> + <title>How to Set Up Replication</title> <para> This section describes how to set up complete replication of a @@ -214,25 +214,16 @@ slaves before replication starts, have not previously configured the binary log and are able to shutdown your MySQL server for a short period during the process, see - <xref linkend="replication-howto-existingdata"/>. - </para> + <xref linkend="replication-howto-existingdata"/>.</para> </listitem> - + <listitem> <para> - If you are already running a MySQL server, have binary logging - enabled and would like to avoid shutting down your MySQL - server during the process, see - <xref linkend="replication-howto-existingdata-noshutdown"/>. - </para> - </listitem> - - <listitem> - <para> - If you already have a recent snapshot of your data, or you are - setting up additional slaves, see + If you you are + setting up additional slaves to an existing replication environment + then you can setup the slaves without affecting the master. See <xref - linkend="replication-howto-additional-slaves"/>. + linkend="replication-howto-additionalslaves"/>. </para> </listitem> @@ -269,9 +260,10 @@ <para> You do not need to create a specific user for replication. However, you should be aware that the username and password will - be stored in plain text within the <literal>master.info</literal> - file. Therefore you may want to create a user that only has - privileges for the replication process. + be stored in plain text within the + <literal>master.info</literal> file. Therefore you may want to + create a user that only has privileges for the replication + process. </para> <para> @@ -407,9 +399,11 @@ replication to be enabled. However, if you enable binary logging on the slave then you can use the binary log for data backups and crash recovery on the slave, and also use the slave as part - of a more complex replication topology. For more information, + of a more complex replication topology. + + <!--For more information, see <xref - linkend="replication-topology"/>. + linkend="replication-topology"/>.--> </para> </section> @@ -534,7 +528,7 @@ <section id="replication-howto-mysqldump"> - <title>Creating a Data Snapshot using <literal>mysqldump</literal> [TODO:Check]</title> + <title>Creating a Data Snapshot using <literal>mysqldump</literal></title> <para> One way to create a snapshot of the data in an existing master @@ -615,7 +609,7 @@ <section id="replication-howto-rawdata"> - <title>Creating a Data Snapshot Using Raw Data Files[TODO:Check]</title> + <title>Creating a Data Snapshot Using Raw Data Files</title> <para> If your database is particularly large then copying the raw data @@ -800,7 +794,7 @@ <section id="replication-howto-newservers"> - <title>Setting up Replication with new Master and Slaves[TODO:Check]</title> + <title>Setting up Replication with new Master and Slaves</title> <para> Setting up replication with a new Master and Slaves (i.e. with @@ -901,7 +895,7 @@ <section id="replication-howto-existingdata"> - <title>Setting up replication with existing data[TODO:Check]</title> + <title>Setting up replication with existing data</title> <para> When setting up replication with existing data, you will need to @@ -1113,7 +1107,7 @@ <section id="replication-howto-additionalslaves"> <title>Introducing Additional Slaves to an Existing Replication - Environment[TODO:Check]</title> + Environment</title> <para> If you want to add another slave to the existing replication @@ -1181,7 +1175,7 @@ <section id="replication-howto-slaveinit"> - <title>Setting the Master Configuration on the Slave [TODO:Check]</title> + <title>Setting the Master Configuration on the Slave</title> <para> To setup the slave to communicate with the master for @@ -1236,7 +1230,7 @@ <section id="replication-formats"> - <title>Replication Formats[TODO:Check]</title> + <title>Replication Formats</title> <para> Replication works because events written to the binary log are @@ -3296,7 +3290,7 @@ <section id="replication-administration"> - <title>Common Replication Administration Tasks[TODO:Check]</title> + <title>Common Replication Administration Tasks</title> <para> Once replication has been started it should execute without Modified: branches/repupdate/5.1/replication-implementation.xml =================================================================== --- branches/repupdate/5.1/replication-implementation.xml 2007-02-06 23:55:31 UTC (rev 4835) +++ branches/repupdate/5.1/replication-implementation.xml 2007-02-07 10:26:07 UTC (rev 4836) Changed blocks: 1, Lines Added: 1, Lines Deleted: 1; 542 bytes @@ -11,7 +11,7 @@ ]> <section id="replication-implementation"> - <title>Replication Implementation[TODO:Check]</title> + <title>Replication Implementation</title> <indexterm> <primary>replication implementation</primary> Modified: branches/repupdate/5.1/replication-notes.xml =================================================================== --- branches/repupdate/5.1/replication-notes.xml 2007-02-06 23:55:31 UTC (rev 4835) +++ branches/repupdate/5.1/replication-notes.xml 2007-02-07 10:26:07 UTC (rev 4836) Changed blocks: 2, Lines Added: 2, Lines Deleted: 4; 1095 bytes @@ -81,8 +81,7 @@ these issues by using MySQL's row-based replication instead. For a detailed list of issues, see <xref linkend="stored-procedure-logging"/>. For a description of - row-based replication, see - <xref linkend="replication-formats"/>. + row-based replication, see <xref linkend="replication-formats"/>. </para> <section id="replication-features-autoincid"> @@ -946,8 +945,7 @@ Downgrading a replication setup to a previous version cannot be done once you've switched from statement-based to row-based replication, and after the first row-based statement has been - written to the binlog. See - <xref linkend="replication-formats"/>. + written to the binlog. See <xref linkend="replication-formats"/>. </para> </section> Modified: branches/repupdate/5.1/replication-solutions.xml =================================================================== --- branches/repupdate/5.1/replication-solutions.xml 2007-02-06 23:55:31 UTC (rev 4835) +++ branches/repupdate/5.1/replication-solutions.xml 2007-02-07 10:26:07 UTC (rev 4836) Changed blocks: 13, Lines Added: 155, Lines Deleted: 24; 10594 bytes @@ -70,15 +70,15 @@ <section id="replication-solutions-backups"> - <title>Using Replication for Backups[TODO:Complete]</title> + <title>Using Replication for Backups</title> <para> You can use replication as a backup solution by replicating data - from the master to a slave, and then backing up the slave. Because - the slave can be paused and shutdown without affecting the running - operation of the master you can produce an effective snapshot of - 'live' data that would otherwise require a shutdown of the master - database. + from the master to a slave, and then backing up the data slave. + Because the slave can be paused and shutdown without affecting the + running operation of the master you can produce an effective + snapshot of 'live' data that would otherwise require a shutdown of + the master database. </para> <para> @@ -112,8 +112,86 @@ <title>Backing up using <literal>mysqldump</literal></title> - <para></para> + <para> + Using <command>mysqldump</command> to create a copy of the + database enables you to capture all of the data in the database + in a format that allows the information to be imported into + another instance of MySQL. Because the format of the information + is SQL statements the file can easily be distributed and applied + to running servers in the event that you need access to the data + in an emergency. However, if the size of your data set is very + large then <command>mysqldump</command> may be impractical. + </para> + <para> + When using <command>mysqldump</command> you should stop the + slave before starting the dump process to ensure that the dump + contains a consistent set of data: + </para> + + <orderedlist> + + <listitem> + <para> + Stop the slave from processing requests. You can either stop + the slave completely using <command>mysqladmin</command>: + </para> + +<programlisting>shell> mysqladmin stop-slave</programlisting> + + <para> + Alternatively, you can stop processing the relay log files + by stopping the replication SQL thread. Using this method + will allow the binary log data to be transferred. Within + busy replication environments this may speed up the catch-up + process when you start the slave processing again: + </para> + +<programlisting>shell> mysql -e 'STOP SLAVE SQL_THREAD;'</programlisting> + </listitem> + + <listitem> + <para> + Run <command>mysqldump</command> to dump your databases. You + may either select databases to be dumped, or dump all + databases. For more information see + <xref + linkend="mysqldump"/>. For example, to dump all + databases: + </para> + +<programlisting>shell> mysqldump --all-databases >fulldb.dump</programlisting> + </listitem> + + <listitem> + <para> + Once the dump has completed, start slave operations again: + </para> + +<programlisting>shell> mysqladmin start-slave</programlisting> + </listitem> + + </orderedlist> + + <para> + In the above example you may want to add login credentials + (username, password) to the commands, and bundle the process up + into a script that you can run automatically each day. + </para> + + <para> + If you use this approach, make sure you monitor the slave + replication process to ensure that the time taken to run the + backup in this way is not affecting the slaves ability to keep + up with events from the master. See + <xref linkend="replication-administration-status"/>. If the + slave is unable to keep up you may want to add another server + and distribute the backup process. For an example of how to + configure this scenario, see + <xref + linkend="replication-solutions-partitioning"/>. + </para> + </section> <section id="replication-solutions-backups-rawdata"> @@ -122,16 +200,69 @@ <para> Backing up the raw data files on your MySQL replication slave + should take place while your slave server is shutdown to + guarantee the integrity of the files that are copied. If the + MySQL server is still running then background tasks, + particularly with storage engines with background processes such + as InnoDB, may still be updating the database files. With + InnoDB, these problems should be resolved during crash recovery, + but since the slave server can be shutdown during the backup + process without affecting the execution of the master it makes + sense to take advantage of this facility. </para> <para> - <emphasis role="bold">What to backup:</emphasis> + To shutdown the server and backup the files: </para> + <orderedlist> + + <listitem> + <para> + Shutdown the slave MySQL server: + </para> + +<programlisting>shell> mysqladmin shutdown</programlisting> + </listitem> + + <listitem> + <para> + Copy the data files. You can use any suitable copying or + archive utility, including <command>cp</command>, + <command>tar</command> or <command>WinZip</command>: + </para> + +<programlisting>tar cf /tmp/dbbackup.tar ./data</programlisting> + </listitem> + + <listitem> + <para> + Start up the <command>mysqld</command> process again: + </para> + +<programlisting>shell> mysqld_safe &</programlisting> + + <para> + Under Windows: + </para> + +<programlisting>C:\> "C:\Program Files\MySQL\MySQL Server 5.1\bin\mysqld"</programlisting> + </listitem> + + </orderedlist> + <para> - When you back up the slave's data, you should back up these two - status files as well, along with the relay log files. They are - needed to resume replication after you restore the slave's data. + Normally you should back up the entire data folder for the slave + MySQL server. If you want to be able to restore the data and + operate as a slave (for example, in the event of failure of the + slave), then when you back up the slave's data, you should back + up the slave status files, <filename>master.info</filename> and + <filename>relay.info</filename>, along with the relay log files. + These files are needed to resume replication after you restore + the slave's data. + </para> + + <para> If you lose the relay logs but still have the <filename>relay-log.info</filename> file, you can check it to determine how far the SQL thread has executed in the master @@ -162,7 +293,7 @@ <section id="replication-solutions-diffengines"> <title>Using Replication with different Master and Slave Storage - Engines[TODO:Check]</title> + Engines</title> <para> The replication process does not care if the source table on the @@ -247,7 +378,7 @@ Stop the slave from running replication updates: </para> -<programlisting>shell> stop slave;</programlisting> +<programlisting>mysql> STOP SLAVE;</programlisting> <para> This will enable you to change engine types without @@ -268,7 +399,7 @@ Start the slave replication process again: </para> -<programlisting>shell> start slave;</programlisting> +<programlisting>mysql> START SLAVE;</programlisting> </listitem> </orderedlist> @@ -279,10 +410,10 @@ aware that <literal>CREATE TABLE</literal> and <literal>ALTER TABLE</literal> statements that include the engine specification will be correctly replicated to the slave. For example, if you - have a CSV table, <literal>csvtablea</literal>, and you execute: + have a CSV table and you execute: </para> -<programlisting>shell> ALTER TABLE csvtable Engine='MyISAM';</programlisting> +<programlisting>mysql> ALTER TABLE csvtable Engine='MyISAM';</programlisting> <para> The above statement will be replicated to the slave and the engine @@ -294,14 +425,14 @@ creating a new table. For example, instead of: </para> -<programlisting>shell> CREATE TABLE tablea (columna int) Engine=MyISAM;</programlisting> +<programlisting>mysql> CREATE TABLE tablea (columna int) Engine=MyISAM;</programlisting> <para> Use this format: </para> -<programlisting>shell> SET storage_engine=MyISAM; -shell> CREATE TABLE tablea (columna int);</programlisting> +<programlisting>mysql> SET storage_engine=MyISAM; +mysql> CREATE TABLE tablea (columna int);</programlisting> <para> When replicated, the <literal>storage_engine</literal> variable @@ -313,7 +444,7 @@ <section id="replication-solutions-scaleout"> - <title>Using Replication for Scale-out[TODO:Check]</title> + <title>Using Replication for Scale-out</title> <para> You can use replication as a scale-out solution, i.e. where you @@ -429,7 +560,7 @@ <section id="replication-solutions-partitioning"> - <title>Replicating Different Databases to Different Slaves[TODO:Check]</title> + <title>Replicating Different Databases to Different Slaves</title> <remark role="todo"> [MC] Source for this input was Bug #23615 @@ -548,7 +679,7 @@ <section id="replication-solutions-performance"> - <title>Improving Replication Performance[TODO:Check]</title> + <title>Improving Replication Performance</title> <para> As the number of slaves connecting to a master increases, the @@ -689,7 +820,7 @@ <section id="replication-solutions-switch"> - <title>Switching Masters During Failover[TODO:Check]</title> + <title>Switching Masters During Failover</title> <para> There is currently no official solution for providing failover @@ -1000,7 +1131,7 @@ replication process: </para> -<programlisting>shell> start slave;</programlisting> +<programlisting>mysql> START SLAVE;</programlisting> <para> You can use the <literal>SHOW SLAVE STATUS</literal> to confirm
| Thread | ||
|---|---|---|
| • svn commit - mysqldoc@docsrva: r4836 - branches/repupdate/5.1 | mcbrown | 7 Feb |
© 1995-2008 MySQL AB, 2008-2009 Sun Microsystems, Inc.
Page generated in 0.503 sec. using MySQL 5.1.14-beta-log