| List: | Commits | « Previous MessageNext Message » | |
| From: | stefan | Date: | August 3 2007 7:46pm |
| Subject: | svn commit - mysqldoc@docsrva: r7326 - in trunk: refman-5.0 refman-common | ||
| View as plain text | |||
Author: shinz Date: 2007-08-03 19:46:46 +0200 (Fri, 03 Aug 2007) New Revision: 7326 Log: Reviewed ha.xml, fixed some typos in replication-drbd.xml Modified: trunk/refman-5.0/ha.xml trunk/refman-common/replication-drbd.xml Modified: trunk/refman-5.0/ha.xml =================================================================== --- trunk/refman-5.0/ha.xml 2007-08-03 17:20:48 UTC (rev 7325) +++ trunk/refman-5.0/ha.xml 2007-08-03 17:46:46 UTC (rev 7326) Changed blocks: 15, Lines Added: 126, Lines Deleted: 76; 15212 bytes @@ -7,39 +7,42 @@ ]> <chapter id="ha-overview"> - <title>High Availability, Scalability and DRBD</title> + <title>High Availability, Scalability, and DRBD</title> <para> - When using MySQL you may need to ensure the availability or scalability of - your MySQL installation. Availability refers to the ability to cope with, - and if necessary recover from, failures on the host, including failures of - MySQL, the operating system or the hardware. Scalability refers to the - ability to spread the load of your application queries across multiple - MySQL servers. As your application and usage increases, you may need to - spread the queries for the application across multiple servers to improve - response times. + When using MySQL you may need to ensure the availability or + scalability of your MySQL installation. Availability refers to the + ability to cope with, and if necessary recover from, failures on the + host, including failures of MySQL, the operating system, or the + hardware. Scalability refers to the ability to spread the load of + your application queries across multiple MySQL servers. As your + application and usage increases, you may need to spread the queries + for the application across multiple servers to improve response + times. </para> + <para> - There are a number of solutions available for - solving issues of availability and scalability. There are two - primary solutions supported by MySQL, MySQL Replication and MySQL - Cluster. Further options are available using third-party solutions - such as DRBD and Heartbeat, and more complex scenarios can be solved - through a combination of these technologies. These different tools - work in different ways: + There are a number of solutions available for solving issues of + availability and scalability. The two primary solutions supported by + MySQL are MySQL Replication and MySQL Cluster. Further options are + available using third-party solutions such as DRBD (Distributed + Replicated Block Device) and Heartbeat, and more complex scenarios + can be solved through a combination of these technologies. These + tools work in different ways: </para> <itemizedlist> <listitem> <para> - MySQL Replication enables statements and data from one MySQL - server instance to be replicated to another MySQL server - instance. Without using more complex setups, data can only be - replicated from a single master server to any number of slaves. - The replication is asynchronous, so the synchronization does not - take place in real time, and there is no guarantee that data from - the master will have been replicated to the slaves. + <emphasis>MySQL Replication</emphasis> enables statements and + data from one MySQL server instance to be replicated to another + MySQL server instance. Without using more complex setups, data + can only be replicated from a single master server to any number + of slaves. The replication is asynchronous, so the + synchronization does not take place in real time, and there is + no guarantee that data from the master will have been replicated + to the slaves. </para> <itemizedlist> @@ -52,9 +55,9 @@ <listitem> <para> - Supported by all platforms supported by MySQL, and - replication is not either OS specific, so it can operate - across different platforms. + MySQL Replication is available on all platforms supported by + MySQL, and since it isn't operating system-specific it can + operate across different platforms. </para> </listitem> @@ -72,7 +75,7 @@ Data can be replicated from one master to any number of slaves, making replication suitable in environments with heavy reads, but light writes (for example, many web - applications) by spreading the load across multiple slaves. + applications), by spreading the load across multiple slaves. </para> </listitem> @@ -85,7 +88,7 @@ <listitem> <para> Data can only be written to the master. In advanced - configurations you can set up a multiple master + configurations, though, you can set up a multiple-master configuration where the data is replicated around a ring configuration. </para> @@ -95,6 +98,10 @@ <para> There is no guarantee that data on master and slaves will be consistent. + + <remark> + [SH] "... at a given point in time" I'd suggest to add. + </remark> </para> </listitem> @@ -103,6 +110,13 @@ Because replication is asynchronous there may be a small delay between data being written to the master and it being available on the slaves. + + <remark> + [SH] This sounds like the previous item (no guarantee...). + Also, the delay may be big if slaves attach to the network + only from time to time (e.g. replicating to laptop + computers). + </remark> </para> </listitem> @@ -115,7 +129,7 @@ <listitem> <para> Scale-out solutions that require a large number of reads but - fewer writes (i.e. web serving). + fewer writes (for example, web serving). </para> </listitem> @@ -129,7 +143,7 @@ <listitem> <para> - Online-backup (availability), where you need an active copy + Online backup (availability), where you need an active copy of the data available. You need to combine this with other tools, such as custom scripts or Heartbeat. However, because of the asynchronous architecture, the data may be @@ -143,25 +157,31 @@ the data. You can take the slave down and get a reliable snapshot of the data (without MySQL running), then restart MySQL and replication to catch up. + + <remark> + [SH] This doesn't make it clear if you're talking about + the master or the slave (it's the master that needs to be + stopped I guess). + </remark> </para> </listitem> </itemizedlist> <para> - For more information on setting up and configuring replication, - see <xref + For information on setting up and configuring replication, see + <xref linkend="replication"/>. </para> </listitem> <listitem> <para> - MySQL Cluster is a synchronous solution that enables multiple - MySQL instances to share database information. Unlike - replication, data in a cluster can be read from or written to - any node within the cluster, and information will be distributed - to the other nodes. + <emphasis>MySQL Cluster</emphasis> is a synchronous solution + that enables multiple MySQL instances to share database + information. Unlike replication, data in a cluster can be read + from or written to any node within the cluster, and information + will be distributed to the other nodes. </para> <itemizedlist> @@ -238,28 +258,30 @@ </itemizedlist> <para> - For more information on MySQL Cluster, see + For information on MySQL Cluster, see <xref linkend="mysql-cluster"/>. </para> </listitem> <listitem> <para> - DRBD is third party solution from Linbit supported only on - Linux. DRBD creates a virtual block device (which is associated - with an underlying physical block device) that can be replicated - from the primary server to a secondary server. You create a + <emphasis>DRBD (Distributed Replicated Block Device)</emphasis> + is a third-party solution from Linbit supported only on Linux. + DRBD creates a virtual block device (which is associated with an + underlying physical block device) that can be replicated from + the primary server to a secondary server. You create a filesystem on the virtual block device, and this information is then replicated, at the block level, to the secondary server. </para> <para> Because the block device, not the data you are storing on it, is - being replicated the validity of the information is more reliable - than with data-only replication solutions. DRBD can also ensure - data integrity by only returning from a write operation on the - primary server when the data has been written to the underlying - physical block device on both the primary and secondary servers. + being replicated the validity of the information is more + reliable than with data-only replication solutions. DRBD can + also ensure data integrity by only returning from a write + operation on the primary server when the data has been written + to the underlying physical block device on both the primary and + secondary servers. </para> <itemizedlist> @@ -301,8 +323,8 @@ <listitem> <para> - Cannot provide scalability, since secondary nodes will do - not have access to the secondary data. + Cannot provide scalability, since secondary nodes don't have + access to the secondary data. </para> </listitem> @@ -323,26 +345,32 @@ </itemizedlist> <para> - For more information on configuring DRBD and configuring MySQL - for use with a DRBD device, see - <xref linkend="replication-drbd"/>. + For information on configuring DRBD and configuring MySQL for + use with a DRBD device, see <xref linkend="replication-drbd"/>. </para> </listitem> <listitem> <para> - Heartbeat is not a data replication solution, but a solution for - monitoring servers and switching active MySQL servers - automatically in the event of failure. Heartbeat needs to be - combined with MySQL Replication or DRBD to provide automatic - failover. + <emphasis>Heartbeat</emphasis> is not a data replication + solution, but a solution for monitoring servers and switching + active MySQL servers automatically in the event of failure. + Heartbeat needs to be combined with MySQL Replication or DRBD to + provide automatic failover. + + <remark> + [SH] I'm still wondering what Heartbeat is - a third-party + software? + </remark> </para> </listitem> </itemizedlist> -<para>The information and suitability of the various technologies and different - scenarios is summarized in the table below. </para> + <para> + The information and suitability of the various technologies and + different scenarios is summarized in the table below. + </para> <informaltable> <tgroup cols="5"> @@ -365,35 +393,48 @@ <entry><emphasis role="bold">Availability</emphasis></entry> </row> <row> - <entry>Automated IP Fail-Over</entry> + <entry>Automated IP failover</entry> <entry>No</entry> <entry>Yes</entry> <entry>Yes</entry> <entry>No</entry> </row> <row> - <entry>Automated DB Fail-Over</entry> + <entry>Automated database + + <remark> + [SH] Or does that have to be "DB"? + </remark> + + failover</entry> <entry>No</entry> <entry>No</entry> <entry>Yes</entry> <entry>Yes</entry> </row> <row> - <entry>Typical Fail-Over Time</entry> - <entry>User/Script dependent</entry> + <entry>Typical failover time</entry> + <entry>User/script-dependent</entry> <entry>Varies</entry> - <entry>< 30 secs</entry> - <entry>< 3 secs</entry> + <entry>< 30 seconds</entry> + <entry>< 3 seconds</entry> </row> <row> - <entry>Auto Resynch of Data</entry> + <entry>Automatic resynchronization + + <remark> + [SH] This was "auto resync" which sounded too geeky to me + :-) + </remark> + + of data</entry> <entry>No</entry> <entry>No</entry> <entry>Yes</entry> <entry>Yes</entry> </row> <row> - <entry>Geographic Redundancy Support</entry> + <entry>Geographic redundancy support</entry> <entry>Yes</entry> <entry>Yes</entry> <entry>Yes, when combined with MySQL Replication</entry> @@ -403,35 +444,45 @@ <entry><emphasis role="bold">Scalability</emphasis></entry> </row> <row> - <entry>Built-in Load Balancing</entry> + <entry>Built-in load balancing</entry> <entry>No</entry> <entry>No</entry> <entry>No</entry> <entry>Yes</entry> </row> <row> - <entry>Read Intensive</entry> + <entry><remark> + [SH] This could be misleading: read-intensive = for + read-intensive uses, or rather the setup would be + read-intensive? Same for the write-intensive below. + </remark> + + Read-intensive</entry> <entry>Yes</entry> <entry>Yes</entry> <entry>Yes, when combined with MySQL Replication</entry> <entry>Yes</entry> </row> <row> - <entry>Write Intensive</entry> + <entry>Write-intensive</entry> <entry>No</entry> <entry>No</entry> <entry>Yes</entry> <entry>Yes</entry> </row> <row> - <entry>Max # nodes per group</entry> - <entry>One Master, multiple slaves</entry> - <entry>One Master, multiple slaves</entry> - <entry>One Active (Primary), Multiple Passive (Secondary)</entry> + <entry>Maximum number of nodes per group</entry> + <entry>One master, multiple slaves</entry> + <entry>One master, multiple slaves</entry> + <entry>One active (primary), multiple passive (secondary) + + <remark> + [SH] I'm missing a noun here + </remark></entry> <entry>255</entry> </row> <row> - <entry>Max # of slaves</entry> + <entry>Maximum number of slaves</entry> <entry>Unlimited (reads only)</entry> <entry>Unlimited (reads only)</entry> <entry>Unlimited (reads only)</entry> @@ -442,6 +493,5 @@ </informaltable> <xi:include href="../refman-common/replication-drbd.xml" xmlns:xi="http://www.w3.org/2001/XInclude"/> - </chapter> Modified: trunk/refman-common/replication-drbd.xml =================================================================== --- trunk/refman-common/replication-drbd.xml 2007-08-03 17:20:48 UTC (rev 7325) +++ trunk/refman-common/replication-drbd.xml 2007-08-03 17:46:46 UTC (rev 7326) Changed blocks: 15, Lines Added: 16, Lines Deleted: 16; 6178 bytes @@ -28,7 +28,7 @@ <para> On the primary, for example, the data writes are written both to the underlying physical block device and distributed to the secondary - DRBD services. On the secondariess, the writes received through DRBD + DRBD services. On the secondary, the writes received through DRBD and written to the local physical block device. On both the primary and the secondary, reads from the DRBD block device are handled by the underlying physical block device. The information is shared @@ -107,7 +107,7 @@ <para> Before starting the installation process, you should be aware of - the following information, termas and requirements on using DRBD: + the following information, terms and requirements on using DRBD: </para> <itemizedlist> @@ -234,7 +234,7 @@ <listitem> <para> Once DRBD has been configured, you must alter the - configuration and storage locationof the MySQL data. See + configuration and storage location of the MySQL data. See <xref linkend="replication-drbd-install-mysql"/>. </para> @@ -336,7 +336,7 @@ Ideally the partitions that will be used on each node should be of an identical size, although this is not strictly necessary. Do, however, ensure that the physical partition - on the DRBD secondary is at least as big as the partitionon + on the DRBD secondary is at least as big as the partitions on the DRBD primary node. </para> </listitem> @@ -436,7 +436,7 @@ <listitem> <para> - <emphasis role="bold">Tips for RedHat (including CentOS and + <emphasis role="bold">Tips for Red Hat (including CentOS and Fedora)</emphasis>: </para> @@ -450,7 +450,7 @@ <para> Reboot. If you are going to build DRBD from source, then - update your system with the required development pacakges + update your system with the required development packages </para> <programlisting># up2date glib-devel openssl-devel libgcrypt-devel glib2-devel \ @@ -549,7 +549,7 @@ <para> If you are installing using a binary distribution then you must - ensure that the kernl version number of the binary package + ensure that the kernel version number of the binary package matches your currently active kernel. You can use <command>uname</command> to find out this information: </para> @@ -619,7 +619,7 @@ </para> <para> - The key elements to configurare are the <literal>on</literal> + The key elements to configure are the <literal>on</literal> sections which specify the configuration of each node. </para> @@ -637,9 +637,9 @@ Set the synchronization rate between the two nodes. You should keep this in check compared to the speed of your network connection. Gigabit Ethernet can support up to 125 - megabytes/sec, 100Mbps Ethernet slightly less than a tenth + MB/second, 100Mbps Ethernet slightly less than a tenth of that (12MBps). If you are using a shared network - connection, rather than a dedicated, then you should guage + connection, rather than a dedicated, then you should gauge accordingly. </para> @@ -702,7 +702,7 @@ <listitem> <para> <literal>meta-disk</literal> — the location - where the meta-data about the DRBD device will be + where the metadata about the DRBD device will be stored. You can set this to <literal>internal</literal> and DRBD will use the physical block device to store the information, by @@ -935,7 +935,7 @@ <listitem> <para> - ld — local data consistentency + ld — local data consistency </para> </listitem> @@ -1064,7 +1064,7 @@ <para> <literal>protocol</literal> — specifies the level of consistency to be used when information is written to the - block device. The option is similar in priciple to the + block device. The option is similar in principle to the <link linkend="option_mysqld_innodb_flush_log_at_trx_commit"><literal>innodb_flush_log_at_trx_commit</literal></link> option within MySQL. Three levels are supported: @@ -1103,7 +1103,7 @@ </itemizedlist> <para> - The preferreed and recommended protocol is C, as it is the + The preferred and recommended protocol is C, as it is the only protocol which ensures the consistency of the local and remote physical storage. </para> @@ -1116,7 +1116,7 @@ block device. Suitable values include <literal>panic</literal>, which causes the node to leave the DRBD cluster by causing a kernel panic (and which - would trigger automatic fail-over if you were using + would trigger automatic failover if you were using Heartbeat); and <literal>detach</literal>, which switches DRBD into a diskless mode (i.e. data is not written to the lower level block device). @@ -1130,7 +1130,7 @@ then you can specify the size of the DRBD device to be created. The size specification can include a quantifier. For example, to set the maximum size of the DRBD partition - to 1 Gigabyte you would use: + to 1GB you would use: </para> <programlisting>size 1G;</programlisting>
| Thread | ||
|---|---|---|
| • svn commit - mysqldoc@docsrva: r7326 - in trunk: refman-5.0 refman-common | stefan | 3 Aug |
© 1995-2008 MySQL AB, 2008-2009 Sun Microsystems, Inc.
Page generated in 0.701 sec. using MySQL 5.1.14-beta-log