vault backup: 2024-07-11 08:58:53

.obsidian/plugins/home-tab/data.json

@@ -25,7 +25,11 @@
   "recentFilesStore": [
     {
       "filepath": "_inbox/Асинхронная репликация.md",
-      "timestamp": 1720677062425
+      "timestamp": 1720677527995
+    },
+    {
+      "filepath": "_inbox/Отставание реплики в БД.md",
+      "timestamp": 1720677527014
     },
     {
       "filepath": "_inbox/Репликация БД.md",
@@ -38,10 +42,6 @@
     {
       "filepath": "_inbox/Репликация master-master.md",
       "timestamp": 1720676085556
-    },
-    {
-      "filepath": "_inbox/Журналы в MySQL.md",
-      "timestamp": 1720676038039
     }
   ],
   "bookmarkedFileStore": [],

.obsidian/plugins/recent-files-obsidian/data.json

@@ -4,6 +4,10 @@
       "basename": "Асинхронная репликация",
       "path": "_inbox/Асинхронная репликация.md"
     },
+    {
+      "basename": "Отставание реплики в БД",
+      "path": "_inbox/Отставание реплики в БД.md"
+    },
     {
       "basename": "Репликация БД",
       "path": "_inbox/Репликация БД.md"
@@ -168,10 +172,6 @@
       "basename": "Микросервисная архитектура",
       "path": "wiki/zero/Микросервисная архитектура.md"
     },
-    {
-      "basename": "Отставание реплики в БД",
-      "path": "_inbox/Отставание реплики в БД.md"
-    },
     {
       "basename": "Репликация в PostgreSQL",
       "path": "_inbox/Репликация в PostgreSQL.md"

_inbox/Асинхронная репликация.md

@@ -22,13 +22,17 @@ linked:
 **Как работает**
 - Подготовка транзакции в движке БД: Транзакция начинается на главном сервере, где собираются все изменения данных.
 - Запись транзакции в лог: Все изменения записываются в журнал транзакций (например, Write-Ahead Log в PostgreSQL).
-- Завершение транзакции в движке БД: Транзакция завершается на главном сервере, и клиент получает подтверждение.
+- Завершение транзакции в движке БД: Транзакция завершается на master.
+- Возврат результата клиенту: Клиент получает подтверждение о завершении транзакции
 - Пересылка лога репликам: Журнал транзакций отправляется на реплики для асинхронного применения изменений.
 - Воспроизведение транзакции на репликах: Реплики получают журнал и применяют изменения к своим копиям данных, но это может произойти с задержкой.
 
 **Плюсы**
-- Клиент быстрее получает ответ
+- Высокая производительность: Поскольку подтверждение транзакции возвращается клиенту до её применения на репликах, время отклика уменьшается, что улучшает производительность системы.
+- Уменьшенная нагрузка на сеть: Пересылка изменений на реплики происходит асинхронно, что снижает нагрузку на сеть и позволяет более эффективно использовать сетевые ресурсы.
+- Гибкость в использовании: Асинхронная репликация позволяет использовать реплики для различных задач, таких как отчеты или резервное копирование, без влияния на производительность главного сервера.
 
 **Минусы**
-- Если мастер упадет до отправки репликам, то данные могут потеряться.
+- Потеря данных при сбое: Если master выходит из строя до пересылки изменений на реплики, данные могут быть потеряны. Это может привести к несогласованности данных и необходимости восстановления системы.
-- [Отставание реплики в БД](Отставание%20реплики%20в%20БД.md)
+Отставание реплик: Задержка в применении изменений на репликах может привести к отставанию реплик от главного сервера, что может затруднить выполнение некоторых операций, требующих актуальных данных.
+Проблемы с консистентностью данных: Каждая реплика может отставать по разному, из-за этого данные могут быть несогласованными между репликами. Например, пользователь может получить разные результаты для одного и того же запроса.