П О Р Т А Л                            
С Е Т Е В Ы Х                          
П Р О Е К Т О В                        
  
Поиск по сайту:
                                                 
Главная

О проекте

Web-мастеру
     HTML & JavaScript
     SSI
     Perl
     PHP
     XML & XSLT
     Unix Shell

MySQL

Безопасность

Хостинг

Другое








Самое читаемое:

Учебник PHP - "Для Чайника".
Просмотров 3525 раз(а).

Иллюстрированный самоучитель по созданию сайтов.
Просмотров 6122 раз(а).

Учебник HTML.
Просмотров 3276 раз(а).

Руководство по PHP5.
Просмотров 5499 раз(а).

Хостинг через призму DNS.
Просмотров 4150 раз(а).

Подборка текстов стандартных документов.
Просмотров 55774 раз(а).

Учебник PHP - Самоучитель
Просмотров 3093 раз(а).

Документация на MySQL (учебник & справочное руководство)
Просмотров 5763 раз(а).

Внешние атаки...
Просмотров 3843 раз(а).

Учебник PHP.
Просмотров 2826 раз(а).

SSI в примерах.
Просмотров 37463 раз(а).



 
 
| Добавить в избранное | Сделать стартовой | Помощь





Глава 4. Администрирование баз данных
Пред. След.

4.10. Репликация в MySQL
4.10.2. Как реализована репликация: обзор

Репликация в MySQL основывается на том, что все изменения базы данных (обновления, удаления и т.д.) протоколируются в двоичном журнале на сервере (see Раздел 4.9.4, «Бинарный журнал обновлений»), а подчиненный сервер читает сохраненные запросы из двоичного журнала головного сервера и выполняет эти запросы на своей копии данных.

Очень важно понимать, что двоичный журнал - это просто запись, начатая с фиксированного момента времени (с момента, когда вы включаете ведение записей в двоичном журнале). При установке каждого из подчиненных серверов нужно будет скопировать с головного сервера все данные, существовавшие на нем к моменту начала ведения записей в двоичном журнале. Если подчиненный сервер будет запущен с данными, не соответствующими тем, которые содержались на головном сервере к моменту запуска двоичного журнала, на подчиненном сервере может произойти сбой.

В следующей таблице вы найдете информацию о совместимости головных и подчиненных серверов разных версий. С учетом версии 4.0, мы рекомендуем использовать одну и ту же версию на обеих серверах, подчиненном и головном.

  ГоловнойГоловнойГоловнойГоловной
  3.23.33 и новее4.0.04.0.14.0.3 и новее
Подчиненный3.23.33 и новееданетнетнет
Подчиненный4.0.0нетданетнет
Подчиненный4.0.1данетданет
Подчиненный4.0.3 и новееданетнетда

Note: MySQL 4.0.2 не рекомендован для репликации.

Начиная с версии 4.0.0 для записи данных на подчиненный сервер можно использовать команду LOAD DATA FROM MASTER. Учтите, что команда LOAD DATA FROM MASTER в настоящее время работает только если все таблицы на головном сервере имеют тип MyISAM, и для них будет установлена глобальная блокировка чтения, чтобы не допустить никаких записей во время передачи таблиц от головного сервера к подчиненному. Данное ограничение носит временный характер. Оно обусловлено тем, что мы еще не реализовали горячее резервное копирование таблиц без блокировок. Это ограничение мы снимем для следующих ветвей версии 4.0 - как только будет реализовано горячее резервное копирование, которое позволит команде LOAD DATA FROM MASTER работать без блокирования обновлений на головном сервере.

Из-за вышеупомянутого ограничения рекомендуется использовать команду LOAD DATA FROM MASTER только в тех случаях, если набор данных на головном сервере относительно невелик или если для головного сервера допустима длительная блокировка чтения. Скорость выполнения команды LOAD DATA FROM MASTER для разных систем может быть различной, поэтому для грубой оценки времени выполнения команды можно считать, что для передачи 1 Мб данных требуется 1 секунда. Это приблизительно соответствует случаю, когда и головной, и подчиненный серверы эквивалентны Pentium с тактовой частотой 700 МГц и связаны сетью с пропускной способностью 100 Мбит/с, а размер индексного файла равен примерно половине размера файла данных. Разумеется, такая прикидка дает лишь грубую приближенную оценку и в случае каждой конкретной системы потребуются свои допущения.

После того как подчиненный сервер будут правильно сконфигурирован и запущен, он должен легко соединиться с головным сервером и ожидать обработки обновлений. Если головной сервер завершит работу или подчиненный сервер потеряет связь с головным, подчиненный сервер будет пытаться установить соединение каждый раз по истечении интервала времени, указанного в опции master-connect-retry (в секундах) до тех пор, пока не установится подсоединение и не продолжится прослушивание обновлений.

Каждый подчиненный сервер отслеживает события с момента разрыва. Головной сервер не имеет никакой информации о том, сколько существует подчиненных серверов, и какие из них обновлены последними данными в любой момент времени.

В следующем разделе процесс установки головного/подчиненного серверов рассматривается более подробно.


Пред. След.
Глава 3. Учебное пособие по MySQL  Начало  Глава 5. Оптимизация в MySQL


Если Вы не нашли что искали, то рекомендую воспользоваться поиском по сайту:
 





Copyright © 2005-2016 Project.Net.Ru