Предупреждение. Ако не сте запознати с репликация в MySQL, че е малко вероятно да се реализира нещо от nizhenapisannogo, първо трябва да прочетете документацията за репликацията и мулти-сървър MySQL план на същия компютър.
Prelude. Отне ми да организира двупосочна репликация база данни MySQL и две сървъри, работещи на същата машина (за да заобиколят заключване MyISAM-таблици). Тя ще изглежда, нищо сложно, и не е специален, предвид факта, че аз знам как да работите с множество MySQL-сървър на същата машина, и как да се организира репликацията на данни между две различни машини. Но задачата не е много лесно. Аз няма да кажа как цял ден се бори с довереник като се опитаха стартиране възможности и т.н. но просто пиша за клопките:
№1 капан. Имам MySQL Опции майстор-домакин, майстор-порт, но не и настройка майстор-гнездо, така че когато написах първия сървър
майстор-домакин = Localhost
майстор-порт = 3307,
той не се вкопчи в 127.0.0.1:3307 и да /tmp/mysql.sock, т.е. за себе си, а не на втория сървър. И в информацията в дневника за това къде той наистина се е вкопчил случайно се оказа, само когато отидох там много nahimichil.
Прескачането на проблема - пише майстор-домакин = 127.0.0.1.
№2 капан. Дори prosle как смених my.cnf майстор-домакин на 127.0.0.1, системата не работи пука. Тук причината е, че опцията е майстор-домакин и някои други параметри за репликация се чете от главния довереник само ако нещо не е наред с master.info файла (тя автоматично се създава в директорията на данни), например, той просто отсъства, и ако съществува, мастер-домакин се прочете и сложи на сървъра, че аз го променя до my.cnf. Документирането на това твърдение, но аз го намери, след като узнае от експеримент ... че е необходимо да го маркирате с удебелен червен, дявол да го вземе.
Байпас на този проблем - промените ръчно, или, че е по-лесно да се премахне master.info, не забравяйте да се спре MySQL сървър, преди да. Когато изтриете изгубена оперативна INFA репликация - текущия лог файл - така че трябва да бъдете внимателни, по-сигурно още редактиране.
Какво в крайна сметка се е случило. Ето едно парче на my.cnf, позовавайки се на случая, с които тя работи добре (версия MySQL 4.0.18):
################
# MySQL сървър 1
[Mysqld1]
порт = 3306
гнездо = /tmp/mysql.sock
DataDir = / данни / mysql1
PID-файл = /data/mysql1/mysqld.pid
потребител = MySQL
# репликация
влезте бин
сървъра номер = 1
binlog задачи-db = тест
майстор-домакин = 127.0.0.1
майстор-порт = 3307
майстор потребител = репликатор
майстор-Connect-повторен опит = 10
репликира задачи-db = тест
################
################
# MySQL сървър 2
[Mysqld2]
порт = 3307
гнездо = /tmp/mysql2.sock
DataDir = / данни / mysql2
PID-файл = /data/mysql2/mysqld.pid
потребител = MySQL
# репликация
влезте бин
сървъра номер = 2
binlog задачи-db = тест
майстор-домакин = Localhost
майстор-порт = 3306
майстор потребител = репликатор
майстор-Connect-повторен опит = 10
репликира задачи-db = тест
################
На първия сървър трябва да направите:
Дарение REPLICATION роб * * ДА Replicator @ Localhost .;
вторият:
Дарение REPLICATION роб * * ДА [email protected] .;
За производителността (вместо заключение). Както можете да видите, за втори сървър напуснах майстор-домакин = Localhost, е съвсем оправдано, защото той ще бъде свързан към /tmp/mysql.sock, т.е. на първия сървър, а ние сме там и ние трябва. Изглежда, че е като споделянето чрез UNIX домейн около два пъти по-бързо, отколкото чрез мрежа гнезда. Малко вероятно е, че тя може значително да повлияе на функционирането на репликация, особено след като в повечето случаи се осъществява между две различни машини по мрежата. Но въпреки това ме обърква е, че разработчиците не предполагат, MySQL репликация събитие на един компютър и не осъзнават, създаването майстор-контакта.
Свързани статии