Author: paul
Date: 2006-01-09 01:10:14 +0100 (Mon, 09 Jan 2006)
New Revision: 726
Log:
r5963@frost: paul | 2006-01-08 17:44:09 -0600
De-cruft.
Modified:
trunk/
trunk/refman-4.1/introduction.xml
trunk/refman-5.1/introduction.xml
trunk/refman-5.1/replication.xml
trunk/refman-common/maxdb.en.xml
Property changes on: trunk
___________________________________________________________________
Name: svk:merge
- b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:5962
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:1994
+ b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:5963
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:1994
Modified: trunk/refman-4.1/introduction.xml
===================================================================
--- trunk/refman-4.1/introduction.xml 2006-01-09 00:09:57 UTC (rev 725)
+++ trunk/refman-4.1/introduction.xml 2006-01-09 00:10:14 UTC (rev 726)
@@ -787,59 +787,60 @@
<para>
Support for a number of additional storage engines was
implemented in the MySQL 4.1 release series:
+ </para>
- <itemizedlist>
+ <itemizedlist>
- <listitem>
- <para>
- The <literal>EXAMPLE</literal> storage engine is
- a <quote>stub</quote> engine that serves as an
- example in the MySQL source code for writing new
- storage engines, and is primarily of interest to
- developers. See
- <xref linkend="example-storage-engine"/>.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ The <literal>EXAMPLE</literal> storage engine is a
+ <quote>stub</quote> engine that serves as an
+ example in the MySQL source code for writing new
+ storage engines, and is primarily of interest to
+ developers. See
+ <xref linkend="example-storage-engine"/>.
+ </para>
+ </listitem>
- <listitem>
- <para>
- <literal>NDB Cluster</literal> is the storage
- engine used by MySQL Cluster to implement tables
- that are partitioned over many computers. See
- <xref linkend="ndbcluster"/>.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ <literal>NDB Cluster</literal> is the storage
+ engine used by MySQL Cluster to implement tables
+ that are partitioned over many computers. See
+ <xref linkend="ndbcluster"/>.
+ </para>
+ </listitem>
- <listitem>
- <para>
- The <literal>ARCHIVE</literal> storage engine is
- used for storing large amounts of data without
- indexes in a very small footprint. See
- <xref linkend="archive-storage-engine"/>.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ The <literal>ARCHIVE</literal> storage engine is
+ used for storing large amounts of data without
+ indexes in a very small footprint. See
+ <xref linkend="archive-storage-engine"/>.
+ </para>
+ </listitem>
- <listitem>
- <para>
- The <literal>CSV</literal> storage engine stores
- data in text files using comma-separated-values
- format. See
- <xref linkend="csv-storage-engine"/>.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ The <literal>CSV</literal> storage engine stores
+ data in text files using comma-separated-values
+ format. See <xref linkend="csv-storage-engine"/>.
+ </para>
+ </listitem>
- <listitem>
- <para>
- The <literal>BLACKHOLE</literal> storage engine
- accepts but does not store data, and always
- returns an empty result set. It is for use
- primarily in replication. See
- <xref linkend="blackhole-storage-engine"/>.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ The <literal>BLACKHOLE</literal> storage engine
+ accepts but does not store data, and always
+ returns an empty result set. It is for use
+ primarily in replication. See
+ <xref linkend="blackhole-storage-engine"/>.
+ </para>
+ </listitem>
- </itemizedlist>
+ </itemizedlist>
+ <para>
<emphasis role="bold">Note</emphasis>: These engine
were implemented at different points in the
development of MySQL 4.1. Please see the indicated
Modified: trunk/refman-5.1/introduction.xml
===================================================================
--- trunk/refman-5.1/introduction.xml 2006-01-09 00:09:57 UTC (rev 725)
+++ trunk/refman-5.1/introduction.xml 2006-01-09 00:10:14 UTC (rev 726)
@@ -419,39 +419,39 @@
<para>
<emphasis role="bold">The Instance Manager (IM)</emphasis>
now has some additional functionality:
+ </para>
- <itemizedlist>
+ <itemizedlist>
- <listitem>
- <para>
- <literal>SHOW <replaceable>instance_name</replaceable>
- LOG FILES</literal> provides a listing of all log
- files used by the instance. (Author: Petr Chardin)
- </para>
- </listitem>
+ <listitem>
+ <para>
+ <literal>SHOW <replaceable>instance_name</replaceable>
+ LOG FILES</literal> provides a listing of all log files
+ used by the instance. (Author: Petr Chardin)
+ </para>
+ </listitem>
- <listitem>
- <para>
- <literal>SHOW <replaceable>instance_name</replaceable>
- LOG {ERROR | SLOW | GENERAL}
- <replaceable>size</replaceable></literal> retrieves a
- part of the specified log file. (Author: Petr Chardin)
- </para>
- </listitem>
+ <listitem>
+ <para>
+ <literal>SHOW <replaceable>instance_name</replaceable>
+ LOG {ERROR | SLOW | GENERAL}
+ <replaceable>size</replaceable></literal> retrieves a
+ part of the specified log file. (Author: Petr Chardin)
+ </para>
+ </listitem>
- <listitem>
- <para>
- <literal>SET
- <replaceable>instance_name</replaceable>.<replaceable>option_name</replaceable>=<replaceable>option_value</replaceable></literal>
- sets an option to the specified value and writes it to
- the config file See
- <xref linkend="instance-manager"/>, for more details
- on these new commands. (Author: Petr Chardin)
- </para>
- </listitem>
+ <listitem>
+ <para>
+ <literal>SET
+ <replaceable>instance_name</replaceable>.<replaceable>option_name</replaceable>=<replaceable>option_value</replaceable></literal>
+ sets an option to the specified value and writes it to
+ the config file See <xref linkend="instance-manager"/>,
+ for more details on these new commands. (Author: Petr
+ Chardin)
+ </para>
+ </listitem>
- </itemizedlist>
- </para>
+ </itemizedlist>
</listitem>
</itemizedlist>
Modified: trunk/refman-5.1/replication.xml
===================================================================
--- trunk/refman-5.1/replication.xml 2006-01-09 00:09:57 UTC (rev 725)
+++ trunk/refman-5.1/replication.xml 2006-01-09 00:10:14 UTC (rev 726)
@@ -94,12 +94,14 @@
row-based replication. Consider the following scenario, where a
record is inserted on the slave, followed by a statement on the
master's side that should empty the table:
+ </para>
<programlisting>
slave> INSERT INTO tbl VALUES (1);
master> DELETE FROM tbl;
</programlisting>
+ <para>
The master doesn't know about the <literal>INSERT</literal>
operation on the slave server, but with statement-based
replication, <literal>tbl</literal> will still be empty on both
@@ -267,11 +269,13 @@
to using statement-based replication. If you want to use row-based
replication instead, you have to start the MySQL server with this
option:
+ </para>
<programlisting>
--binlog-format=row
</programlisting>
+ <para>
This enables row-based replication
<emphasis>server-wide</emphasis>, and automatically turns on
<option>innodb_locks_unsafe_for_binlog</option> as it is safe in
@@ -284,17 +288,19 @@
as setting the dynamic server system variable
<literal>BINLOG_FORMAT</literal> to a value of
<literal>ROW</literal>, like this:
+ </para>
<programlisting>
mysql> <userinput>SET GLOBAL BINLOG_FORMAT = 'ROW';</userinput>
</programlisting>
+ <para>
Alternatively, you can set it to a value of <literal>2</literal>:
+ </para>
<programlisting>
mysql> <userinput>SET GLOBAL BINLOG_FORMAT = 2;</userinput>
</programlisting>
- </para>
-->
<para>
@@ -302,6 +308,7 @@
the server without the <literal>--binlog-format=row</literal>
option (statement-based replication is the default) or by
specifiying <option>--binlog-format=statement</option> explicitly.
+ </para>
<!-- Remove comment when WL#2712 is implemented
Without restarting the server, you can set the dynamic
@@ -311,13 +318,14 @@
mysql> <userinput>SET GLOBAL BINLOG_FORMAT = 'STMT';</userinput>
</programlisting>
+ <para>
Alternatively, you can set it to a value of <literal>1</literal>:
+ </para>
<programlisting>
mysql> <userinput>SET GLOBAL BINLOG_FORMAT = 1;</userinput>
</programlisting>
-->
- </para>
<para>
<!-- Remove comment when WL#2712 is implemented
@@ -339,57 +347,57 @@
Here are two reasons why you would want to set replication logging
on a per-connection basis:
+ </para>
- <itemizedlist>
+ <itemizedlist>
- <listitem>
- <para>
- A thread that does a lot of small changes to the database
- might want to use row-based logging, while a thread that
- does a lot of heavy-duty searching might want to use
- statement-based logging.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ A thread that does a lot of small changes to the database
+ might want to use row-based logging, while a thread that does
+ a lot of heavy-duty searching might want to use
+ statement-based logging.
+ </para>
+ </listitem>
- <listitem>
- <para>
- Some statements require a lot of execution on the master,
- but create a small result set. It might therefore be
- beneficial to replicated them row-based.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ Some statements require a lot of execution on the master, but
+ create a small result set. It might therefore be beneficial to
+ replicated them row-based.
+ </para>
+ </listitem>
- </itemizedlist>
- </para>
+ </itemizedlist>
<para>
Row-based replication causes <emphasis>most</emphasis> changes to
be written to the binary log using the row-based format. Some
changes, however, will still be written into the binary log as
statements:
+ </para>
- <itemizedlist>
+ <itemizedlist>
- <listitem>
- <para>
- <literal>ANALYZE</literal>
- </para>
- </listitem>
+ <listitem>
+ <para>
+ <literal>ANALYZE</literal>
+ </para>
+ </listitem>
- <listitem>
- <para>
- <literal>REPAIR</literal>
- </para>
- </listitem>
+ <listitem>
+ <para>
+ <literal>REPAIR</literal>
+ </para>
+ </listitem>
- <listitem>
- <para>
- <literal>OPTIMIZE</literal>
- </para>
- </listitem>
+ <listitem>
+ <para>
+ <literal>OPTIMIZE</literal>
+ </para>
+ </listitem>
- </itemizedlist>
- </para>
+ </itemizedlist>
<para>
There is another option you can use with row-based replication:
@@ -4228,321 +4236,319 @@
<para>
Advantages of statement-based replication are:
+ </para>
- <itemizedlist>
+ <itemizedlist>
- <listitem>
- <para>
- Proven technology (existed in MySQL since 3.23).
- </para>
- </listitem>
+ <listitem>
+ <para>
+ Proven technology (existed in MySQL since 3.23).
+ </para>
+ </listitem>
- <listitem>
- <para>
- Smaller log files (when using updates or deletes that
- affects many rows, much smaller log files). Because log
- files are smaller, they take up less storage space and are
- faster to back up.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ Smaller log files (when using updates or deletes that affects
+ many rows, much smaller log files). Because log files are
+ smaller, they take up less storage space and are faster to
+ back up.
+ </para>
+ </listitem>
- <listitem>
- <para>
- Log files contain all statements that made any changes,
- which allow them to be used to audit the database.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ Log files contain all statements that made any changes, which
+ allow them to be used to audit the database.
+ </para>
+ </listitem>
- <listitem>
- <para>
- Log files can be used for point-in-time recovery, not just
- for replication purposes. See
- <xref linkend="point-in-time-recovery"/>.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ Log files can be used for point-in-time recovery, not just for
+ replication purposes. See
+ <xref linkend="point-in-time-recovery"/>.
+ </para>
+ </listitem>
- <listitem>
- <para>
- Slave may be a newer version of MySQL with a different row
- structure.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ Slave may be a newer version of MySQL with a different row
+ structure.
+ </para>
+ </listitem>
- </itemizedlist>
- </para>
+ </itemizedlist>
<para>
Disadvantages of statement-based replication are:
+ </para>
- <itemizedlist>
+ <itemizedlist>
- <listitem>
- <para>
- Not all <literal>UPDATE</literal> statements can be
- replicated: Any non-deterministic behavior, for example when
- using random functions in an SQL statement, is hard to
- replicate when using statement-based replication. When using
- a non-deterministic user-defined function (UDF), it is not
- possible to replicate the result using statement-based
- replication, while row-based replication will just replicate
- the value returned by the UDF.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ Not all <literal>UPDATE</literal> statements can be
+ replicated: Any non-deterministic behavior, for example when
+ using random functions in an SQL statement, is hard to
+ replicate when using statement-based replication. When using a
+ non-deterministic user-defined function (UDF), it is not
+ possible to replicate the result using statement-based
+ replication, while row-based replication will just replicate
+ the value returned by the UDF.
+ </para>
+ </listitem>
- <listitem>
- <para>
- Statements that use a UDF (user defined function) which is
- non-deterministic (value depends on other things than the
- given parameters) cannot be replicated properly.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ Statements that use a UDF (user defined function) which is
+ non-deterministic (value depends on other things than the
+ given parameters) cannot be replicated properly.
+ </para>
+ </listitem>
- <listitem>
- <para>
- Statements that use one of the following functions cannot be
- replicated properly:
+ <listitem>
+ <para>
+ Statements that use one of the following functions cannot be
+ replicated properly:
+ </para>
- <itemizedlist>
+ <itemizedlist>
- <listitem>
- <para>
- <literal>LOAD_FILE()</literal>
- </para>
- </listitem>
+ <listitem>
+ <para>
+ <literal>LOAD_FILE()</literal>
+ </para>
+ </listitem>
- <listitem>
- <para>
- <literal>UUID()</literal>
- </para>
- </listitem>
+ <listitem>
+ <para>
+ <literal>UUID()</literal>
+ </para>
+ </listitem>
- <listitem>
- <para>
- <literal>USER()</literal>
- </para>
- </listitem>
+ <listitem>
+ <para>
+ <literal>USER()</literal>
+ </para>
+ </listitem>
- <listitem>
- <para>
- <literal>FOUND_ROWS()</literal>
- </para>
- </listitem>
+ <listitem>
+ <para>
+ <literal>FOUND_ROWS()</literal>
+ </para>
+ </listitem>
- </itemizedlist>
+ </itemizedlist>
- All other functions are replicated correctly (including
- <literal>RAND()</literal>, <literal>NOW()</literal>,
- <literal>LOAD DATA INFILE</literal>, an so forth).
- </para>
- </listitem>
+ <para>
+ All other functions are replicated correctly (including
+ <literal>RAND()</literal>, <literal>NOW()</literal>,
+ <literal>LOAD DATA INFILE</literal>, an so forth).
+ </para>
+ </listitem>
- <listitem>
- <para>
- <literal>INSERT … SELECT</literal> requires more
- row-level locks than with row-level replication.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ <literal>INSERT … SELECT</literal> requires more
+ row-level locks than with row-level replication.
+ </para>
+ </listitem>
- <listitem>
- <para>
- <literal>UPDATE</literal> statements that require a table
- scan (that is don't use indexes in the
- <literal>WHERE</literal> clause) have to lock more rows than
- with row-level replication.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ <literal>UPDATE</literal> statements that require a table scan
+ (that is don't use indexes in the <literal>WHERE</literal>
+ clause) have to lock more rows than with row-level
+ replication.
+ </para>
+ </listitem>
- <listitem>
- <para>
- For <literal>InnoDB</literal>: An <literal>INSERT</literal>
- statement that uses <literal>auto_increment</literal> will
- block other non-conflicting <literal>INSERT</literal>
- statements.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ For <literal>InnoDB</literal>: An <literal>INSERT</literal>
+ statement that uses <literal>auto_increment</literal> will
+ block other non-conflicting <literal>INSERT</literal>
+ statements.
+ </para>
+ </listitem>
- <listitem>
- <para>
- Slower to apply data on slave for complex queries.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ Slower to apply data on slave for complex queries.
+ </para>
+ </listitem>
- <listitem>
- <para>
- Stored functions (not stored procedures) will execute with
- the same <literal>NOW()</literal> value as the calling
- statement. (This may be regarded both as a bad and a good
- thing.)
- </para>
- </listitem>
+ <listitem>
+ <para>
+ Stored functions (not stored procedures) will execute with the
+ same <literal>NOW()</literal> value as the calling statement.
+ (This may be regarded both as a bad and a good thing.)
+ </para>
+ </listitem>
- <listitem>
- <para>
- Deterministic UDFs (user-defined functions) must be applied
- on the slaves.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ Deterministic UDFs (user-defined functions) must be applied on
+ the slaves.
+ </para>
+ </listitem>
- <listitem>
- <para>
- When getting something wrong on the slave, the difference
- between master and slave will grow with time.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ When getting something wrong on the slave, the difference
+ between master and slave will grow with time.
+ </para>
+ </listitem>
- <listitem>
- <para>
- Tables have to be (almost) identical on master and slave.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ Tables have to be (almost) identical on master and slave.
+ </para>
+ </listitem>
- </itemizedlist>
- </para>
+ </itemizedlist>
<para>
Advantages of row-level replication are:
+ </para>
- <itemizedlist>
+ <itemizedlist>
- <listitem>
- <para>
- Everything can be replicated; safest form of replication.
- Note that currently, DDL (data definition language)
- statements such as <literal>CREATE TABLE</literal> are
- replicated using statement-based replication, while DML
- (data manipulation language) statements, as well as
- <literal>GRANT</literal> and <literal>REVOKE</literal>
- statements, are replicated using row-based-replication. For
- statements like <literal>CREATE … SELECT</literal>, a
- <literal>CREATE</literal> statement is generated from the
- table definition and replicated statement-based, while the
- row insertions are replicated row-based.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ Everything can be replicated; safest form of replication. Note
+ that currently, DDL (data definition language) statements such
+ as <literal>CREATE TABLE</literal> are replicated using
+ statement-based replication, while DML (data manipulation
+ language) statements, as well as <literal>GRANT</literal> and
+ <literal>REVOKE</literal> statements, are replicated using
+ row-based-replication. For statements like <literal>CREATE
+ … SELECT</literal>, a <literal>CREATE</literal>
+ statement is generated from the table definition and
+ replicated statement-based, while the row insertions are
+ replicated row-based.
+ </para>
+ </listitem>
- <listitem>
- <para>
- Same technology as most other database management systems
- (easier to explain to database administrators used to other
- systems).
- </para>
- </listitem>
+ <listitem>
+ <para>
+ Same technology as most other database management systems
+ (easier to explain to database administrators used to other
+ systems).
+ </para>
+ </listitem>
- <listitem>
- <para>
- In many cases, faster to apply data on the slave on tables
- with primary keys.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ In many cases, faster to apply data on the slave on tables
+ with primary keys.
+ </para>
+ </listitem>
- <listitem>
- <para>
- Less locks needed (thus higher concurrency) on the master
- for:
+ <listitem>
+ <para>
+ Less locks needed (thus higher concurrency) on the master for:
+ </para>
- <itemizedlist>
+ <itemizedlist>
- <listitem>
- <para>
- <literal>INSERT … SELECT</literal>
- </para>
- </listitem>
+ <listitem>
+ <para>
+ <literal>INSERT … SELECT</literal>
+ </para>
+ </listitem>
- <listitem>
- <para>
- <literal>INSERT</literal> statements with
- <literal>auto_increment</literal>
- </para>
- </listitem>
+ <listitem>
+ <para>
+ <literal>INSERT</literal> statements with
+ <literal>auto_increment</literal>
+ </para>
+ </listitem>
- <listitem>
- <para>
- <literal>UPDATE</literal> or <literal>DELETE</literal>
- statements with <literal>WHERE</literal> clauses that
- don't use keys or don't change most of the examined
- rows.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ <literal>UPDATE</literal> or <literal>DELETE</literal>
+ statements with <literal>WHERE</literal> clauses that
+ don't use keys or don't change most of the examined rows.
+ </para>
+ </listitem>
- </itemizedlist>
- </para>
- </listitem>
+ </itemizedlist>
+ </listitem>
- <listitem>
- <para>
- Less locks on the slave for any <literal>INSERT</literal>,
- <literal>UPDATE</literal>, or <literal>DELETE</literal>
- statement.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ Less locks on the slave for any <literal>INSERT</literal>,
+ <literal>UPDATE</literal>, or <literal>DELETE</literal>
+ statement.
+ </para>
+ </listitem>
- <listitem>
- <para>
- It's possible to add multiple threads to apply data on the
- slave in the future (works better on SMP machines).
- </para>
- </listitem>
+ <listitem>
+ <para>
+ It's possible to add multiple threads to apply data on the
+ slave in the future (works better on SMP machines).
+ </para>
+ </listitem>
- </itemizedlist>
- </para>
+ </itemizedlist>
<para>
Disadvantages of row-level replication are:
+ </para>
- <itemizedlist>
+ <itemizedlist>
- <listitem>
- <para>
- Bigger log files (much bigger in some cases).
- </para>
- </listitem>
+ <listitem>
+ <para>
+ Bigger log files (much bigger in some cases).
+ </para>
+ </listitem>
- <listitem>
- <para>
- Binary log will contain data for large statements that were
- rolled back.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ Binary log will contain data for large statements that were
+ rolled back.
+ </para>
+ </listitem>
- <listitem>
- <para>
- When using row-based replication to replicate a statement
- (for example, an <literal>UPDATE</literal> or
- <literal>DELETE</literal> statement), each changed row has
- to be written to the binary log. In contrast, when using
- statement-based replication only the statement is written to
- the binary log. If the statement changes a lot of rows,
- row-based replication may write significantly more data to
- the binary log. In these cases the binary log will be locked
- for longer times to write the data, which may cause
- concurrency problems.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ When using row-based replication to replicate a statement (for
+ example, an <literal>UPDATE</literal> or
+ <literal>DELETE</literal> statement), each changed row has to
+ be written to the binary log. In contrast, when using
+ statement-based replication only the statement is written to
+ the binary log. If the statement changes a lot of rows,
+ row-based replication may write significantly more data to the
+ binary log. In these cases the binary log will be locked for
+ longer times to write the data, which may cause concurrency
+ problems.
+ </para>
+ </listitem>
- <listitem>
- <para>
- Deterministic UDFs that generate big
- <literal>BLOB</literal>s will be notably slower to
- replicate.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ Deterministic UDFs that generate big <literal>BLOB</literal>s
+ will be notably slower to replicate.
+ </para>
+ </listitem>
- <listitem>
- <para>
- One can't examine the logs to see what statements were
- executed.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ One can't examine the logs to see what statements were
+ executed.
+ </para>
+ </listitem>
- <listitem>
- <para>
- One can't see on the slave what statements were received
- from the master and executed.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ One can't see on the slave what statements were received from
+ the master and executed.
+ </para>
+ </listitem>
- </itemizedlist>
- </para>
+ </itemizedlist>
<section id="replication-problems">
Modified: trunk/refman-common/maxdb.en.xml
===================================================================
--- trunk/refman-common/maxdb.en.xml 2006-01-09 00:09:57 UTC (rev 725)
+++ trunk/refman-common/maxdb.en.xml 2006-01-09 00:10:14 UTC (rev 726)
@@ -160,52 +160,51 @@
meet the needs of installations in OLTP and Data
Warehouse/OLAP/Decision Support scenarios and offers these
benefits:
+ </para>
- <itemizedlist>
+ <itemizedlist>
- <listitem>
- <para>
- <emphasis role="bold">Easy configuration and
- administration:</emphasis> GUI-based Installation Manager
- and Database Manager as single administration tools for DBMS
- operations
- </para>
- </listitem>
+ <listitem>
+ <para>
+ <emphasis role="bold">Easy configuration and
+ administration:</emphasis> GUI-based Installation Manager and
+ Database Manager as single administration tools for DBMS
+ operations
+ </para>
+ </listitem>
- <listitem>
- <para>
- <emphasis role="bold">Around-the-clock operation, no planned
- downtimes, no permanent attendance required:</emphasis>
- Automatic space management, no need for reorganizations
- </para>
- </listitem>
+ <listitem>
+ <para>
+ <emphasis role="bold">Around-the-clock operation, no planned
+ downtimes, no permanent attendance required:</emphasis>
+ Automatic space management, no need for reorganizations
+ </para>
+ </listitem>
- <listitem>
- <para>
- <emphasis role="bold">Sophisticated backup and restore
- capabilities:</emphasis> Online and incremental backups,
- recovery wizard to guide you through the recovery scenario
- </para>
- </listitem>
+ <listitem>
+ <para>
+ <emphasis role="bold">Sophisticated backup and restore
+ capabilities:</emphasis> Online and incremental backups,
+ recovery wizard to guide you through the recovery scenario
+ </para>
+ </listitem>
- <listitem>
- <para>
- <emphasis role="bold">Supports large number of users,
- database sizes in the terabytes, and demanding
- workloads:</emphasis> Proven reliability, performance, and
- scalability
- </para>
- </listitem>
+ <listitem>
+ <para>
+ <emphasis role="bold">Supports large number of users, database
+ sizes in the terabytes, and demanding workloads:</emphasis>
+ Proven reliability, performance, and scalability
+ </para>
+ </listitem>
- <listitem>
- <para>
- <emphasis role="bold">High availability:</emphasis> Cluster
- support, standby configuration, hot standby configuration
- </para>
- </listitem>
+ <listitem>
+ <para>
+ <emphasis role="bold">High availability:</emphasis> Cluster
+ support, standby configuration, hot standby configuration
+ </para>
+ </listitem>
- </itemizedlist>
- </para>
+ </itemizedlist>
</section>
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r726 - in trunk: . refman-4.1 refman-5.1 refman-common | paul | 9 Jan |
