Попередження. Якщо Ви не знайомі з реплікацією в mysql, то навряд чи зрозумієте що-небудь з ніженапісанное, Вам слід спершу ознайомитися з документацією по реплікації і по запуску кількох серверів mysql на одному комп'ютері.
Прелюдія. Знадобилося мені організувати двосторонню реплікацію БД на двох mysql-серверах, запущених на одній машині (для обходу блокування myisam-таблиць). Здавалося б нічого складного і особливого тут немає, зважаючи на те, що я знаю як запускати кілька mysql-серверів на одній машині і як організувати реплікацію БД між двома різними машинами. Але завдання виявилося не найпростішим. Не буду розповідати, як протягом цілого дня бився з конфіга, скільки варіантів запуску перепробував і т.д. а просто напишу про підводні камені:
Підводний камінь №1. У mysql є параметри master-host, master-port, але немає параметра master-socket, тому коли я для першого сервера написав
master-host = localhost
master-port = 3307,
він чіплявся ні до 127.0.0.1:3307, а до /tmp/mysql.sock, тобто до самого себе, а не до другого сервера. Причому в логах інформація про те, куди він насправді чіпляється випадково з'явилася тільки коли я там сильно нахімічив.
Обхід цієї проблеми - написати master-host = 127.0.0.1.
Підводний камінь №2. Навіть простежити того, як я в my.cnf змінив master-host на 127.0.0.1, система ні хрена не заробила. Тут причина в тому, що виявляється параметр master-host і деякі інші параметри реплікації зчитуються з основного конфіга тільки в тому випадку, якщо щось не в порядку з файлом master.info (він створюється автоматично в каталозі даних), наприклад, він просто відсутня, а якщо він існує, то master-host зчитується звідти, і сервера покласти, що я там поміняв в my.cnf. У документації про це сказано, але я це знайшов уже після того, як сам з'ясував шляхом експерименту ... треба було виділити це червоним жирним шрифтом, блін.
Обхід цієї проблеми - відредагувати вручну, або, що простіше, видалити master.info, не забувши перед цим зупинити сервер mysql. При видаленні загубиться оперативна інфа по реплікації - поточний файл журналу - так що треба бути обережним, безпечніше все ж відредагувати.
Що в підсумку вийшло. Ось шматок my.cnf, що відноситься до справи, з яким все працює чудово (версія mysql 4.0.18):
################
# MySQL server 1
[Mysqld1]
port = 3306
socket = /tmp/mysql.sock
datadir = / data / mysql1
pid-file = /data/mysql1/mysqld.pid
user = mysql
# replication
log-bin
server-id = 1
binlog-do-db = test
master-host = 127.0.0.1
master-port = 3307
master-user = replicator
master-connect-retry = 10
replicate-do-db = test
################
################
# MySQL server 2
[Mysqld2]
port = 3307
socket = /tmp/mysql2.sock
datadir = / data / mysql2
pid-file = /data/mysql2/mysqld.pid
user = mysql
# replication
log-bin
server-id = 2
binlog-do-db = test
master-host = localhost
master-port = 3306
master-user = replicator
master-connect-retry = 10
replicate-do-db = test
################
На першому сервері слід зробити:
GRANT REPLICATION SLAVE ON *. * TO replicator @ localhost;
на другому:
GRANT REPLICATION SLAVE ON *. * TO [email protected];
Про продуктивності (замість висновку). Як бачите, для другого сервера я залишив master-host = localhost, це цілком правомірно, тому що він буде з'єднуватися з /tmp/mysql.sock, тобто до першого сервера, а нам туди і треба. Начебто як обмін через unix domain близько двох разів швидше, ніж через мережеві сокети. Навряд чи це може сильно вплинути на продуктивність реплікації, тим більше, що в більшості випадків вона реалізується між двома різними машинами через мережу. Але незважаючи на це бентежить те, що розробники mysql не допустити випадку реплікації на одному комп'ютері і не реалізували параметр master-socket.