resolved conflicts

* CHECK TABLE::                 @code{CHECK TABLE} syntax

* ANALYZE TABLE::               @code{ANALYZE TABLE} syntax

* REPAIR TABLE::                @code{REPAIR TABLE} syntax

* BACKUP TABLE::                @code{BACKUP TABLE} syntax

* RESTORE TABLE::               @code{RESTORE TABLE} syntax

* DELETE::                      @code{DELETE} syntax

* SELECT::                      @code{SELECT} syntax

* JOIN::                        @code{JOIN} syntax

* Replication Features::        Replication Features

* Replication Options::         Replication Options in my.cnf

* Replication SQL::             SQL Commands related to replication

* Replication FAQ::             Frequently asked questions about replication

Getting maximum performance from MySQL

* CHECK TABLE::                 @code{CHECK TABLE} syntax

* ANALYZE TABLE::               @code{ANALYZE TABLE} syntax

* REPAIR TABLE::                @code{REPAIR TABLE} syntax

* BACKUP TABLE::                @code{BACKUP TABLE} syntax

* RESTORE TABLE::               @code{RESTORE TABLE} syntax

* DELETE::                      @code{DELETE} syntax

* SELECT::                      @code{SELECT} syntax

* JOIN::                        @code{JOIN} syntax

@item @code{EXTENDED} @tab Do a full key lookup for all keys for each row.  This ensures that the table is 100 % consistent, but will take a long time!

@end multitable

@findex BACKUP TABLE

@node BACKUP TABLE,  RESTORE TABLE, CHECK TABLE, Reference

@section @code{BACKUP TABLE} syntax

@example

BACKUP TABLE tbl_name[,tbl_name...] TO '/path/to/backup/directory'

@end example

Make a copy of all the table files to the backup directory that are the

minimum needed to restore it. Currenlty only works for @code{MyISAM}

tables. For @code{MyISAM} table, copies @code{.frm} (definition)  and

 @code{.MYD} (data) files. The index file can be rebuilt from those two.

During the backup, read lock will be held for each table, one at time,

as they are being backed up. If you want to backup several tables as

a snapshot, you must first issue @code{LOCK TABLES} obtaining a read

lock for each table in the group.

The command returns a table with the following columns:

@multitable @columnfractions .35 .65

@item @strong{Column} @tab @strong{Value}

@item Table @tab Table name

@item Op @tab Always ``backup''

@item Msg_type @tab One of @code{status}, @code{error}, @code{info} or @code{warning}.

@item Msg_text @tab The message.

@end multitable

@findex RESTORE TABLE

@node RESTORE TABLE, ANALYZE TABLE, BACKUP TABLE, Reference

@section @code{RESTORE TABLE} syntax

@example

RESTORE TABLE tbl_name[,tbl_name...] FROM '/path/to/backup/directory'

@end example

Restores the table(s) from the backup that was made with 

@code{BACKUP TABLE}. Existing tables will not be overwritten - if you

try to restore over an existing table, you will get an error. Restore

will take  longer than BACKUP due to the need to rebuilt the index. The

more keys you have, the longer it is going to take. Just as 

@code{BACKUP TABLE}, currently only works of @code{MyISAM} tables.

The command returns a table with the following columns:

@multitable @columnfractions .35 .65

@item @strong{Column} @tab @strong{Value}

@item Table @tab Table name

@item Op @tab Always ``restore''

@item Msg_type @tab One of @code{status}, @code{error}, @code{info} or @code{warning}.

@item Msg_text @tab The message.

@end multitable

@findex ANALYZE TABLE

@node ANALYZE TABLE, REPAIR TABLE, CHECK TABLE, Reference

@node ANALYZE TABLE, REPAIR TABLE, RESTORE TABLE, Reference

@section @code{ANALYZE TABLE} syntax

@example

* Replication Features::        Replication Features

* Replication Options::         Replication Options in my.cnf

* Replication SQL::             SQL Commands related to replication

* Replication FAQ::             Frequently Asked Questions about replication

@end menu

@node Replication Intro, Replication Implementation, Replication, Replication

@end multitable

@node Replication SQL,  , Replication Options, Replication

@node Replication SQL, Replication FAQ, Replication Options, Replication

@section SQL commands related to replication

Replication can be controlled through the SQL interface. Below is the

@end multitable

@node Replication FAQ, , Replication SQL, Replication 

@section Replication FAQ

@strong{Q}: Why do I sometimes see more than one @code{Binlog_Dump} thread on

the master after I have restarted the slave?

@strong{A}: @code{Binlog_Dump} is a continuous process that is handled by the

server the following way:

@itemize

@item

catch up on the updates

@item

once there are no more updates left, go into @code{pthread_cond_wait()},

from which we can be woken up either by an update or a kill

@item 

on wake up, check the reason, if we are not supposed to die, continue

the @code{Binlog_dump} loop

@item

if there is some fatal error, such as detecting a dead client, 

terminate the loop

@end itemize

So if the slave thread stops on the slave, the corresponding 

@code{Binlog_Dump} thread on the master will not notice it until after

at least one update to the master ( or a kill), which is needed to wake

it up from @code{pthread_cond_wait()}.  In the meantime, the slave 

could have opened another connection, which resulted in another 

@code{Binlog_Dump} thread.

Once we add @strong{server_id} variable for each server that 

participates in replication, we will fix @code{Binlog_Dump} thread to

kill all the zombies from the same slave on reconnect.

@strong{Q}: What issues should I be aware of when setting up two-way

replication?

@strong{A}: @strong{MySQL} replication currently does not support any

locking protocol between master and slave to guarantee the atomicity of

a distributed ( cross-server) update. In in other words, it is possible

for client A to make an update to  co-master 1, and in the meantime, 

before it propogates to co-master 2, client B could make an update to

co-master 2 that will make the update of client A work differently than

it did on co-master 1. Thus when the update of client A will make it

to co-master 2, it will produce  tables that will be different than 

what you have on co-master 1, even after all the updates from co-master

2 have also propogated. So you should not co-chain two servers in a

two-way replication relationship, unless you are sure that you updates

can safely happen in any order, or unless you take care of mis-ordered

updates somehow in the client code.

Until we implement @code{server_id} variable, you cannot have more than

two servers in a co-master replication relationship, and you must 

run @code{mysqld} without @code{log-slave-updates} (default) to avoid

infinite update loops.

You must also realize that two-way replication actually does not improve

performance very much, if at all, as far as updates are concerned. Both

servers need to do the same amount of updates each, as you would have 

one server do. The only difference is that there will be a little less

lock contention, because the updates originating on another server will

be serialized in one slave thread. This benefit, though, might be 

offset by network delays.

@strong{Q}: How can I use replication to improve performance of my system?

@strong{A}: You should set up one server as the master, and direct all

writes to it, and configure as many slaves as you have the money and

rackspace for, distributing the reads among the master and the slaves.

@strong{Q}: What should I do to prepare my client code to use 

performance-enhancing replication?

@strong{A}: 

If the part of your code that is responsible for database access has

been properly abstracted/modularized, converting it to run with the

replicated setup should be very smooth and easy - just change the 

implementation of your database access to read from some slave or the

master, and to awlays write to the master. If your code does not have

this level of abstraction,

setting up a replicated system will give you an opportunity/motivation 

to it clean up. 

 You should start by creating a wrapper library

/module with the following functions:

@itemize

@item

@code{safe_writer_connect()}

@item

@code{safe_reader_connect()}

@item

@code{safe_reader_query()}

@item

@code{safe_writer_query()}

@end itemize

@code{safe_} means that the function will take care of handling all

the error conditions. 

You should then convert your client code to use the wrapper library.

It may be a painful and scary process at first, but it will pay off in

the long run. All application that follow the above pattern will be

able to take advantage of one-master/many slaves solution.  The 

code will be a lot easier to maintain, and adding troubleshooting 

options will be trivial - you will just need to modify one or two

functions, for example, to log how long each query took, or which

query, among your many thousands, gave you an error. If you have written a lot of code already,

you may want to automate the conversion task by using Monty's 

@code{replace} utility, which comes with the standard distribution of 

@strong{MySQL}, or just write your own Perl script. Hopefully, your

code follows some recognizable pattern. If not, then you are probably

better off re-writing it anyway, or at least going through and manually

beating it into a pattern.

Note that, of course, you can use different names for the

functions. What is important is having unified interface for connecting

for reads, connecting for writes, doing a read, and doing a write. 

@strong{Q}: When and how much can @code{MySQL} replication improve the performance

of my system?

@strong{A}: @strong{MySQL} replication is most benefitial for a system

with frequent reads and not so frequent writes. In theory, by using a

one master/many slaves setup you can scale by adding more slaves until

you either run out of network bandwidth, or your update 

load grows to the point

that the master cannot handle it. 

In order to determine how many slaves you can get before the added

benefits begin to level out, and how much you can improve performance

of your site, you need to know your query patterns, and empirically

 (by benchmarking) determine the relationship between the throughput

on reads ( reads per second, or @code{max_reads}) and on writes 

@code{max_writes}) on a typical master and a typical slave. The

example below will show you a rather simplified calculation of what you

can get with replication for our imagined system.

Let's say our system load consist of 10% writes and 90% reads, and we

have determined that @code{max_reads} = 1200 - 2 * @code{max_writes},

or in other words, our system can do 1200 reads per second with no

writes, our average write is twice as slow as average read, 

and the relationship is 

linear. Let us suppose that our master and slave are of the same

capacity, and we have N slaves and 1 master. Then we have for each

server ( master or slave):

@code{reads = 1200 - 2 * writes} ( from bencmarks)

@code{reads = 9* writes / (N + 1) } ( reads split, but writes go

to all servers)

@code{9*writes/(N+1) + 2 * writes = 1200}

@code{writes = 1200/(2 + 9/(N+1)}

So if N = 0, which means we have no replication, our system can handle

1200/11, about 109 writes per second ( which means we will have 9 times

as many reads to to the nature of our application) 

If N = 1, we can get up to 184 writes per second

If N = 8, we get up to 400

If N = 17, 480 writes

Eventually as N approaches infinity ( and our budget negative infinity),

we can get very close to 600 writes per second, increasing system

throughput about 5.5 times. However, with only 8 servers, we increased

it almost 4 times already. 

Note that our computations assumed infitine network bandwidth, and 

neglected several other factors that could turn out to be signficant on

your system. In many cases, you may not be able to make a computation

similar to the one above that will accurately predict what will happen

on your system if you add N replication slaves. However, answering the

following questions should help you decided whether and how much if at

all the replication will improve the performance of your system:

@itemize

@item

What is the read/write ratio on your system?

@item

How much more write load can one server handle if you reduce the reads?

@item

How many slaves do you have bandwidth for on your network?

@end itemize

@strong{Q}: How can I use replication to provide redundancy/high 

availability?

@strong{A}: With the currently available features, you would have to

set up a master and a slave (or several slaves), and write a script 

that will monitor the

master to see if it is up, and instruct your applications and 

the slaves of the master change in case of failure. Some suggestions:

@itemize

@item

To tell a slave to change the master use @code{CHANGE MASTER TO} command

@item 

A good way to keep your applications informed where the master is is by

having a dynamic DNS entry for the master. With @strong{bind} you can

use @code{nsupdate} to dynamically update your DNS

@item

You should run your slaves with @code{log-bin} option and without

@code{log-slave-updates}. This way the slave will be ready to become a

master as soon as you issue @code{STOP SLAVE}; @code{FLUSH MASTER}, and

@code{CHANGE MASTER TO} on the other slaves. It will also help you catch

spurious updates that may happen because of misconfiguration of the 

slave ( ideally, you want to configure access rights so that no client

can update the slave, except for the slave thread) combined with the

bugs in your client programs ( they should never update the slave 

directly). 

@end itemize

We are currently working on intergrating an automatic master election

system into @strong{MySQL}, but until it is ready, you will have to

create your own monitoring tools .

@cindex Performance

@cindex Optimization

@node Performance, MySQL Benchmarks, Replication, Top

@item

Implement function: @code{get_changed_tables(timeout,table1,table2,...)}

@item

Atomic updates; This includes a language that one can even use for

a set of stored procedures.

@item

@code{update items,month set items.price=month.price where items.id=month.id;}

Atomic multi-table updates, eg @code{update items,month set 

items.price=month.price where items.id=month.id;}; 

@item

Change reading through tables to use memmap when possible. Now only

compressed tables use memmap.

@item

Add full support for @code{JOIN} with parentheses.

@item

Reuse threads for systems with a lot of connections.

@item

As an alternative for one thread / connection manage a pool of threads

to handle the queries.

@item

  HA_CHECK_OPT   check_opt;			// check/repair options

  HA_CREATE_INFO create_info;

  LEX_MASTER_INFO mi;				// used by CHANGE MASTER

  char* backup_dir;                             // used by RESTORE/BACKUP

  ulong thread_id,type;

  ulong options;

  enum_sql_command sql_command;