Недавно я настроил репликацию master-slave для своего производства без учета всех пользовательских случаев. Я снова приступаю к рассмотрению всех возможных вариантов использования на уровне аппаратного обеспечения, чтобы убедиться, что мы будем готовы справиться со всеми сбоями.
Я не вижу лучшего подхода для приведенных ниже сценариев.
There is no space left on master to write binary logs
There is no space left on slave to write really logs
Большое спасибо за любую помощь в этом. С уважением, Удай
По сути, вы хотите обнаружить это до того, как это произойдет.
я использую контролировать с проверкой файловой системы, чтобы отправить электронное письмо, и попробовать такие базовые шаги;
check filesystem rootfs with path /dev/hda1
IF SPACE USAGE > 90 % THEN alert
IF SPACE USAGE > 95 % THEN
EXEC '/run/script/with/logrotate/and/empty/tmp/dir/while/you/read/alert/email'
Результат выполнения условия Disk FULL в mysql сильно зависит от того, как вы настроили MySQL и основную структуру разделов. По умолчанию в пакетной версии CentOS написано следующее:
logs -> /var/log/mysqld.log
binlogs -> /var/lib/mysql/mysql-bin.00NNNN
data -> /var/lib/mysql/
Однако, к сожалению, макет файловой системы по умолчанию - поместить / var / в один раздел следующим образом;
/dev/cciss/c0d0p2 on /var type ext3 (rw)
следовательно, результат переполнения диска обычно довольно дерьмовый результат с потерей данных.
Процедура сервера MySQL для работы с условием переполнения диска описана в руководстве здесь;
http://dev.mysql.com/doc/refman/5.0/en/full-disk.html
Согласно документации, если вы освободите достаточно места, она должна продолжаться;
Когда возникает состояние переполнения диска, MySQL делает следующее:
It checks once every minute to see whether there isдостаточно места для записи текущей строки. Если места достаточно, он продолжается, как ни в чем не бывало.
Every 10 minutes it writes an entry to the log file,предупреждение о переполнении диска.
Чтобы решить проблему, вы можете предпринять следующие действия:
To continue, you only have to free enough disk space to insert all records.
Однако мой опыт показывает, что к тому времени произошло слишком много сбоев, и mysqld необходимо перезапустить с потерей ожидающих транзакций.
Что касается порядка действий, то Руководство mysql для версии 5.1 имеет это говорит о том, что происходит с транзакцией при сбоях записи транзакции или бинлога;
Двоичное ведение журнала выполняется сразу после завершения оператора, но до того, как будут сняты блокировки или совершена фиксация. Это гарантирует, что журнал регистрируется в порядке выполнения.
Обновления нетранзакционных таблиц сохраняются в двоичном журнале сразу после выполнения. В MySQL 5.1.22 и более ранних версиях MySQL 5.1 оператор UPDATE, использующий хранимую функцию, которая изменяет нетранзакционную таблицу, не регистрировался в случае сбоя, а оператор INSERT ... ON DUPLICATE KEY UPDATE, который обнаружил дублирующееся ограничение ключа, но фактически не изменил никаких данных - не был зарегистрирован. Начиная с MySQL 5.1.23, оба этих оператора записываются в двоичный журнал. (Ошибка # 23333)
В незафиксированной транзакции все обновления (UPDATE, DELETE или INSERT), которые изменяют транзакционные таблицы, такие как таблицы InnoDB, кэшируются до тех пор, пока сервер не получит оператор COMMIT. В этот момент mysqld записывает всю транзакцию в двоичный журнал перед выполнением COMMIT.
Откат изменений нетранзакционных таблиц невозможен. Если откат транзакции включает изменения в нетранзакционных таблицах, вся транзакция регистрируется с оператором ROLLBACK в конце, чтобы гарантировать, что изменения в этих таблицах будут реплицированы.