Dashboard > СУБД > Home > MySQL, гипотетическая кластеризация поверх drbd+ocfs2 > Просмотр
  СУБД Вход | Зарегистрироваться   Вариант для печати.  
  MySQL, гипотетическая кластеризация поверх drbd+ocfs2
Добавил(а) shixaro, последний раз редактировал(а) shixaro Sep 16, 2011  (посмотреть изменения)
Метки: 

Теория: кластеризация между узлами mysql, как правило, осуществляется собственными средствами данной СУБД, как то - обменом бинарными журналами. По той же технологии, кстати, работает и PostgreSQL (межузловой обмен WAL). DRBD в техническом плане представляет собой raid1 поверх TCP/IP. Есть все основания попробовать использовать поверх оного OCFS2 в качестве кластерной ФС. Это разные уровни и здесь drbd можно вполне заменить на mdadm (софтовый локальный рейд), если убрать кластерную, межмашинную составляющую. OCFS2 берет на себя разруливание всех блокировок в условиях межмашинного доступа к хранилищу. Поэтому есть все основания полагать, что два экземпляра MySQL с настройками "из коробки" должны адекватно работать с сетевым рейдом, базирующимся на drbd+ocfs2. Один из подводных камней тут - InnoDB (один файл и в него должны писать сразу минимум два узла). Для начала можно обкатать и MyISAM.

Практика:
Развернуто два абсолютно идентичных OpenVZ контейнера на разных узлах с дебианом и MySQL 5.0.51 из репозитория. К обоим контейнерам монтируется одна и та же директория, обслуживаемая хранилищем drbd+ocfs2.

На первой ноде создана тестовая база данных mytest.
Смотрим что у нас на второй ноде:

mysql> use mytest;
Database changed
mysql> show tables;
Empty set (0.00 sec)

Таблиц пока нет. Импортируем на первой ноде таблицу t с миллионом записей и четырьями индексами (один индекс на столбец).

root@mysql0:~# mysql -pghjcnjq mytest < ./t.sql 

На второй ноде:

mysql> show tables;
Empty set (0.00 sec)

mysql> show tables;

 Tables_in_mytest 

t                
1 row in set (1.65 sec)

Выборка всех записей из таблицы на второй ноде:

1000000 rows in set (0.36 sec)

Обновляем половину таблицы на второй ноде:

mysql> update t set a=a-100000 limit 500000;
Query OK, 500000 rows affected (6.77 sec)
Rows matched: 500000  Changed: 500000  Warnings: 0

Выбираем таблицу на первой ноде:

1000000 rows in set (0.48 sec)

Удваиваем объем таблицы на первой ноде:

mysql> insert into t select * from t;
Query OK, 1000000 rows affected (1 min 18.01 sec)
Records: 1000000  Duplicates: 0  Warnings: 0

mysql> select count(*) from t;
+----------+
| count(*) |
+----------+
|  2000000 | 
+----------+
1 row in set (0.00 sec)

На второй ноде:

mysql> select count(*) from t;
+----------+
| count(*) |
+----------+
|  2000000 | 
+----------+
1 row in set (0.00 sec)
mysql> delete from t limit 999999; 
Query OK, 999999 rows affected (8.35 sec)

mysql> select count(*) from t;
+----------+
| count(*) |
+----------+
|        1 | 
+----------+
1 row in set (0.00 sec)


mysql> select * from t;
+----------+----------+----------+----------+
| a        | b        | c        | d        |
+----------+----------+----------+----------+
| 11000000 | 21000000 | 31000000 | 41000000 | 
+----------+----------+----------+----------+
1 row in set (0.41 sec)

В итоге, вторая нода не подхватила ничего.

Изучаем ситуацию на первой ноде после операций перезаписи таблицы на второй:

mysql> select * from t;
ERROR 1194 (HY000): Table 't' is marked as crashed and should be repaired

Решение нежизнеспособно. Возможно, нужно инициировать повторное чтение мускулем файлов БД. Что выходит за рамки допустимых "производственных потерь", так как подобные дополнения к транзакциям будут подразумевать корректирование всех приложений, работающих с кластеризованным узлом MySQL.

Powered by Atlassian Confluence, the Enterprise Wiki. (Version: 2.5 Build:#805 Apr 26, 2007) - Запрос Bug/feature - Связаться с администраторами