Прочитанные книги
Книги в процессе чтения
Подборка книг по асинхронному программированию
1. Мэтью Фаулер - Asyncio и конкурентное программирование на Python / пер. с англ. А. А. Слинкина. – М.: ДМК Пресс, 2022. – 398 с.: ил. ISBN 978-5-93700-166-5
Эта книга адресована разработчикам средней и высокой квалификации, которые хотят использовать средства конкурентности в Python для повышения производительности, пропускной способности и отзывчивости приложений.
Из начальных глав читатель узнает, как работает asyncio, как написать первое реальное приложение и как использовать базовые функции asyncio API для конкурентного выполнения сопрограмм. Затем речь пойдет о практическом применении конкурентности – например, о том, как отправить несколько конкурентных вебзапросов или запросов к базе данных, как управлять потоками и процессами, строить веб-приложения и решать вопросы синхронизации. Рассматривается широкий круг применений от API на основе веба до командных приложений, так что книга будет полезной в решении многих реальных задач.
© Manning Publications, 2022
© Перевод, оформление, издание, ДМК Пресс, 2022
Подборка книг по технологии разработки программного обеспечения
Журналы и газеты
Материалы конференций
Материалы Wikipedia
Материалы АлтГТУ
Учебно-методическое пособие посвящено проектированию и реализации многопоточных и сетевых приложений. В пособии рассматриваются способы реализации параллельных алгоритмов с использованием нативных потоков операционной системы, средств OpenMP; проектирование распределенных программных систем с использованием языка UML и реализацию их на основе примитивов синхронизации. Рассматриваются объекты ядра операционной системы и внутренняя организация потоков и процессов.
Кроме этого, изучаются сетевые соединения на основе сокетов и способы реализации распреденных систем на их основе. Рассматриваются также программирование для суперкомпьютеров с использованием библиотеки MPI и для графических процессоров на основе OpenCL. Пособие отвечает новым стандартам высшего образования по направлениям полготовки 09.04.04 «Программная инженерия (уровень магистратуры)» и 09.04.01«Информатика и вычислительная техника (уровень магистратуры)». (с) АлтГТУ, 2015
1С-Битрикс: Управление сайтом - система управления контентом веб-проекта (CMS) от российской компании «Битрикс». Сайт: https://www.1c-bitrix.ru/
Git - это бесплатная распределенная система управления версиями с открытым исходным кодом, предназначенная для быстрой и эффективной обработки всего, от небольших до очень крупных проектов. Git прост в освоении, занимает мало места и обладает молниеносной производительностью. Он превосходит инструменты SCM, такие как Subversion, CVS, Perforce и ClearCase, с такими функциями, как дешевое локальное ветвление, удобные промежуточные области и несколько рабочих процессов.
Особенность Git, которая действительно отличает его от почти всех других SCM, - это его модель ветвления. Git позволяет и поощряет создание нескольких локальных веток, которые могут быть полностью независимыми друг от друга. Создание, слияние и удаление этих линий разработки занимает секунды. Это означает, что вы можете делать что-то вроде:
Примечательно, что когда вы отправляете в удаленный репозиторий, вам не нужно отправлять все свои ветки. Вы можете предоставить общий доступ только к одной из своих веток, нескольким или всем. Это дает людям возможность пробовать новые идеи, не беспокоясь о том, что им придется планировать, как и когда они собираются объединить их или поделиться ими с другими.
Есть способы добиться этого с помощью других систем, но эта работа намного сложнее и подвержена ошибкам. Git делает этот процесс невероятно простым и меняет способ работы большинства разработчиков, когда они его изучают.
Git работает быстро. В Git почти все операции выполняются локально, что дает огромное преимущество в скорости для централизованных систем, которым постоянно приходится где-то связываться с сервером. Git был создан для работы с ядром Linux, а это означает, что ему с самого первого дня приходилось эффективно обрабатывать большие репозитории.
Git написан на C, что сокращает накладные расходы времени выполнения, связанные с языками более высокого уровня. Скорость и производительность были основной целью Git с самого начала.
Давайте посмотрим, как общие операции сочетаются с Subversion, общей централизованной системой управления версиями, похожей на CVS или Perforce. Меньше - быстрее.
Для тестирования большие инстансы AWS были настроены в одной зоне доступности. Git и SVN были установлены на обеих машинах, репозиторий Ruby был скопирован на серверы Git и SVN, и на обоих выполнялись общие операции. В некоторых случаях команды не совпадают в точности. Здесь была предпринята попытка сопоставления по наименьшему общему знаменателю. Например, тесты «фиксации» также включают время для отправки запроса на Git, хотя в большинстве случаев вы фактически не отправляете запрос на сервер сразу после фиксации, когда две команды не могут быть разделены в SVN.
Обратите внимание, что это лучший сценарий для SVN - сервера без нагрузки с гигабитным подключением к клиентской машине. Почти все это время было бы еще хуже для SVN, если бы это соединение было медленнее, в то время как многие из Git-времени не пострадали бы. Очевидно, что во многих из этих распространенных операций управления версиями Git на один или два порядка быстрее SVN, даже в идеальных условиях для SVN. Одно место, где Git работает медленнее, - это начальная операция клонирования. Здесь Git загружает всю историю, а не только последнюю версию. Как видно из приведенных выше диаграмм, операция, выполняемая только один раз, ненамного медленнее.
Также интересно отметить, что размер данных на стороне клиента очень похож, хотя Git также имеет каждую версию каждого файла для всей истории проекта. Это показывает, насколько он эффективен при сжатии и хранении данных на стороне клиента.
Одна из самых приятных особенностей любой распределенной SCM, включая Git, - это то, что она распределенная. Это означает, что вместо «проверки» текущей части исходного кода вы выполняете «клонирование» всего репозитория.
Это означает, что даже если вы используете централизованный рабочий процесс, у каждого пользователя, по сути, есть полная резервная копия главного сервера. Каждую из этих копий можно подтолкнуть, чтобы заменить основной сервер в случае сбоя или повреждения. Фактически, у Git нет единой точки отказа, если нет только одной копии репозитория.
Благодаря распределенной природе Git и превосходной системе ветвления можно относительно легко реализовать почти бесконечное количество рабочих процессов.
Централизованный рабочий процесс очень распространен, особенно у людей, переходящих из централизованной системы. Git не позволит вам толкать, если кто-то нажал с момента последней загрузки, поэтому централизованная модель, когда все разработчики отправляют на один и тот же сервер, работает нормально.
Другой распространенный рабочий процесс Git включает в себя менеджера интеграции - одного человека, который фиксирует «благословенный» репозиторий. Затем ряд разработчиков клонируют данные из этого репозитория, отправляют их в свои собственные независимые репозитории и просят интегратора внести их изменения. Это тип модели разработки, который часто встречается в репозиториях с открытым исходным кодом или GitHub.
Для более масштабных проектов часто эффективен рабочий процесс разработки, подобный процессу ядра Linux. В этой модели некоторые люди («лейтенанты») отвечают за определенную подсистему проекта и объединяют все изменения, связанные с этой подсистемой. Другой интегратор («диктатор») может получать изменения только от своих лейтенантов, а затем отправлять их в «благословенный» репозиторий, из которого все затем клонируют снова.
Модель данных, которую использует Git, обеспечивает криптографическую целостность каждого бита вашего проекта. Каждый файл и фиксация проверяются по контрольной сумме и извлекаются по ее контрольной сумме при повторной проверке. Из Git невозможно получить что-либо, кроме точно введенных вами битов.
Также невозможно изменить какой-либо файл, дату, сообщение фиксации или любые другие данные в репозитории Git без изменения идентификаторов всего, что находится после него. Это означает, что если у вас есть идентификатор фиксации, вы можете быть уверены не только в том, что ваш проект точно такой же, как в момент фиксации, но и в том, что в его истории ничего не изменилось. Большинство централизованных систем контроля версий по умолчанию не обеспечивают такой целостности.
В отличие от других систем, в Git есть нечто, называемое «промежуточной областью» или «индексом». Это промежуточная область, где коммиты могут быть отформатированы и проверены перед завершением коммита.
Одна вещь, которая отличает Git от других инструментов, заключается в том, что можно быстро подготовить некоторые из ваших файлов и зафиксировать их без фиксации всех других измененных файлов в вашем рабочем каталоге или необходимости перечисления их в командной строке во время фиксации.
Это позволяет размещать только части измененного файла. Прошли те времена, когда в файл вносились две логически не связанные модификации, прежде чем вы осознали, что забыли зафиксировать одну из них. Теперь вы можете просто подготовить изменение, необходимое для текущего коммита, и подготовить другое изменение для следующего коммита.Эта функция позволяет при необходимости вносить в файл столько различных изменений, сколько необходимо.
Конечно, Git также позволяет легко игнорировать эту функцию, если вам не нужен такой контроль - просто добавьте '-a' в свою команду фиксации, чтобы добавить все изменения во все файлы в промежуточную область.
Git выпущен под лицензией GNU General Public License версии 2.0, которая является лицензией с открытым исходным кодом. Проект Git решил использовать GPLv2, чтобы гарантировать вам свободу обмена и изменения бесплатного программного обеспечения - чтобы убедиться, что программное обеспечение является бесплатным для всех его пользователей.
Hexlet - Введение в Git
В июле 2020 года мы объявили о своем намерении требовать использования аутентификации на основе токенов (например, токен личного доступа, OAuth или токен установки приложения GitHub) для всех аутентифицированных операций Git. С 13 августа 2021 г. мы больше не будем принимать пароли учетных записей при аутентификации операций Git на GitHub.com.
Затронутые рабочие процессы
Настольные приложения, использующие Git (GitHub Desktop не затрагивается) Любые приложения/сервисы, которые получают доступ к репозиториям Git на GitHub.com напрямую, используя ваш пароль. Это изменение не коснется следующих клиентов: Если для вашей учетной записи включена двухфакторная аутентификация, вам уже необходимо использовать аутентификацию на основе токена или SSH. Если вы используете GitHub Enterprise Server, мы не объявляли о каких-либо изменениях в нашем локальном предложении. Если вы поддерживаете приложение GitHub, приложения GitHub не поддерживают аутентификацию по паролю.
Мы описали нашу мотивацию, когда объявили об аналогичных изменениях в аутентификации с помощью API, следующим образом:
В последние годы клиенты GitHub воспользовались рядом улучшений безопасности GitHub.com, таких как двухфакторная аутентификация, оповещения о входе в систему, проверенные устройства, предотвращение использования скомпрометированных паролей и поддержка WebAuthn. Эти функции затрудняют злоумышленнику получение пароля, который повторно использовался на нескольких веб-сайтах, и использование его для попытки получить доступ к вашей учетной записи GitHub. Несмотря на эти улучшения, по историческим причинам клиенты без включенной двухфакторной аутентификации могли продолжать аутентифицировать операции Git и API, используя только свое имя пользователя и пароль GitHub.
Начиная с 13 августа 2021 г. мы больше не будем принимать пароли учетных записей при аутентификации операций Git и будем требовать использования аутентификации на основе токенов, например токена личного доступа (для разработчиков) или токена установки приложения OAuth или GitHub (для интеграторов). для всех аутентифицированных операций Git на GitHub.com. Вы также можете продолжать использовать SSH-ключи там, где вам удобно.
Токены предлагают ряд преимуществ в плане безопасности по сравнению с аутентификацией на основе пароля:
Что вам нужно сделать сегодня
Дополнительные сведения см. в разделе Авторизация приложений OAuth и объявление в блоге разработчиков.
Включение двухфакторной аутентификации
Если вы хотите убедиться, что ваша учетная запись не поддерживает аутентификацию на основе пароля, вы можете включить двухфакторную аутентификацию для своей учетной записи сегодня. Это потребует от вас использовать личный токен доступа для всех аутентифицированных операций через Git и сторонние интеграции.
Браунауты
Чтобы все затронутые клиенты знали об изменении аутентификации, во время двух запланированных отключений мы временно отключим поддержку аутентификации по паролю, а операции Git, выполняемые с использованием пароля, временно завершатся сбоем.
График
Сегодня — если вы используете пароли для аутентификации операций Git с GitHub.com сегодня, вы скоро получите электронное письмо с призывом обновить метод аутентификации или сторонний клиент.
git hist
git status
git add .
git log
git commit -m "Описание изменения"
git push
Адрес электронной почты защищен от спам-ботов. Для просмотра адреса в браузере должен быть включен Javascript. ya.ru + Token1Восстановление файла в предыдущее состояние
git log
git checkout <обозначение коммита> <имя файла>
Показать настройки всех уровней
git config --list --global
IgorL@igor2022 MINGW64 ~/PycharmProjects/LawBot (master)$ git config --listdiff.astextplain.textconv=astextplainfilter.lfs.clean=git-lfs clean -- %ffilter.lfs.smudge=git-lfs smudge -- %ffilter.lfs.process=git-lfs filter-processfilter.lfs.required=truehttp.sslbackend=opensslhttp.sslcainfo=C:/Program Files/Git/mingw64/ssl/certs/ca-bundle.crtcore.autocrlf=truecore.fscache=truecore.symlinks=falsepull.rebase=falsecredential.helper=managercredential.https://dev.azure.com.usehttppath=trueinit.defaultbranch=masteruser.name=IgorLytkinuser.email=core.repositoryformatversion=0core.filemode=falsecore.bare=falsecore.logallrefupdates=truecore.symlinks=falsecore.ignorecase=trueremote.origin.url=https://github.com/IgorLytkin/LawBot.gitremote.origin.fetch=+refs/heads/*:refs/remotes/origin/*branch.master.remote=originbranch.master.merge=refs/heads/master
Посмотреть все настройки и где они хранятся
git config --list --show-origin
IgorL@igor2022 MINGW64 ~/PycharmProjects/LawBot (master)$ git config --list --show-originfile:C:/Program Files/Git/etc/gitconfig diff.astextplain.textconv=astextplainfile:C:/Program Files/Git/etc/gitconfig filter.lfs.clean=git-lfs clean -- %ffile:C:/Program Files/Git/etc/gitconfig filter.lfs.smudge=git-lfs smudge -- %ffile:C:/Program Files/Git/etc/gitconfig filter.lfs.process=git-lfs filter-processfile:C:/Program Files/Git/etc/gitconfig filter.lfs.required=truefile:C:/Program Files/Git/etc/gitconfig http.sslbackend=opensslfile:C:/Program Files/Git/etc/gitconfig http.sslcainfo=C:/Program Files/Git/mingw64/ssl/certs/ca-bundle.crtfile:C:/Program Files/Git/etc/gitconfig core.autocrlf=truefile:C:/Program Files/Git/etc/gitconfig core.fscache=truefile:C:/Program Files/Git/etc/gitconfig core.symlinks=falsefile:C:/Program Files/Git/etc/gitconfig pull.rebase=falsefile:C:/Program Files/Git/etc/gitconfig credential.helper=managerfile:C:/Program Files/Git/etc/gitconfig credential.https://dev.azure.com.usehttppath=truefile:C:/Program Files/Git/etc/gitconfig init.defaultbranch=masterfile:C:/Users/IgorL/.gitconfig user.name=IgorLytkinfile:C:/Users/IgorL/.gitconfig user.email=file:.git/config core.repositoryformatversion=0file:.git/config core.filemode=falsefile:.git/config core.bare=falsefile:.git/config core.logallrefupdates=truefile:.git/config core.symlinks=falsefile:.git/config core.ignorecase=truefile:.git/config remote.origin.url=https://github.com/IgorLytkin/LawBot.gitfile:.git/config remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*file:.git/config branch.master.remote=originfile:.git/config branch.master.merge=refs/heads/master
PostgreSQL (произносится «Пост-Грэс-Кью-Эл») — свободная объектно-реляционная система управления базами данных (СУБД).
PostgreSQL создана на основе некоммерческой СУБД Postgres, разработанной как open-source проект в Калифорнийском университете в Беркли. К разработке Postgres, начавшейся в 1986 году, имел непосредственное отношение Майкл Стоунбрейкер, руководитель более раннего проекта Ingres, на тот момент уже приобретённого компанией Computer Associates. Название расшифровывалось как «Post Ingres», и при создании Postgres были применены многие ранние наработки.
Стоунбрейкер и его студенты разрабатывали новую СУБД в течение восьми лет с 1986 по 1994 годы. За этот период в синтаксис были введены процедуры, правила, пользовательские типы и другие компоненты. В 1995 году разработка снова разделилась: Стоунбрейкер использовал полученный опыт в создании коммерческой СУБД Illustra, продвигаемой его собственной одноимённой компанией (приобретённой впоследствии компанией Informix), а его студенты разработали новую версию Postgres — Postgres95, в которой язык запросов POSTQUEL — наследие Ingres — был заменен на SQL.
Разработка Postgres95 была выведена за пределы университета и передана команде энтузиастов. Новая СУБД получила имя, под которым она известна и развивается в текущий момент — PostgreSQL.
PostgreSQL - от теории к практике (2020 год)
Телеграм-каналы
YouTube
pgAdmin is the most popular and feature rich Open Source administration and development platform for PostgreSQL, the most advanced Open Source database in the world. pgAdmin may be used on Linux, Unix, macOS and Windows to manage PostgreSQL and EDB Advanced Server 10 and above.
DataGrip is a database management environment for developers. It is designed to query, create, and manage databases. Databases can work locally, on a server, or in the cloud. Supports MySQL, PostgreSQL, Microsoft SQL Server, Oracle, and more. If you have a JDBC driver, add it to DataGrip, connect to your DBMS, and start working.
Free multi-platform database tool for developers, database administrators, analysts and all people who need to work with databases. Supports all popular databases: MySQL, PostgreSQL, SQLite, Oracle, DB2, SQL Server, Sybase, MS Access, Teradata, Firebird, Apache Hive, Phoenix, Presto, etc.
# Create the file repository configuration:sudo sh -c 'echo "deb http://apt.postgresql.org/pub/repos/apt $(lsb_release -cs)-pgdg main" > /etc/apt/sources.list.d/pgdg.list'# Import the repository signing key:wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo apt-key add -# Update the package lists:sudo apt-get update# Install the latest version of PostgreSQL.# If you want a specific version, use 'postgresql-12' or similar instead of 'postgresql':sudo apt-get -y install postgresql
В СУБД PostgreSQL уровень изоляции транзакций по умолчанию READ COMMITED. Задается параметром default_transaction_isolation.
SHOW default_transaction_isolation;
Создание кластераpg_createcluster 14 standby1
Запуск кластераpg_ctlcluster 14 standby1 start
postgres@singularity:~$ pg_lsclustersVer Cluster Port Status Owner Data directory Log file14 main 5432 online postgres /var/lib/postgresql/14/main /var/log/postgresql/postgresql-14-main.log14 standby1 5433 online postgres /var/lib/postgresql/14/standby1 /var/log/postgresql/postgresql-14-standby1.log
/var/log/postgresql/postgresql-14-main.log/var/log/postgresql/postgresql-14-standby1.log
COPY — копировать данные между файлом и таблицейpostgres=# \c zabbixВы подключены к базе данных "zabbix" как пользователь "postgres".zabbix=# \! mkdir /home/postgres/backup/zabbix=# copy users to '/home/postgres/backup/zabbix.users.text' (format text);COPY 3zabbix=# copy users to '/home/postgres/backup/zabbix.users.csv' (format csv);COPY 3zabbix=# copy users to '/home/postgres/backup/zabbix.users.bin' (format binary);COPY 3
Список имён всех таблиц БД zabbixselect table_name from information_schema.tableswhere table_catalog='zabbix' and table_schema='public'order by 1;
Выгрузка всех таблиц БД\с zabbixselect 'copy '||schemaname||'.'||tablename||' to ''/tmp/'||schemaname||'_'||tablename||'.txt''' from pg_tables where schemaname = 'public' \gexec
pg_dump — выгрузить базу данных PostgreSQL в виде скрипта или в архивном форматеpostgres@singularity:~$ pg_dump zabbix > zabbix.sqlpostgres@singularity:~$ ls -lитого 54324drwxrwxr-x 2 postgres postgres 4096 апр 14 05:24 backup-rw-rw-r-- 1 postgres postgres 55616031 апр 14 06:25 zabbix.sql
Восстановление в новую БДpostgres@singularity:~$ psqlpsql (14.2 (Ubuntu 14.2-1.pgdg20.04+1+b1))
postgres=# create database newdb;CREATE DATABASE postgres@singularity:~$ psql -d newdb -f zabbix.sql Выгрузка базы данных в специальном формате:postgres@singularity:~$ pg_dump -Fc zabbix > zabbix.dumppostgres@singularity:~$ ls -lитого 68404drwxrwxr-x 2 postgres postgres 4096 апр 14 05:24 backup-rw-rw-r-- 1 postgres postgres 14415122 апр 14 06:34 zabbix.dump-rw-rw-r-- 1 postgres postgres 55616031 апр 14 06:25 zabbix.sql
Выгрузка базы данных в формате каталога:postgres@singularity:~$ pg_dump -Fd zabbix -f dumpdirpostgres@singularity:~$ ls -lитого 68408drwxrwxr-x 2 postgres postgres 4096 апр 14 05:24 backupdrwx------ 2 postgres postgres 4096 апр 14 06:44 dumpdir-rw-rw-r-- 1 postgres postgres 14415122 апр 14 06:34 zabbix.dump-rw-rw-r-- 1 postgres postgres 55616031 апр 14 06:25 zabbix.sqlpostgres@singularity:~$ du dumpdir14708 dumpdirКопия кластера БД
pg_dumpall — выгрузить кластер баз данных PostgreSQL в формате скриптаpostgres@singularity:~$ pg_dumpall -f mainpostgres@singularity:~$ ls -ldrwxrwxr-x 2 postgres postgres 4096 апр 14 05:24 backupdrwx------ 2 postgres postgres 4096 апр 14 06:44 dumpdir-rw-rw-r-- 1 postgres postgres 112068105 апр 14 06:55 main
Настройка репликации main, beta (вариант 1, оба кластера работают на одном хосте)
Действия на кластере main
sudo nano /etc/postgresql/14/main/postgresql.conf
listen_addresses = '<IP-адрес сервера PostgreSQL с кластером main>'
sudo -u postgres psql
CREATE ROLE replicator WITH REPLICATION PASSWORD 'пароль replicator' LOGIN;
sudo nano /etc/postgresql/14/main/pg_hba.conf
host replication replicator 127.0.0.1/32 scram-sha-256
sudo systemctl restart postgresql@14-main
SHOW data_directory;
Задать параметры в /etc/postgresql/14/main/postgresql.conf
sudo nano /etc/postgresql/14/main/postgresql.conf
wal_level = replicawal_log_hints = onarchive_mode = onarchive_command = 'cp -i %p /var/lib/postgresql/archive/main/%f'max_wal_senders = 100hot_standby = on
Перезапустить кластер main
pg_ctlcluster stop 14 main
pg_ctlcluster start 14 main
sudo -u postgres pg_basebackup -h '127.0.0.1' -p 5432 -U replicator -D /var/lib/postgresql/14/beta/ -Fp -Xs -R
Здесь:
--tablespace-mapping). Это формат по умолчанию.Когда используется формат tar, файлы журнала предзаписи сохраняются в отдельном архиве с именем pg_wal.tar.
Это значение по умолчанию.
standby.signal и добавить параметры конфигурации в файл postgresql.auto.conf в целевом каталоге (или внутри архива, если используется формат tar). Это упрощает настройку ведомого сервера при восстановлении этой копии.
В файл postgresql.auto.conf будут записаны параметры соединения и слот репликации, если его использует pg_basebackup, так что впоследствии при потоковой репликации будут использоваться те же параметры.
sudo -u postgres psql
SELECT client_addr, state FROM pg_stat_replication;
Output
client_addr | state
------------------+-----------
<<IP-адрес сервера PostgreSQL с кластером beta> | streaming
SELECT * FROM pg_stat_replication \gx
postgres@singularity:~$ psql
psql (14.3 (Ubuntu 14.3-1.pgdg20.04+1))Введите "help", чтобы получить справку.
postgres=# SELECT * FROM pg_stat_replication \gx-[ RECORD 1 ]----+------------------------------pid | 300335usesysid | 40170usename | replicatorapplication_name | 14/betaclient_addr | 127.0.0.1client_hostname |client_port | 41576backend_start | 2022-06-08 17:37:37.66505+00backend_xmin |state | streamingsent_lsn | 16/A7EE29B0write_lsn | 16/A7EE29B0flush_lsn | 16/A7EE29B0replay_lsn | 16/A7EE29B0write_lag | 00:00:00.000256flush_lag | 00:00:00.000545replay_lag | 00:00:00.000592sync_priority | 0sync_state | asyncreply_time | 2022-06-08 17:53:19.371493+00
Действия на кластере beta
sudo -u postgres pg_dropcluster 14 beta
sudo -u postgres rm -r /var/lib/postgresql/14/beta
sudo -u postgres mkdir /var/lib/postgresql/14/beta
sudo -u postgres chmod 700 /var/lib/postgresql/14/beta
su -
chown postgres:postgres /var/lib/postgresql/14/beta/*
postgres@singularity:~$ mkdir /etc/postgresql/14/beta
postgres@singularity:~$ cp /etc/postgresql/14/main/postgresql.conf /etc/postgresql/14/beta/postgresql.conf
postgres@singularity:~$ mkdir /var/lib/postgresql/archive/beta/
postgres@singularity:~$ mkdir /etc/postgresql/14/beta/conf.d
nano /etc/postgresql/14/beta/postgresql.conf
cp /etc/postgresql/14/main/pg_hba.conf /etc/postgresql/14/beta/pg_hba.conf
cp /etc/postgresql/14/main/pg_ident.conf /etc/postgresql/14/beta/pg_ident.conf
Задать параметры в /etc/postgresql/14/beta/postgresql.conf
wal_level = replica
wal_log_hints = on
archive_mode = on
archive_command = 'cp -i %p /var/lib/postgresql/archive/beta/%f'
max_wal_senders = 100
hot_standby = on
sudo -u postgres pg_createcluster 14 beta
sudo systemctl restart postgresql@14-beta
Курсы для разработчика серверной части
Источники
DEV1 Разработка серверной части приложений PostgreSQL 12. Базовый курс (postgrespro.ru)
Репозитории GitHub
MVCC - Multiversion Concurrency Control, многоверсионное управление конкурентным доступом
Источники:
Заметки к книге Рогов Е. В. Р59 PostgreSQL 15 изнутри. — М.: ДМК Пресс, 2023. — 662 с. ISBN 978-5-93700-178-8
В книге рассматривается внутреннее устройство СУБД PostgreSQL: детали реализации многоверсионности и изоляции на основе снимков данных, включая процедуру очистки неактуальных версий строк; буферный кеш и журнал предзаписи; использование блокировок различных уровней; планирование и выполнение SQL-запросов; принципы расширяемости и особенности имеющихся индексных методов доступа. Большое внимание уделяется возможностям, предоставляемым для самостоятельного изучения механизмов функционирования PostgreSQL. В настоящем издании учтены замечания читателей и исправлены опечатки, а также отражены изменения, произошедшие в версии PostgreSQL 15. Сайт книги: https://postgrespro.ru/education/books/internals. Для администраторов и программистов.
Глава 11. Режимы журнала
wal_sync_method для Postgres Pro (исходник).Примеры выполнения.
1. student.lan (Oracle VM, xubuntu, диск ВМ на внешнем диске)
postgres@student:/etc/postgresql/12/main$ /usr/lib/postgresql/12/bin/pg_test_fsync
5 seconds per test
O_DIRECT supported on this platform for open_datasync and open_sync.
Compare file sync methods using one 8kB write:
(in wal_sync_method preference order, except fdatasync is Linux's default)
open_datasync 359,407 ops/sec 2782 usecs/op
fdatasync 372,340 ops/sec 2686 usecs/op
fsync 143,684 ops/sec 6960 usecs/op
fsync_writethrough n/a
open_sync 145,531 ops/sec 6871 usecs/op
Compare file sync methods using two 8kB writes:
(in wal_sync_method preference order, except fdatasync is Linux's default)
open_datasync 177,764 ops/sec 5625 usecs/op
fdatasync 321,705 ops/sec 3108 usecs/op
fsync 121,483 ops/sec 8232 usecs/op
fsync_writethrough n/a
open_sync 71,018 ops/sec 14081 usecs/op
Compare open_sync with different write sizes:
(This is designed to compare the cost of writing 16kB in different write
open_sync sizes.)
1 * 16kB open_sync write 125,003 ops/sec 8000 usecs/op
2 * 8kB open_sync writes 65,584 ops/sec 15248 usecs/op
4 * 4kB open_sync writes 32,748 ops/sec 30536 usecs/op
8 * 2kB open_sync writes 15,574 ops/sec 64211 usecs/op
16 * 1kB open_sync writes 7,363 ops/sec 135807 usecs/op
Test if fsync on non-write file descriptor is honored: (If the times are similar, fsync() can sync data written on a different descriptor.)
write, fsync, close 121,703 ops/sec 8217 usecs/op
write, close, fsync 129,187 ops/sec 7741 usecs/op
Non-sync'ed 8kB writes:
write 153025,891 ops/sec 7 usecs/op
2. VPS singularity.lytkins.ru (BeGet, Ubuntu 22.04.1).
postgres@singularity:~$ /usr/lib/postgresql/15/bin/pg_test_fsync
5 seconds per test
O_DIRECT supported on this platform for open_datasync and open_sync.
Compare file sync methods using one 8kB write:
(in wal_sync_method preference order, except fdatasync is Linux's default)
open_datasync 9174.853 ops/sec 109 usecs/op
fdatasync 8987.786 ops/sec 111 usecs/op
fsync 8339.495 ops/sec 120 usecs/op
fsync_writethrough n/a
open_sync 8348.133 ops/sec 120 usecs/op
Compare file sync methods using two 8kB writes:
(in wal_sync_method preference order, except fdatasync is Linux's default)
open_datasync 4622.513 ops/sec 216 usecs/op
fdatasync 8352.103 ops/sec 120 usecs/op
fsync 7935.690 ops/sec 126 usecs/op
fsync_writethrough n/a
open_sync 4478.802 ops/sec 223 usecs/op
Compare open_sync with different write sizes:
(This is designed to compare the cost of writing 16kB in different write
open_sync sizes.)
1 * 16kB open_sync write 8280.727 ops/sec 121 usecs/op
2 * 8kB open_sync writes 4340.611 ops/sec 230 usecs/op
4 * 4kB open_sync writes 2191.251 ops/sec 456 usecs/op
8 * 2kB open_sync writes 899.303 ops/sec 1112 usecs/op
16 * 1kB open_sync writes 487.776 ops/sec 2050 usecs/op
Test if fsync on non-write file descriptor is honored:
(If the times are similar, fsync() can sync data written on a different descriptor.)
write, fsync, close 8202.338 ops/sec 122 usecs/op
write, close, fsync 7979.933 ops/sec 125 usecs/op
Non-sync'ed 8kB writes:
write 1428417.859 ops/sec 1 usecs/op