SpirirHost Support Centre: MySQL Reference Manual p.313

<< previous page -- table of contents -- next page >>

Chapter_1

Chapter_2

Chapter_3

Chapter_4

Chapter_5

Return to Table of Contents

Table of Contents
1. General Information
2. MySQL Installation
3. Tutorial Introduction
4. Database Administration
5. MySQL Optimisation
6. MySQL Language Reference
7. MySQL Table Types
8. MySQL APIs
9. Extending MySQL

Chapter 4: Database Administration 313 master. The extra speed is achieved by sending a part of the non-updating queries to the replica server. Of course this only works if non-updating queries dominate, but that is the normal case. Starting in Version 3.23.15, MySQL supports one-way replication internally. One server acts as the master, while the other acts as the slave. Note that one server could play the roles of master in one pair and slave in the other. The master server keeps a binary log of updates (see Section 4.9.4 [Binary log], page 310) and an index le to binary logs to keep track of log rotation. The slave, upon connecting, informs the master where it left o since the last successfully propagated update, catches up on the updates, and then blocks and waits for the master to notify it of the new updates. Note that if you are replicating a database, all updates to this database should be done through the master! Another benet of using replication is that one can get live backups of the system by doing a backup on a slave instead of doing it on the master. See Section 4.4.1 [Backup], page 227. 4.10.2 Replication Implementation Overview MySQL replication is based on the server keeping track of all changes to your database (updates, deletes, etc) in the binary log (see Section 4.9.4 [Binary log], page 310) and the slave server(s) reading the saved queries from the master server's binary log so that the slave can execute the same queries on its copy of the data. It is very important to realise that the binary log is simply a record starting from a xed point in time (the moment you enable binary logging). Any slaves which you set up will need copies of all the data from your master as it existed the moment that you enabled binary logging on the master. If you start your slaves with data that doesn't agree with what was on the master when the binary log was started, your slaves may fail. Please see the following table for an indication of master-slave compatibility between dif- ferent versions. With regard to version 4.0, we recommend using same version on both sides. Master Master Master Master 3.23.33 and up 4.0.0 4.0.1 4.0.2 Slave 3.23.33 and up yes no no no Slave 4.0.0 no yes no no Slave 4.0.1 yes no yes no Slave 4.0.2 yes no no yes Starting from 4.0.0, one can use LOAD DATA FROM MASTER to set up a slave. Be aware that LOAD DATA FROM MASTER currently works only if all the tables on the master are MyISAM type, and will acquire a global read lock, so no writes are possible while the tables are being transferred from the master. This limitation is of a temporary nature, and is due to the fact that we have not yet implemented hot lock-free table backup. It will be removed in the future 4.0 branch versions once we implemented hot backup enabling LOAD DATA FROM MASTER to work without blocking master updates.

MySQL Reference Manual

Home
Hosting Plans \| Domain Registration \| About Us \| Contact Us \| Site Map Terms of Use \| Privacy Policy \| Guarantees Merchant Accounts

SpiritHost - web hosting for spiritual and education sites SpiritHit.com - Religious and Spiritual Portal Copyright © 2002 Dyntex Group, Inc. All Rights Reserved

Return to Table of Contents	Back to top

Web Hosting: Manuals & FAQ's

1. Unix-Based Web Hosting
2. Unix Dedicated Servers
3. Windows Dedicated Servers
4. CuteFTP User’s Guide
5. CuteHTML User’s Guide
6. WS_FTP Pro User's Guide
7. Miva Order User's Guide
8. Miva Merchant User's Guide