Задать вопрос

igortru

Комментарии

  • Почему большой iowait в cloud vm c postgres?

    @igortru Автор вопроса
    изучали, правда давно, получается значительно дороже и по скорости медленнее
    Написано

  • Какие есть варианты репликации MSSQL?

    @igortru Автор вопроса
    Лицензия есть, конфигурация 1с закрытая, на postgres тормозит. Разбираться "почему тормозит" - ни у кого нет времени и желания ) По состоянию на год назад разобраться с этим не удалось, рабочую 1с надо было "прям сейчас".
    Написано

  • Почему большой iowait в cloud vm c postgres?

    @igortru Автор вопроса
    SunTechnik, получается система простаивает из-за большого latency ? и внутри vm я на это никак повлиять не могу?
    Вопрос к тому что у нас есть другие БД, кластера, vm где этого не наблюдается.
    Написано

  • Почему большой iowait в cloud vm c postgres?

    @igortru Автор вопроса
    так что делать?)) вопрос больше риторический.
    у нас есть СУБД в YC которые в разы больше по объёму и нагрузке, но такой latency и iowait я не наблюдаю.
    мб есть какой-то тюнинг - "писать большими блоками", "количество потоков записи" и пр...
    Написано

  • Почему большой iowait в cloud vm c postgres?

    @igortru Автор вопроса
    ну т.е. это облачный провайдер? Они свой комментарий как-бы дали
    Написано

  • Почему большой iowait в cloud vm c postgres?

    @igortru Автор вопроса
    SunTechnik, прикрепил, в новой версии вопроса
    Написано

  • Как pgbouncer обрабатывает idle сесии?

    @igortru Автор вопроса
    ky0 Melkij благодарю за развернутые ответы
    Написано

  • Как исправить несоответствие версии сортировки?

    @igortru Автор вопроса
    Версии ОС действительно разные, местер Debian 11, реплика Debian 12
    Написано

  • Как восстановить базу данных?

    @igortru Автор вопроса
    Константин Цветков, Да, сейчас БД развернута из бекапа на тестовом сервере.
    Написано

  • Как восстановить базу данных?

    @igortru Автор вопроса
    пробовали, последующая проверка выдает те-же ошибки:
    Msg 824, Level 24, State 2, Line 5
SQL Server обнаружил логическую ошибку ввода-вывода, связанную с согласованностью: неверный идентификатор страницы (ожидаемый 1:7587022; фактический 1:8495766). Она произошла при прочитать страницы (1:7587022) в базе данных с идентификатором 5 по смещению 0x00000e7899c000 в файле "C:\Program Files\Microsoft SQL Server\MSSQL16.MSSQLSERVER\MSSQL\DATA\database.mdf".
    Написано

  • Как восстановить базу данных?

    @igortru Автор вопроса
    hint000, все резервные копии содержат эту ошибку.
    Написано

  • Как восстановить базу данных?

    @igortru Автор вопроса
    Константин Цветков, да, падает
    Написано

  • Как делаются снапшоты в Proxmox при использовании Proxmox Backup Server?

    @igortru Автор вопроса
    Дмитрий, я к этому и пришел, получается что бекап "snapshot" ничего не имеет общего со "snapshot" во вкладке с vm.
    При отсутствии агента quemu мы вообще получаем гарантированно не консистентные данные и чем дольше она бекапится тем расхождение еще больше.
    Поправь если не прав.
    Написано

  • Как делаются снапшоты в Proxmox при использовании Proxmox Backup Server?

    @igortru Автор вопроса
    Дмитрий, ок.
    Получается что в момент создания бекапа методом Snapshot в случае с qcow2 формата размещения диска vm я должен рядом увидеть файл изменений (дельту) или в случае с lvm snapshot раздела. Верно?
    Написано

  • Как делаются снапшоты в Proxmox при использовании Proxmox Backup Server?

    @igortru Автор вопроса
    Дмитрий, да, агент не запущен. Для создания снапшота vm это не требуется. Я сравниваю с vmware.
    Написано

  • Как делаются снапшоты в Proxmox при использовании Proxmox Backup Server?

    @igortru Автор вопроса
    При размещении диска vm в формате - qcow2 тоже есть снапшоты, в lvm (thick) - нету, в lvm thin - есть, это указано в офиц. документации. А где их можно пощупать и увидеть? В vmware видно что vm уходит в snapshot.
    Я запустил бекап машины в разных дисковых средах (ext4,lvm (thick), lvm thin) - везде машина отбекапилась, создания снапшотов я не увидел в консоли проксмоса и в LVM (lvs, lvdisplay). Такое ощущение что это лишь команда для quemu agenta типа создай vss внутри ОС.
    Написано

  • Почему возникает ошибка при восстановлении PiTR Postgres WAL-G?

    @igortru Автор вопроса
    Попробовал восстановить БД побольше 4Гб, судя по журналам WAL пишутся в S3 каждые пол часа.

    restore_command = 'wal-g --config=/mnt/pg-data/.walg.json wal-fetch \"%f\" \"%p\" >> /var/log/wal-g/wal_g_restore_command.log 2>&1'
recovery_target_time = '2023-06-16 23:00:00 '


    wal_g_restore_command.log
    ERROR: 2023/06/17 02:55:40.458071 Archive '0000000D.history' does not exist.
ERROR: 2023/06/17 02:55:40.971844 Archive '0000000C0000003100000095' does not exist.
ERROR: 2023/06/17 02:55:41.148688 Archive '0000000B0000003100000095' does not exist.
ERROR: 2023/06/17 02:55:41.277587 Archive '0000000A0000003100000095' does not exist.


    postgresql-Sat.log
    2023-06-17 02:55:39.463 GMT [22637] LOG:  starting PostgreSQL 14.8 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-44), 64-bit
2023-06-17 02:55:39.463 GMT [22637] LOG:  listening on IPv4 address "0.0.0.0", port 5432
2023-06-17 02:55:39.463 GMT [22637] LOG:  listening on IPv6 address "::", port 5432
2023-06-17 02:55:39.464 GMT [22637] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2023-06-17 02:55:39.466 GMT [22637] LOG:  listening on Unix socket "/tmp/.s.PGSQL.5432"
2023-06-17 02:55:39.470 GMT [22641] LOG:  database system was interrupted; last known up at 2023-06-16 17:00:03 GMT
2023-06-17 02:55:40.039 GMT [22641] LOG:  restored log file "0000000A.history" from archive
2023-06-17 02:55:40.135 GMT [22641] LOG:  restored log file "0000000B.history" from archive
2023-06-17 02:55:40.237 GMT [22641] LOG:  restored log file "0000000C.history" from archive
2023-06-17 02:55:40.459 GMT [22641] LOG:  starting point-in-time recovery to 2023-06-16 23:00:00+00
2023-06-17 02:55:40.773 GMT [22641] LOG:  restored log file "0000000C.history" from archive
2023-06-17 02:55:41.573 GMT [22641] LOG:  restored log file "000000090000003100000095" from archive
2023-06-17 02:55:41.611 GMT [22641] FATAL:  requested timeline 12 is not a child of this server's history
2023-06-17 02:55:41.611 GMT [22641] DETAIL:  Latest checkpoint is at 31/95000060 on timeline 9, but in the history of the requested timeline, the server forked off from that timeline at 2A/6C0000
A0.
2023-06-17 02:55:41.612 GMT [22637] LOG:  startup process (PID 22641) exited with exit code 1
2023-06-17 02:55:41.612 GMT [22637] LOG:  aborting startup due to startup process failure
2023-06-17 02:55:41.616 GMT [22637] LOG:  database system is shut down
    Написано

  • Почему возникает ошибка при восстановлении PiTR Postgres WAL-G?

    @igortru Автор вопроса
    wal-g --config=/mnt/pg-data/.walg.json wal-show

    648d1adea631c062076983.png
    Написано

  • Почему возникает ошибка при восстановлении PiTR Postgres WAL-G?

    @igortru Автор вопроса
    Melkij, БД маленькая, задание выполняется несколько секунд. Журнал выполнения ниже. Задание запускаеися с такими параметрами:
    su postgres -c 'wal-g --config=/mnt/pg-data/.walg.json delete retain FULL 2 --confirm >> /var/log/wal-g/wal_g_backup.log 2>&1'
su postgres -c 'wal-g --config=/mnt/pg-data/.walg.json backup-push /mnt/pg-data/14 >> /var/log/wal-g/wal_g_backup.log 2>&1'


    Журнал выполнения за 14-е число.

    INFO: 2023/06/14 17:00:01.158815 retrieving permanent objects
INFO: 2023/06/14 17:00:01.574465 Start delete
INFO: 2023/06/14 17:00:01.692653 Objects in folder:
INFO: 2023/06/14 17:00:01.692701        will be deleted: basebackups_005/base_000000180000000000000053_backup_stop_sentinel.json
INFO: 2023/06/14 17:00:01.692789        will be deleted: wal_005/000000180000000000000053.00000028.backup.br
INFO: 2023/06/14 17:00:01.692810        will be deleted: wal_005/000000180000000000000053.br
INFO: 2023/06/14 17:00:01.692818        will be deleted: wal_005/000000180000000000000054.br
INFO: 2023/06/14 17:00:01.692860        will be deleted: basebackups_005/base_000000180000000000000053/metadata.json
INFO: 2023/06/14 17:00:01.692885        will be deleted: basebackups_005/base_000000180000000000000053/tar_partitions/part_001.tar.br
INFO: 2023/06/14 17:00:01.692894        will be deleted: basebackups_005/base_000000180000000000000053/tar_partitions/part_003.tar.br
INFO: 2023/06/14 17:00:01.692905        will be deleted: basebackups_005/base_000000180000000000000053/tar_partitions/pg_control.tar.br
INFO: 2023/06/14 17:00:01.761965 Selecting the latest backup as the base for the current delta backup...
INFO: 2023/06/14 17:00:01.792326 Calling pg_start_backup()
INFO: 2023/06/14 17:00:01.956149 Starting a new tar bundle
INFO: 2023/06/14 17:00:01.956204 Walking ...
INFO: 2023/06/14 17:00:01.956486 Starting part 1 ...
INFO: 2023/06/14 17:00:02.370733 Packing ...
INFO: 2023/06/14 17:00:02.371676 Finished writing part 1.
INFO: 2023/06/14 17:00:03.540698 Starting part 2 ...
INFO: 2023/06/14 17:00:03.540770 /global/pg_control
INFO: 2023/06/14 17:00:03.541743 Finished writing part 2.
INFO: 2023/06/14 17:00:03.542964 Calling pg_stop_backup()
INFO: 2023/06/14 17:00:04.861308 Starting part 3 ...
INFO: 2023/06/14 17:00:04.861406 backup_label
INFO: 2023/06/14 17:00:04.861419 tablespace_map
INFO: 2023/06/14 17:00:04.863097 Finished writing part 3.
INFO: 2023/06/14 17:00:04.954148 Wrote backup with name base_000000180000000000000059


    Возможно ли поведение WAL-G когда он удаляет все предыдущие WAL при создании нового полного бекапа? т.е. восстановить предыдущее 2 полных возможно но без привязки по времени?

    Попробовал восстановить из вчерашнего бекапа, получил другую ошибку :

    Новых данных в БД не заносится, размен как ранее писал очень мал - 11МБ.

    2023-06-17 02:01:45.454 GMT [19421] LOG:  starting PostgreSQL 14.8 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-44), 64-bit
2023-06-17 02:01:45.456 GMT [19421] LOG:  listening on IPv4 address "0.0.0.0", port 5432
2023-06-17 02:01:45.456 GMT [19421] LOG:  listening on IPv6 address "::", port 5432
2023-06-17 02:01:45.458 GMT [19421] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2023-06-17 02:01:45.461 GMT [19421] LOG:  listening on Unix socket "/tmp/.s.PGSQL.5432"
2023-06-17 02:01:45.464 GMT [19424] LOG:  database system was interrupted; last known up at 2023-06-16 17:00:02 GMT
2023-06-17 02:01:45.648 GMT [19424] LOG:  restored log file "00000019.history" from archive
2023-06-17 02:01:45.895 GMT [19424] LOG:  starting point-in-time recovery to 2023-06-17 00:00:00+00
2023-06-17 02:01:45.996 GMT [19424] LOG:  restored log file "00000019.history" from archive
2023-06-17 02:01:46.363 GMT [19424] LOG:  restored log file "00000018000000000000005D" from archive
<b>2023-06-17 02:01:46.369 GMT [19424] FATAL:  requested timeline 25 is not a child of this server's history
2023-06-17 02:01:46.369 GMT [19424] DETAIL:  Latest checkpoint is at 0/5D000060 on timeline 24, but in the history of the requested timeline, the server forked off from that timeline at 0/5C00000
</b>2023-06-17 02:01:46.370 GMT [19421] LOG:  startup process (PID 19424) exited with exit code 1
2023-06-17 02:01:46.370 GMT [19421] LOG:  aborting startup due to startup process failure
2023-06-17 02:01:46.373 GMT [19421] LOG:  database system is shut down


    restore_command = 'wal-g --config=/mnt/pg-data/.walg.json wal-fetch \"%f\" \"%p\" >> /var/log/wal-g/wal_g_restore_command.log 2>&1'
    recovery_target_time = '2023-06-17 00:00:00'

    /var/log/wal-g/wal_g_restore_command.log
    ERROR: 2023/06/17 02:00:32.899667 Archive '0000001A.history' does not exist.
ERROR: 2023/06/17 02:00:33.195372 Archive '00000019000000000000005D' does not exist.
ERROR: 2023/06/17 02:01:45.894435 Archive '0000001A.history' does not exist.
ERROR: 2023/06/17 02:01:46.197105 Archive '00000019000000000000005D' does not exist.


    Журнал выполнения бекапа с сервера за 16-е число.
    INFO: 2023/06/16 17:00:01.582475 retrieving permanent objects
INFO: 2023/06/16 17:00:02.072793 Start delete
INFO: 2023/06/16 17:00:02.222819 Objects in folder:
INFO: 2023/06/16 17:00:02.222870        will be deleted: basebackups_005/base_000000180000000000000057_backup_stop_sentinel.json
INFO: 2023/06/16 17:00:02.222954        will be deleted: wal_005/000000180000000000000057.00000028.backup.br
INFO: 2023/06/16 17:00:02.222963        will be deleted: wal_005/000000180000000000000057.br
INFO: 2023/06/16 17:00:02.222972        will be deleted: wal_005/000000180000000000000058.br
INFO: 2023/06/16 17:00:02.223025        will be deleted: basebackups_005/base_000000180000000000000057/metadata.json
INFO: 2023/06/16 17:00:02.223052        will be deleted: basebackups_005/base_000000180000000000000057/tar_partitions/part_001.tar.br
INFO: 2023/06/16 17:00:02.223066        will be deleted: basebackups_005/base_000000180000000000000057/tar_partitions/part_003.tar.br
INFO: 2023/06/16 17:00:02.223077        will be deleted: basebackups_005/base_000000180000000000000057/tar_partitions/pg_control.tar.br
INFO: 2023/06/16 17:00:02.292458 Selecting the latest backup as the base for the current delta backup...
INFO: 2023/06/16 17:00:02.320451 Calling pg_start_backup()
INFO: 2023/06/16 17:00:02.473048 Starting a new tar bundle
INFO: 2023/06/16 17:00:02.473108 Walking ...
INFO: 2023/06/16 17:00:02.473456 Starting part 1 ...
INFO: 2023/06/16 17:00:02.905460 Packing ...
INFO: 2023/06/16 17:00:02.906443 Finished writing part 1.
INFO: 2023/06/16 17:00:04.052359 Starting part 2 ...
INFO: 2023/06/16 17:00:04.052436 /global/pg_control
INFO: 2023/06/16 17:00:04.053475 Finished writing part 2.
INFO: 2023/06/16 17:00:04.054552 Calling pg_stop_backup()
INFO: 2023/06/16 17:00:05.096904 Starting part 3 ...
INFO: 2023/06/16 17:00:05.097015 backup_label
INFO: 2023/06/16 17:00:05.097027 tablespace_map
INFO: 2023/06/16 17:00:05.098561 Finished writing part 3.
INFO: 2023/06/16 17:00:05.203537 Wrote backup with name base_00000018000000000000005D


    С рабочего сервера, больше записей нет - /var/log/wal-g/wal_g_archive_command.log
    INFO: 2023/06/12 17:00:04.588456 FILE PATH: 000000180000000000000055.br
INFO: 2023/06/13 17:00:03.180230 FILE PATH: 000000180000000000000056.br
INFO: 2023/06/13 17:00:04.911261 FILE PATH: 000000180000000000000057.00000028.backup.br
INFO: 2023/06/13 17:00:04.917427 FILE PATH: 000000180000000000000057.br
INFO: 2023/06/14 17:00:01.995453 FILE PATH: 000000180000000000000058.br
INFO: 2023/06/14 17:00:03.984552 FILE PATH: 000000180000000000000059.00000028.backup.br
INFO: 2023/06/14 17:00:03.986231 FILE PATH: 000000180000000000000059.br
INFO: 2023/06/15 17:00:02.916916 FILE PATH: 00000018000000000000005A.br
INFO: 2023/06/15 17:00:04.716082 FILE PATH: 00000018000000000000005B.br
INFO: 2023/06/15 17:00:04.716215 FILE PATH: 00000018000000000000005B.00000028.backup.br
INFO: 2023/06/16 17:00:02.556806 FILE PATH: 00000018000000000000005C.br
INFO: 2023/06/16 17:00:04.229296 FILE PATH: 00000018000000000000005D.00000028.backup.br
INFO: 2023/06/16 17:00:04.230712 FILE PATH: 00000018000000000000005D.br
    Написано

  • В postgresql параметр max_wal_size - размер всех сегментов или одного?

    @igortru Автор вопроса
    Melkij, Благодарю!
    Написано