Какие операции над бд регистрируют программы ведения системного журнала

Рассмотрим две модели транзакций, используемые в большинстве коммерческих СУБД: модель автоматического выполнения транзакций и модель управляемого выполнения транзакций, обе основанные на инструкциях языка SQL – COMMIT и ROLLBACK (слайд 5).

Автоматическое выполнение транзакций

В стандарте ANSI/ISO зафиксировано, что транзакция автоматически начинается с выполнения пользователем или программой первой инструкции SQL. Далее происходит последовательное выполнение инструкций до тех пор, пока транзакция не завершается одним из двух способов (слайд 6):

• инструкцией COMMIT, которая выполняет завершение транзакции: изменения, внесенные в БД, становятся постоянными, а новая транзакция начинается сразу после инструкции COMMIT;
• инструкцией ROLLBACK, которая отменяет выполнение текущей транзакции и возвращает БД к состоянию начала транзакции, новая транзакция начинается сразу после инструкции ROLLBACK.

Управляемое выполнение транзакций

• инструкция BEGIN TRANSACTION сообщает о начале транзакции, т.е. начало транзакции задается явно;
• инструкция COMMIT TRANSACTION сообщает об успешном выполнении транзакции, но при этом новая транзакция не начинается автоматически;
• инструкция SAVE TRANSACTION позволяет создать внутри транзакции точку сохранения и присвоить сохраненному состоянию имя точки сохранения, указанное в инструкции;
• инструкция ROLLBACK отменяет выполнение текущей транзакции и возвращает БД к состоянию, где была выполнена инструкция SAVE TRANSACTION (если в инструкции указана точка сохранения – ROLLBACK ТО имя_точки_сохранения) или к состоянию начала транзакции.

25.2. Журнал транзакций (слайд 8)

1. Пользователь не должен осуществлять рестарт транзакций или повторный ввод данных. Восстановление должно проходить на базе транзакции с помощью отмены или изменения отдельных транзакций.
2. Быстрое восстановление данных обеспечивается генерацией данных, используемых для восстановления.
3. При выполнении процедур автоматизированного восстановления пользователь не должен анализировать состав данных и выбирать сами процедуры.

1. Программы ведения системного журнала регистрируют операции над БД: описание соответствующей транзакции, код пользователя, текст входного сообщения, тип изменения БД, адреса изменяемых данных вместе с их значениями до и после изменения.
2. Программы архивации используются для регулярного получения копий БД для последующего ее восстановления.
3. Программы восстановления применяются для возврата БД или некоторых ее частей в состояние, предшествующее возникновению отказа. При этом используют архивную копию БД и системный журнал.
4. Программы отката ликвидируют последствия выполнения определенной транзакции в БД.
5. Программы записи контрольных точек и повторного исполнения позволяют ускорить восстановление.

• Атомарность – операции транзакции образуют неразделимый атомарный блок с определенным началом и концом. Этот блок либо выполняется от начала до конца, либо не выполняется вообще. Если в процессе выполнения транзакции произошел сбой, происходит откат к исходному состоянию.
• Согласованность – по завершении транзакции все задействованные объекты находятся в согласованном состоянии.
• Изолированность – одновременный доступ транзакций различных приложений к разделяемым объектам координируется таким образом, чтобы эти транзакции не влияли друг на друга.
• Долговременность – все изменения данных, осуществленные в процессе выполнения транзакции, не могут быть потеряны.

Источник: studfile.net

Видеолекция Поддержание механизма транзакций. Проблемы параллелизма транзакций

Что такое транзакции БД — простыми словами

Резервное копирование и восстановление

Резервное копирование и восстановление можно выполнить с помощью утилит (например, Enterprise Manager в MS SQL Server), мастера или команд T-SQL. Для размещения архивных копий должно быть создано логическое устройство (которое может быть отдельным физическим устройством).

Резервное копирование выполняется для каждой БД индивидуально и может производиться несколькими способами.

Полное резервное копирование обеспечивает архивирование всех данных базы, размещенных как в группах файлов, так и в отдельных файлах. Этот способ наиболее часто используется для архивирования БД небольшого размера. В других случаях надо использовать выборочное копирование или копирование групп файлов.

Выборочное (дифференциальное) резервное копирование обеспечивает архивирование только тех данных базы, которые были изменены с момента последнего архивирования.

Резервное копирование журнала транзакций обеспечивает архивирование и усечение журнала.

В случае резервного копирования файлов и групп файлов их можно копировать вместе или по отдельности. Полностью восстановить БД с помощью резервной копии файлов и группы файлов сложнее, чем с помощью обычной резервной копии. Для восстановления таблиц и индексов, которые охватывают несколько групп файлов, нужно, чтобы эти файлы и группы файлов были скопированы вместе с охватывающими их объектами.

Восстановление БД после сбоев обеспечивается с помощью журнала транзакций. Основным принципом согласованной политики записи изменений в журнал и в БД является то, что запись об изменении объекта БД должна попадать во внешнюю память журнала раньше, чем измененный объект оказывается во внешней памяти БД. Протокол журнализации (и управления буферизацией) называется WAL (Write Ahead Log – «пиши сначала в журнал»).

Каждая успешно завершившаяся транзакция должна быть зафиксирована во внешней памяти. Минимальным требованием, гарантирующим возможность восстановления последнего согласованного состояния БД, является сохранение во внешней памяти журнала всех записей об изменении БД этой транзакцией. При этом последней записью в журнале от имени данной транзакции является специальная запись о конце транзакции.

Иногда для восстановления БД после сбоя журнала изменений недостаточно. Основой восстановления в этом случае являются журнал и архивная копия БД. Восстановление начинается с обратного копирования БД из архивной копии. Затем для всех закончившихся транзакций по журналу повторно выполняются все операции. Для транзакций, не закончившихся к моменту сбоя, выполняется откат.

К ведению журнала предъявляются особые требования по части надежности, однако реально возможна и его утрата. Тогда единственным способом восстановления БД является возврат к архивной копии. Самый простой способ производства архивных копий БД – архивировать БД при переполнении журнала. В этом случае образование новых транзакций временно блокируется.

Когда БД придет в согласованное состояние, можно выполнять ее архивацию, после чего начинать заполнять журнал заново. Можно выполнять архивацию БД реже, чем переполняется журнал. При переполнении журнала и окончании начатых транзакций можно архивировать сам журнал. Поскольку архивированный журнал требуется только для воссоздания архивной копии БД, журнальная информация при архивации может быть сжата.

Процесс восстановления БД зависит от типа архива. При восстановлении из дифференциального архива или из архива журнала транзакций необходимо предварительно восстановить БД из последнего полного архива. Для правильного восстановления БД на основе файлов или группы файлов необходимо использовать резервную копию журнала транзакций.

Существуют общие требования к системе восстановления данных в СУБД.

1. Пользователь не должен осуществлять рестарт транзакций или повторный ввод данных. Восстановление должно проходить на базе транзакции с помощью отмены или изменения отдельных транзакций.

2. Быстрое восстановление данных обеспечивается генерацией данных, используемых для восстановления.

3. При выполнении процедур автоматизированного восстановления пользователь не должен анализировать состав данных и выбирать сами процедуры.

Для восстановления БД в составе СУБД имеются следующие средства:

· программы ведения системного журнала регистрируют операции над БД;

· программы архивации используются для регулярного получения копий БД для последующего ее восстановления;

· программы восстановления применяются для возврата БД или некоторых ее частей в состояние, предшествующее возникновению отказа;

· программы отката ликвидируют последствия выполнения определенной транзакции в БД;

· программы записи контрольных точек и повторного исполнения позволяют ускорить восстановление.

Контрольная точка – это операция согласования состояния БД в физических файлах с текущим состоянием кэша (системного буфера). С целью улучшения производительности сохраняемые в БД данные сначала помещаются в кэш, а потом система перезаписывает модифицированные страницы на диск (отложенная запись), причем пользователь не может знать, когда эта запись производится.

Контрольная точка выполняется командой CHECKPOINT при завершении работы сервера, а также в соответствии с установленным интервалом контрольных точек и включает выполнение следующих операций:

· запись на диск всех страниц, измененных к началу контрольной точки;

· запись в журнал транзакций списка незавершенных транзакций;

· запись в журнал транзакций всех измененных страниц;

· журнала PostgreSQL

Из коробки PostgreSQL будет показывать журналы в stderr, что не очень удобно, так как они будут смешиваться с другими процессами, которые также ведут логирование в stderr. Чтобы PostgreSQL мог создавать собственные логи, необходимо включить параметр logging_collector . Когда вы это сделаете, журналы начнут отправляться в стандартное местоположение, определенное вашей ОС. Ниже приведены директории журналов по умолчанию для нескольких различных операционных систем:

• Система на базе Debian: e/var/log/postgresql/postgresql-x.x.main.log. X.x.
• Система на базе Red Hat: /var/lib/pgsql/data/pg_log
• Windows: C:Program FilesPostgreSQL9.3datapg_log

Чтобы поменять место хранения файлов журнала при включенном сборщике (коллекторе) логов, вы можете использовать параметр log_directory для указания пользовательского каталога.

Обратите внимание, что иногда ведение журнала может быть затруднительно в PostgreSQL. Коллектор логов не позволит потерять ни одного сообщения журнала, поэтому при высокой нагрузке он может блокировать процессы сервера, что приведет к проблемам. Вместо него можно использовать системный журнал (syslog), так как он позволяет отбрасывать некоторые сообщения и не блокирует систему. Чтобы отключить коллектор логов, вы можете настроить опцию на off:

logging_collector off

В зависимости от условий использования, вам может понадобиться изменить местоположение журналов PostgreSQL. Обычно используются такие варианты, как запись в syslog, CSV, Windows Event и Docker, о которых речь пойдет ниже.

Syslog

Вы можете легко настроить PostgreSQL на ведение журнала в syslog. Вам нужно сделать это на демоне syslog с помощью следующей конфигурации:

local0.* /var/log/postgresql

Вы можете использовать такие параметры, как syslog_facility , syslog_indent , syslog_sequence_number в конфигурационном файле PostgreSQL для форматирования логов.

CSV лог

Если вы хотите загрузить журналы в инструмент анализа или программу, можно сохранить их в CSV-файл. CSV хорошо определен, что делает этот процесс простым. Для перевода журналов в CSV необходимо добавить следующую строку в конфигурацию PostgreSQL:

csvlog /log/postgresql.csv

Вы также можете создать таблицу дополнительно к журналам, а затем использовать SQL для запроса по определенным условиям.

Журнал событий Windows

Для систем PostgreSQL, работающих под Windows, вы можете отправлять логи в журнал событий (event) Windows, используя следующую конфигурацию:

log_destination = ‘stderr, eventlog’

Обязательно зарегистрируйте систему источника событий в ОС Windows, чтобы она могла получать и показывать вам сообщения журнала событий с помощью программы просмотра событий Windows. Для этого выполните команду:

regsvr32 pgsql_library_directory/pgevent.dll

Docker

В настоящее время многие инструменты и базы данных запускаются как Docker-приложения, включая PostgreSQL. Вы также можете легко запустить Docker-версию PostgreSQL на Kubernetes или любой другой платформе оркестрации контейнеров.

Однако в таких случаях не стоит вносить изменения непосредственно в поды или контейнеры, поскольку эти изменения могут быть потеряны при перезапуске подов. Вместо этого необходимо передавать конфигурации во время запуска этих контейнеров.

Чтобы включить логирование, необходимо передать конфигурации с помощью ConfigMaps в Kubernetes. Читайте этот блог, чтобы развернуть PostgreSQL на Kubernetes и включить/выключить различные настройки.

Что важно записывать в журнал?

Запись большого количества информации в журнал может привести к пустой трате времени, если вы не сможете определить, какие логи важны, а какие нет. Очень важно уменьшить шум в журналах, чтобы ускорить отладку — это также сэкономит ваше время и ресурсы для их хранения.

Журналы должны показать вам медленные запросы, уровни логов и то, как отловить критическую информацию с минимальным объемом логирования. Этого можно добиться с помощью фильтров, наиболее распространенными из которых являются пороговые значения журнала, его уровни, время выполнения оператора и семплинг. Давайте немного углубимся в каждый из них.

Пороговые значения для медленного запроса

PostgreSQL может регистрировать запросы, которые занимают больше времени, чем определенный порог. Определение медленных запросов в журнале помогает обнаружить проблемы с базой данных и причины задержек в работе вашего приложения.

Чтобы включить эту функцию, необходимо отредактировать файл postgresql.conf . Найдите строку log_min_duration_statement и настройте ее в соответствии с вашими потребностями. Например, приведенный ниже оператор будет регистрировать все запросы, которые выполняются более 1 секунды:

log_min_duration_statement = 1000

После этого сохраните файл и перезагрузите PostgreSQL. Ваши настройки будут применены, и вы сможете увидеть логи медленных запросов в файлах журнала PostgreSQL.

Вы также можете задать эти параметры динамически с помощью интерфейса запросов PostgreSQL, выполнив следующую команду:

ALTER DATABASE db SET log_min_duration_statement = ‘1000ms’;

Время выполнения оператора

Вы можете легко регистрировать продолжительность выполнения каждого оператора в PostgreSQL. Для этого добавьте приведенный ниже оператор в свою конфигурацию, чтобы включить протоколирование каждого оператора:

log_statement all

Другим вариантом решения этой задачи является запуск следующего оператора PostgreSQL:

ALTER DATABASE db SET log_statement = ‘all’;

Обратите внимание, что это включит логирование всех запрошенных операторов, что может оказаться не слишком полезным и попросту будет создавать много шума.

Вместо этого, возможно, вы захотите вести журнал по типу запроса, например, DDL или MOD. DDL состоит из операторов CREATE, ALTER и DROP, а MOD включает в себя DDL плюс другие операторы модификации.

Семплинг

При включенном семплинге вы можете записывать в журнал примеры операторов, которые переходят определенный порог. Если ваш сервер генерирует огромное количество журналов в связи с различными событиями, то вы не захотите регистрировать все, что выходит за порог. Можно делать это выборочно. Это помогает поддерживать меньший объем ввода/вывода при логировании и уменьшить шум в журналах, что облегчает определение того, какие типы операторов вызывают проблему.

Этими порогами и выборкой можно управлять с помощью таких параметров в файле postgresql.conf, как log_min_duration_sample , log_statement_sample_rate и log_transaction_sample_rate . Обратитесь к документации PostgreSQL, чтобы узнать, как правильно их использовать. У вас также есть возможность внести данные изменения через командную строку PostgreSQL.

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

Уровни журналов PostgreSQL

PostgreSQL предлагает несколько уровней оповещения журнала в зависимости от серьезности события. Вы можете изменить уровень журнала PostgreSQL с помощью параметра log_min_error_statement в конфигурационном файле PostgreSQL, выбрав любой из приведенных ниже:

• DEBUG1, DEBUG2, DEBUG3. DEBUG5: Предоставляет разработчикам более подробную информацию.
• INFO: Извлекает конкретные данные, запрошенные пользователем, подобно вербозному выводу
• NOTICE: Предлагает пользователям полезную информацию, например, об усечении идентификатора.
• WARNING: Выдает предупреждения о вероятных проблемах
• ERROR: Регистрирует ошибки, включая те, которые вызывают прерывание любой команды.
• LOG: Регистрирует данные, например, активность контрольных точек, что может быть полезно для администратора.
• FATAL: Возникает при ошибках, которые привели к прерыванию текущего сеанса работы.
• PANIC: Возникает при ошибках, которые приводят к прерыванию всех сеансов базы данных.

Если вы отправляете журналы в Windows eventlog (журнал событий) или syslog (системный журнал), уровень серьезности (log-severity) журнала будет изменен следующим образом:

• DEBUG1. DEBUG5 будут преобразованы в DEBUG в syslog и INFORMATION в eventlog.
• INFO будет INFO в syslog и INFORMATION в eventlog.
• NOTICE будет NOTICE в syslog и INFORMATION в eventlog.
• WARNING будет NOTICE в syslog и WARNING в eventlog.
• ERROR будет WARNING в syslog и ERROR в eventlog.
• LOG будет INFO в syslog и INFORMATION в eventlog.
• FATAL будет ERR в syslog и ERROR в eventlog.
• PANIC будет CRIT в syslog и ERROR в eventlog.

Помимо уровней, очень важно понимать, какие типы журналов генерируются PostgreSQL. Это поможет вам понять, какие именно журналы следует просматривать при возникновении определенной проблемы.

Типы журналов

Существует несколько типов журналов PostgreSQL, которые необходимо учитывать при дебаггинге Их можно разделить на два типа: журналы для администратора, и журналы для пользователя приложения.

Журналы, специфичные для администратора, помогают управлять сервером PostgreSQL. Если сервер работает неправильно, они могут указать причину этого и помочь в устранении неполадок.

Существует два типа журналов, специфичных для администратора:

• Журналы запуска: Здесь отображаются все важные события и любые проблемы (например, связанные с неправильной конфигурацией) в процессе запуска вашего сервера PostgreSQL.
• Журналы сервера: Они помогут вам определить, что происходит с сервером PostgreSQL во время работы с точки зрения администратора. Они располагаются в стандартном месте вашей инсталляции или в том месте, которое вы указали в конфигурационном файле PostgreSQL.

Когда речь заходит о журналах, специфичных для пользователей приложений, следует обратить внимание на такие важные журналы PostgreSQL:

• Журналы запросов показывают все запросы, которые были сделаны на сервере; вы можете увидеть зарегистрированные запросы, если у вас включен log_statement.
• Журналы транзакций — это записи всех событий, происходящих с базой данных; они соответствуют стандарту WAL (write ahead log), который не предназначен для чтения человеком. WAL — это способ хранения записей всех действий, выполняемых с базой данных, и может быть использован для восстановления после аварии. Плагин pg_receivexlog может отображать журналы транзакций, передаваемые вашим сервером PostgreSQL.
• Журналы соединений полезны для выявления любых нежелательных подключений к серверу. Вы можете включить log_connections в файле postgresql.conf для фиксации каждой попытки подключения к серверу; log_disconnections позволит вам увидеть всех клиентов, которые отключились от сервера.
• Журналы ошибок помогут вам определить, создают ли какие-либо из ваших запросов нежелательные проблемы на сервере; log_in_error_statement управляет уровнем важности регистрации сообщений об ошибках.
• Журналы аудита и доступа очень важны с точки зрения администратора. Первые показывают изменения, внесенные в базу данных, а вторые определяют, кто какие запросы делал; их можно включить с помощью конфигурации log_statement или плагина PostgreSQL, например, pgAudit.

Большинство из этих типов журналов находятся в стандартных местах хранения по умолчанию или там, куда вы их определите в файле postgresql.conf. Есть также несколько проектов с открытым исходным кодом, которые я люблю использовать вместе с PostgreSQL для лучшего анализа журналов, например pgBadger.

Просто вести журнал — это еще не все случаи. Вам также нужно подумать о том, как вы будете архивировать или выполнять ротацию журналов. PostgreSQL поддерживает ротацию журналов, о которой пойдет речь в следующем разделе.

Ротация журналов PostgreSQL

PostgreSQL может выполнять ротацию журналов с помощью некоторых базовых параметров конфигурации. Благодаря таким параметрам, как log_rotation_age, log_rotation_size и log_truncate_on_rotation, вы можете легко настроить, в какой момент вы хотите произвести ротацию журналов. Например:

log_rotation_age 60 #default unit is minutes, this will rotate logs every log_rotation_age 300 #rotate the logs after the time mentioned.

Вы также можете использовать CLI для настройки этой конфигурации.

Как уже говорилось, изучение журналов — необходимый шаг в выявлении проблем, а для этого нужно понимать форматирование журналов. В PostgreSQL вы можете легко определить формат журнала в соответствии с вашими потребностями.

Как форматировать журналы

В PostgreSQL есть возможность использовать формат CSV и сгенерировать CSV файл, который можно использовать для добавления логов в таблице, и в дополнение к всему использовать SQL.

Кроме того, параметр log_line_prefix позволяет форматировать начало каждой строки журнала в файле postgresql.conf или через командную строку. Настраиваемые параметры включают имя приложения, имя пользователя, имя базы данных, удаленный хост, тип бэкенда, идентификатор процесса и т.д. Весь список параметров доступен в документации PostgreSQL. Например:

Приведенный префикс log_line_prefix означает, что журналы будут начинаться со времени в миллисекундах, затем идентификатор процесса, имя пользователя, имя базы данных и имя приложения.

Форматирование журнала, пороговые значения, семплинг, уровни и типы журналов — все это поможет вам в процессе дебаггинга. Но в идеале вам нужен инструмент, который позволяет агрегировать и анализировать все эти журналы и просматривать результаты через одну панель, а не заходить на каждый сервер. Одним из таких инструментов является Sematext. Давайте рассмотрим, как вы можете получить преимущества от ведения журналов PostgreSQL с помощью Sematext.

Ведение журналов PostgreSQL с помощью Sematext

Sematext Logs — это решение для управления журналами и их мониторинга, которое позволяет вам объединять журналы из различных источников данных вашей инфраструктуры в одном месте для просмотра и анализа.

Sematext обладает функцией автоматического обнаружения сервисов, поэтому вам просто нужно установить агент Sematext на свои серверы, выполнить базовую настройку, и ваши журналы PostgreSQL начнут в него стекаться. Они будут представлены на интуитивно понятной, готовой к использованию информационной панели (дашборд). Вы даже можете легко создать собственный дашборд, настроить оповещения и отправлять их по различным каналам передачи уведомлений, таким как Gmail, Slack или PagerDuty.

Sematext также предлагает такие функции, как обнаружение аномалий, что помогает вам заранее выявлять проблемы, а затем принимать меры для их предотвращения. Для более глубокого понимания вы можете сопоставить журналы PostgreSQL с метриками PostgreSQL, чтобы быстрее обнаружить узкие места. Таким образом, вы получаете вид с высоты птичьего полета на ваши установки PostgreSQL, что облегчает поиск и отладку неисправностей.

Sematext Logs (журналы) являются частью Sematext Cloud (облако), полнофункционального решения для ведения журналов и мониторинга, которое позволяет вам получить возможность обзора и интеграции всей вашей ИТ-среды. Помимо баз данных, оно поддерживает интеграцию с широким спектром инструментов, включая HAProxy, Apache Tomcat, JVM и Kubernetes. Кроме того, вы получаете поддержку деплоя Kubernetes, поэтому вам будет проще контролировать свою установку в среде Kubernetes.

Заключение

Следить за журналами PostgreSQL — важная часть работы по устранению неполадок в базе данных. Понимая, как делаются запросы и выполнятся операторы, а также трафик, соединения, ошибки и другие изменения или события на вашем сервере, вы можете легко докопаться до проблематичных процессов и обнаружить первопричину затруднений с производительностью.

Вы можете отслеживать журналы различными способами, например, используя less или tail для файлов журналов, но это будет сложно сделать, если журналы разбросаны по нескольким файлам и машинам. Вам нужны журналы в одном месте, и такое решение, как Sematext Logs, может помочь вам достичь этого.

В преддверии старта курса «Observability — мониторинг, логирование, трейсинг» хотим порекомендовать два абсолютно бесплатных вебинара от OTUS, регистрация на которые доступна по ссылкам ниже.

• Отказоустойчивый Prometheus. Thanos, VictoriaMetrics
• Организация мониторинга с помощью Grafana stack

Источник: habr.com