|
Задавайте вопросы, мы ответим
Вы не зашли.
На сервере стоит Windows 2003 x64 (64-х разрядная).
Стоит база данных mysql 5.01.53 64-х разрядная.
Есть таблиц логов xxxxx. Эта таблица партицирована помесячно используя LIST Partitioning на 12 партиций.
Сейчас идет 11 месяц и все данные пишутся и считываются из таблици xxxxx из партиции 11.
Если производить периодически чистку этой таблици от старых логов (например почистить логи за первый месяц Январь),
то нужно выполнить следующие действия
ALTER TABLE xxxxx DROP PARTITION mnth1;
затем
ALTER TABLE xxxxx ADD PARTITION (PARTITION mnth1 VALUES IN (1));
Вопрос: во время действий удаления и создания партиции 1 будет ли лочится вся таблица xxxxx и в том числе и текущая рабочая партиция 11 и клиенты работающие с данными за текущий 11 месяц повиснут. Или же будет залочена только неактуальная на текущий момент времени партиция 1, что не помешает работе с текущими данными в партиции 11.
Спасибо!
Неактивен
Любой DDL в MySQL блокирует всю таблицу целиком. Другое дело, что
конкретно эти операции выполняются достаточно быстро (время, необ-
ходимое для удаления и создания соответственно, файлов в ФС).
Неактивен
Пару вопросов еще:
1. Можно сразу выполнять на рабочей базе эти 2 операции
ALTER TABLE xxxxx DROP PARTITION mnth1;
затем
ALTER TABLE xxxxx ADD PARTITION (PARTITION mnth1 VALUES IN (1));
и mysql сама залочит и разлочит таблицу или нужно обязательно сначала самому залочить таблицу xxxxx, а после вышеописанных команд разлочить ее?
2. Что в таком случае будет с поступившим запросом INSERT на всавку записи(записей) в партицию 11 во время блокировки таблицы, они отвергнутся и клиенту вернется ошибка что INSERT не прошел или же INSERT дождется разблокировки таблици xxxxx и обязательно выполниться, а клиент подвиснет немного на это время?
Неактивен
1. MySQL позаботится об этом сам.
2. Запросы будут отброшены. И, видимо, никак обойти это не получится.
С другой стороны, Вы же все равно теряете эти данные.
Неактивен
....С другой стороны, Вы же все равно теряете эти данные....
Не совсем так. Сперва в базе в других таблицах производятся апдейты а затем, как результат совершенных действий (апдейтов), в таблицу логов xxxxx вставляется статистическая информация. Так вот если апдейты проходят, а в лог информация об этом не вставиться то будет не совсем хорошо.
Выходит партицирование таблиц не панацея от безболезненной(на горячую) очистки старых данных из таблицы логов.
Ранее, когда таблица была непартиционная, то отключали всех клиентов, транкейтили таблицу логов и снова запускали клиентов.
Я думал, что партицирование позволит производить очистку старых логов(старых партиций) без отключения клиентов, а выходит по сути дела что схема очистки даже одной партиции будет как и ранее - отключение клиентов, удаление и пересоздание партиции и запуск клиентов.
Выход наверное один - переходить на транзакционные таблицы. В таком случае если бы не прошел инсерт в таблицу логов то откатился бы и предыдущий апдейт данных в других таблицах.
Неактивен
Хм. Ну тогда
LOCK TABLES tablename WRITE;
ALTER TABLE tablename DROP PARTITION mnth1;
ALTER TABLE tablename ADD PARTITION ...;
UNLOCK TABLES;
Все потоки будут ждать завершения обеих задач.
Неактивен
Да, спасибо, это поможет.
буду так использовать.
Неактивен
Еще, мучающий вопрос.
если в базе на текущий момент времени выполняется INSERT в таблицу tablename
и я вручную выполняю команду LOCK TABLES tablename WRITE;
то эта блокировка дождется окончания уже начавшего(начавшихся если их было много в этот момент) свое выполнение оператора INSERT и только после этого заблокирует таблицу или же блокировка вступит в силу немедленно и приостановит или отбросит уже начавшиеся INSERT?
И интересует точно такая же формулировка вопроса, только вместо оператора INSERT, например, выпллняется долгий оператор SELECT делающий большую выборку. Как будет вышеописанный вопрос в отношении SELECT?
Неактивен
Будет ждать, разумеется — Вы же должны взять эксклюзивную блокировку.
И другие запросы, которые прийдут после того, как LOCK встанет на ожида-
ние — будут ждать, когда LOCK возьмет блокировку, а потом отпустит.
Неактивен
