Инструкция по архивированию таблиц списаний

Для версий UTM с 5.2.1-007 по 5.3-002 включительно. Инструкция для более ранних версий находится в архиве.

Внимание! Перед выполнением любых действий с БД UTM5 в обязательном порядке следует сделать полную резервную копию БД UTM5 и проверить возможность восстановления данных из этой резервной копии. Дальнейший текст предназначен только для тех, кто понимает, что делает, и имеет достаточный уровень технических знаний в области работы с СУБД. Вопросы касательно способов манипуляции данными средствами СУБД останутся без ответа по существу, в том числе и если они будут заданы в hotline. Перед проведением любых действий рекомендуется отработать их на стендовой машине

Архивирование применяется к определённым наиболее быстро растущим таблицам с целью снизить накладные расходы на операции вставки. В ходе архивирования таблица переносится (переименовывается) в архивную, и одновременно создаётся пустая (текущая) таблица с первоначальным названием и с той же структурой для вновь поступающих данных. Операция может применяться периодически по мере роста таблиц. Ограничения описаны ниже.

  1. В настоящий момент механизм архивирования распространяет свое действие на таблицы, перечисленные ниже:
    ТаблицаТипНазвание поля даты
    discount_transactions_all1discount_date
    discount_transactions_iptraffic_all2discount_date
    tel_sessions_log3recv_date
    tel_sessions_detail4 
    dhs_sessions_log5recv_date
    dhs_sessions_detail6 
    payment_transactions7payment_enter_date
    user_log8date
    dhcp_leases_log9updated
    invoices10invoice_date
    invoice_entry11 
    invoice_entry_details12 
  2. Транзакции списаний за трафик являются подмножеством транзакций изменения балансов лицевых счетов, поэтому записи в указанных выше таблицах связаны. Если для записи в таблице discount_transactions_all установлен service_type, равный 3, то должна существовать запись с таким же id, discount_date и discount в таблице discount_transactions_iptraffic_all. Невыполнение данного условия считается нарушением логической целостности БД.
  3. Начиная со сборки 5.2.1-006, существует таблица archives со следующими полями:
    • id – уникальный идентификатор записи;
    • archive_id – идентификатор архива, не может быть равен 0, должен быть идентичен для всех таблиц, архивируемых одновременно;
    • table_type – тип архивной таблицы (см. выше);
    • table_name – имя архивной таблицы;
    • start_date – время, которым датировано первое списание в архиве (UNIX TIMESTAMP);
    • end_date – время, которым датировано последнее списание в архиве (UNIX TIMESTAMP);
    Все архивные таблицы должны быть перечислены в таблице archives.
  4. Каждая архивная таблица должна иметь такую же структуру, как и соответствующая текущая таблица в установленной сборке.
  5. Каждая архивная таблица должна содержать все данные, датированные временем, входящим в диапазон, указанный в соответствующей записи в таблице archives, и только эти данные.
  6. Все данные за время, не покрытое архивными таблицами, должны содержаться в текущих таблицах.
  7. Архивирование должно происходить одновременно для всех типов таблиц, к которым оно применимо. Создаваемые одновременно архивные таблицы должны иметь одинаковые start_date, end_date и archive_id.
  8. Минимальное значение поля id в текущих таблицах payment_transactions, dhs_sessions_log, dhs_sessions_detail, tel_sessions_log и tel_sessions_detail должно быть больше, чем максимальное значение того же поля в соответствующих архивных таблицах.
  9. В UTM сборки 5.2.1-006 архивирование применялось только к таблицам discount_transactions_all и discount_transactions_iptraffic_all. Использование архивных таблиц, созданных для этой сборки, требует архивирования "задним числом" всех остальных таблиц, к которым оно применимо. Т.е. для каждой из них должны быть созданы архивные таблицы по тем же периодам времени, и данные за эти периоды перенесены в эти таблицы. Наименование полей таблиц, содержащих дату, см. выше.
  10. Начиная с версии 5.3-002 в список архивируемых таблиц добавлена таблица dhcp_leases_log (тип таблицы 9), а также, начиная с версии 5.3-001, при архивации таблицы tel_sessions_detail больше не используется поле даты.
  11. Таблицы, для которых не используется поле даты, нужно архивировать одновременно с таблицами, с которыми они связаны. На данный момент в таблицах связаны следующие поля:
    • tel_sessions_log.id = tel_sessions_detail.dhs_sess_id
    • dhs_sessions_log.id = dhs_sessions_detail.dhs_sess_id
    • invoices.id = invoice_entry.invoice_id
    • invoice_entry.id = invoice_entry_details.entry_id
  12. Для облегчения ручной обработки (в случае надобности) рекомендуется давать архивным таблицам интуитивно понятные имена, например, имя_основной_таблицы_метка, где метка – timestamp (отметка времени) создания архивной таблицы.
  13. Архивная таблица может не поддерживать транзакции и быть доступна в режиме только чтения.