vault backup: 2024-06-20 19:27:42

This commit is contained in:
Struchkov Mark 2024-06-20 19:27:42 +03:00
parent 1de17d4463
commit 8660d9e939
No known key found for this signature in database
GPG Key ID: A3F0AC3F0FA52F3C
5 changed files with 29 additions and 27 deletions

View File

@ -24,24 +24,24 @@
"unresolvedLinks": false,
"recentFilesStore": [
{
"filepath": "_inbox/Two Phase Lock.md",
"timestamp": 1718899990393
"filepath": "knowledge/dev/database/Свойства транзакции БД (ACID).md",
"timestamp": 1718900804605
},
{
"filepath": "_inbox/Транзакция БД.md",
"timestamp": 1718900696331
},
{
"filepath": "_inbox/Блокировки.md",
"timestamp": 1718899989152
"timestamp": 1718900690887
},
{
"filepath": "Home.md",
"timestamp": 1718899956245
"filepath": "_inbox/Журналы в MySQL.md",
"timestamp": 1718900595131
},
{
"filepath": "_inbox/Фантомное чтение.md",
"timestamp": 1718865945013
},
{
"filepath": "_inbox/Потерянное обновление.md",
"timestamp": 1718865699169
"filepath": "_inbox/Two Phase Lock.md",
"timestamp": 1718899990393
}
],
"bookmarkedFileStore": [],

View File

@ -1,13 +1,25 @@
{
"recentFiles": [
{
"basename": "Two Phase Lock",
"path": "_inbox/Two Phase Lock.md"
"basename": "Свойства транзакции БД (ACID)",
"path": "knowledge/dev/database/Свойства транзакции БД (ACID).md"
},
{
"basename": "Транзакция БД",
"path": "_inbox/Транзакция БД.md"
},
{
"basename": "Блокировки",
"path": "_inbox/Блокировки.md"
},
{
"basename": "Журналы в MySQL",
"path": "_inbox/Журналы в MySQL.md"
},
{
"basename": "Two Phase Lock",
"path": "_inbox/Two Phase Lock.md"
},
{
"basename": "Home",
"path": "Home.md"
@ -36,10 +48,6 @@
"basename": "MVCC",
"path": "_inbox/MVCC.md"
},
{
"basename": "Транзакция БД",
"path": "_inbox/Транзакция БД.md"
},
{
"basename": "Repeatable read",
"path": "_inbox/Repeatable read.md"
@ -92,10 +100,6 @@
"basename": "00 NoSQL",
"path": "wiki/zero/00 NoSQL.md"
},
{
"basename": "Свойства транзакции БД (ACID)",
"path": "knowledge/dev/database/Свойства транзакции БД (ACID).md"
},
{
"basename": "Вопросы для собеседование Java",
"path": "notes/Собеседования/Вопросы для собеседование Java.md"
@ -195,10 +199,6 @@
{
"basename": "LSM дерево",
"path": "_inbox/LSM дерево.md"
},
{
"basename": "B-tree",
"path": "_inbox/B-tree.md"
}
],
"omittedPaths": [],

View File

@ -19,7 +19,7 @@ linked:
Примерно в это же время MySQL подарили новый Storage Engine, который называется InnoDB. Это широко используемая штука, и в InnoDB свой журнал. Получилось два журнала InnoDB и Binary Log. Этот момент стал точкой невозврата, после чего появились проблемы, которые решить очень тяжело.
Binary Log не используется для [Point In Time Recovery](Point%20In%20Time%20Recovery%20(PITR).md), а InnoDB Undo/Redo Log не используется в репликации. Получилось, что у PostgreSQL журнал один, а у MySQL их, как бы, два.
Binary Log не используется для [Point In Time Recovery](Point%20In%20Time%20Recovery%20(PITR).md), а InnoDB Undo/Redo Log не используется в репликации. Получилось, что у PostgreSQL журнал один, а у MySQL их, как бы, два.
## InnoDB Undo/Redo Log
## Binary Log
У Binary Log, который нужен для репликации, есть два или три формата (типа).

View File

@ -30,3 +30,5 @@ linked:
**Уровни изоляций транзакций БД:**
![Уровни изоляций транзакций БД](Уровни%20изоляций%20транзакций%20БД.md)
## Дополнительные материалы
- [Транзакции. Восстановление. Классический алгоритм — Викиконспекты](https://neerc.ifmo.ru/wiki/index.php?title=%D0%A2%D1%80%D0%B0%D0%BD%D0%B7%D0%B0%D0%BA%D1%86%D0%B8%D0%B8._%D0%92%D0%BE%D1%81%D1%81%D1%82%D0%B0%D0%BD%D0%BE%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5._%D0%9A%D0%BB%D0%B0%D1%81%D1%81%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D0%B9_%D0%B0%D0%BB%D0%B3%D0%BE%D1%80%D0%B8%D1%82%D0%BC)

View File

@ -13,7 +13,7 @@ linked:
---
**Атомарность (atomicity).** Гарантирует, что никакая транзакция не будет зафиксирована в системе частично. Будут либо выполнены все её подоперации, либо не выполнено ни одной. Благодаря этому появляется возможность повторить прерванную транзакцию, не опасаясь, что часть операций уже выполнена.
**Согласованность (consistency).** Транзакция, достигающая своего нормального завершения и, тем самым, фиксирующая свои результаты, сохраняет согласованность базы данных. По сути поддержание согласованности задача приложения, а не базы.б
**Согласованность (consistency).** Транзакция, достигающая своего нормального завершения и, тем самым, фиксирующая свои результаты, сохраняет согласованность базы данных. По сути поддержание согласованности задача приложения, а не базы.
**Изолированность (isolation).** Во время выполнения транзакции параллельные транзакции не должны оказывать влияние на её результат. Защищает от [Race condition](Race%20condition.md).