شحن قاعدة البيانات وتكرارها

1) لماذا تحتاجه

وعندما يصبح الترقية الرأسية لقاعدة البيانات متجاوزة لوحدة المعالجة المركزية/IO/RAM أو مجموعة واحدة SPOF، يأتي التكرار (للقراءات/HA) والشحن (للكتابة/توزيع البيانات). الأهداف:

الإنتاجية (اكتب النمو الأفقي QPS).
التوفر (فشل سريع، لا نقطة فشل واحدة).
توطين البيانات (مناطق متعددة، زمن انتقال منخفض).
عزل الجيران الصاخبين (المستأجرين الساخنين/المفاتيح الساخنة).

2) المصطلحات الأساسية ونماذج الاتساق

Primary/Leader ↔ Replica/Follower: اكتب عن القائد، اقرأ على النسخ المتماثلة.
النسخ المتزامن: تأكيد المعاملات بعد الكتابة على عقد N (انخفاض RPO، زمن انتقال أعلى).
غير متزامن: يلتزم القائد ويرسل السجل لاحقًا (RPO> 0، زمن انتقال منخفض).
النصاب (Raft/Paxos): الكتابة إلى معظم العقد ؛ سجل واحد، قائد تلقائي.
القراءة بعد الكتابة: قراءة مضمونة لسجلاتها (انظر الفقرة 5).

نقرأ CAP في المبيعات مثل هذه: في حالة مشاكل الشبكة، تختار الاتساق (CP) أو التوافر (AP) للعمليات الهامة، وغالبًا ما تجمع المستويات على مسارات مختلفة.

3) التكرار: الخيارات والممارسات

3. 1 مادي ومنطقي

فيزيائي (WAL/redo/binlog): أقرب إلى سجل الكتلة، بسيط وسريع ؛ يقتصر على الطوبولوجيا/النسخة المتجانسة.
المنطقي: تدفق DML/DDL على مستوى الصف/الجدول ؛ يسمح بالنسخ المتماثلة الجزئية، والهجرات عبر الإصدارات، و CDC لـ DWH/البث.

3. 2 الإعداد والإدارة

رصد التأخر (الوقت/البايت/LSN).
الحد من التعليقات الاحتياطية الساخنة والطلبات الطويلة على النسخ المتماثلة (حتى لا تمنع المكنسة الكهربائية/التنظيف).
لـ MySQL - GTID و Orchestrator ؛ для PostgreSQL - Patroni/replication slots، synchronous_standby_names.

PostgreSQL (نسخة طبق الأصل متزامنة، جزء):

sql
-- on leader
ALTER SYSTEM SET synchronous_commit = 'on';
ALTER SYSTEM SET synchronous_standby_names = 'FIRST 1 (standby_a, standby_b)';
SELECT pg_reload_conf();

MySQL GTID (معرف المعاملة):

sql
SET GLOBAL enforce_gtid_consistency = ON;
SET GLOBAL gtid_mode = ON; -- restart
CHANGE MASTER TO MASTER_AUTO_POSITION=1;

3. 3 طوبولوجيات

1→N (القائد → نسخة طبق الأصل) + السلاسل التعاقبية (يتم دمج نسخة طبق الأصل أكثر).
متعدد الأولويات (نشط) - تجنب في OLTP دون إدارة صارمة للنزاعات.
مجموعة النصاب (الطوافة) - إضافات CockroachDB/Yugabyte/PG-Raft.

4) اقرأ/اكتب الانقسام والتوجيه

اكتب دائما كقائد ؛ اقرأ من الإشارات، ولكن ضع في اعتبارك التأخر.

استراتيجيات القراءة بعد الكتابة:

1. ثبات الجلسة: بعد التسجيل الناجح، يقرأ العميل من القائد خلال «Δ T».

2. بوابة LSN/GTID: يقول العميل «أريد ألا أتقدم في السن LSN = X»، يرسل جهاز التوجيه إلى النسخة المقلدة، التي LSN ≥ X.

3. Stale-ok: بعض الاستفسارات تسمح ببيانات قديمة (أدلة/أشرطة).

الأدوات: PgBouncer/Pgpool-II (Postgres)، ProxySQL/MaxScale (MySQL)، Vitess (توجيه القش).

مثال على بوابة LSN (فكرة): وفر 'pg _ current _ wal _ lsn ()' على رأس/ملف تعريف ارتباط HTTP واطلب من جهاز التوجيه نسخة طبق الأصل مع 'pg _ last _ wal _ replay _ lsn () ≥ LSN'.

5) استراتيجيات الشحن

5. 1 اختيار المفتاح

ويكفل المفتاح توحيد الطلبات ومواقعها:

Hash by 'tenant _ id '/' user _ id' - بالتساوي، لكنه يحرم عمليات مسح النطاق.
النطاق في الوقت/المعرف - رائع للسلسلة الزمنية/الأرشيف، لكنه يخاطر بشظية ساخنة.
التجزئة المتسقة - تجعل من السهل إضافة/إزالة الشظايا.
الدليل/جدول البحث - مرن (أي خوارزمية)، ولكن جدول/مخبأ آخر.

5. 2 أنماط

لا شيء مشترك: كل قطعة هي قاعدة بيانات/مجموعة منفصلة، يعرف التطبيق التوجيه.
Middleware-sharding: Vitess (MySQL)، Citus (Postgres)، Proxy-level يخفي الطوبولوجيا.
الاتحاد: فصل مجالات البيانات حسب الخدمات (الكتالوج، المدفوعات، auth).

5. 3 مفاتيح مركبة

استخدم مساحة المفتاح: '{مستأجر}: {كيان}: {معرف}' وتخزينه في التطبيق والمخبأ. Для Postgres - تجزئة التجزئة + LIST/RANGE subpartition.

تقسيم PostgreSQL (جزء):

sql
CREATE TABLE orders (
tenant_id int,
id     bigint,
created_at timestamptz,
...,
PRIMARY KEY (tenant_id, id)
) PARTITION BY HASH (tenant_id);

CREATE TABLE orders_t0 PARTITION OF orders FOR VALUES WITH (MODULUS 16, REMAINDER 0);
--... t1..t15

6) جيل الهوية

تجنب الزيادات التلقائية الرتيبة «الساخنة» عند الشحن.
استخدم معرف 64 بت شبيه بندفة الثلج (الوقت + المنطقة + الشارد + seq) أو ULID/KSUID (الرتابة والتوزيع).
Для Postgres - تسلسل لكل قطعة ؛ لـ MySQL - auto_increment_increment/offset (تعويضات مختلفة على قادة الشظايا).

7) الإفراط في المشاركة والهجرة عبر الإنترنت

المبادئ الرئيسية: الكتابة المزدوجة، والخصوصية، والتوجيه المزدوج المؤقت.

الخطوات (المعممة):

1. أضف قطعة/مجموعة جديدة.

2. مكّن ثنائي القراءة (فحص الاتساق).

3. تشمل الكتابة المزدوجة (في كلتا الشظتين)، وتناقضات قياسية.

4. ردم البيانات التاريخية (دفعات، تكرار منطقي/CDC).

5. تحويل «مصدر الحقيقة» إلى قطعة جديدة ؛ ترك تزامن «الذيل».

6. قم بإيقاف تشغيل القديم.

الأدوات: Vitess Resharding، Citus move shards، pg_logical/pgoutput، Debezium (CDC)، gh-ost/pt-online-schema-change (DDL بدون أقفال).

8) التوزيع المتعدد المناطق والجغرافي

متابع القائد لكل منطقة: قراءات محلية، اكتب - من خلال الرائد العالمي (نموذج بسيط، ولكن عبر المنطقة RTT).
متعدد القادة: التسجيل في كلا المنطقتين - تحتاج إلى إثارة النزاعات (timetamp/version/CRDT).
SQL الموزع الحقيقي (Raft): CockroachDB/Yugabyte - البيانات «ملتصقة» بالمنطقة، والاستفسارات تذهب إلى النصاب المحلي.

التوصيات:

المال/الطلبات - CP (النصاب/القائد)، الأدلة/الأشرطة - AP (مخبأ، في النهاية).
خطط دائمًا لكتابة سياج (مفاتيح/إصدار فريد) مع احتمال انقسام الدماغ.

9) الاتساق في الممارسة

اقرأ كتاباتك: القائد أو الإشارة التي «لحقت» بشبكة LSN/GTID.
يقرأ Monotonic: «ليس أقدم» من قراءة LSN الأخيرة.
التحكم في نزاع الكتابة: "حدد... للتحديث '، الإصدارات («xmin »/« rowversion»)، UPSERT مع التحقق من الإصدار.
الاختصاص: مفاتيح الاختصاص في المدفوعات/الأحداث.

10) إمكانية الملاحظة و SLO والتنبيهات

تأخر النسخ المقلدة: الوقت (الثواني)، مسافة LSN (بايت)، seconds_behind_master (MySQL).
التراجع القسري/النزاعات، أخطاء التكرار.
p95/p99 زمن الوصول по الطريق (اقرأ القائد مقابل نسخة طبق الأصل، اكتب).
الإنتاجية: TPS/الأقفال/الجداول المتنازع عليها.
Bloat/VACUUM (PG)، نسبة ضرب حمام السباحة المؤقت InnoDB (MySQL).
لوحات القيادة: حمل لكل شظية، شظايا «ساخنة»، توزيع المفتاح.

11) النسخ الاحتياطية و PITR و DR

النسخ الاحتياطي الكامل + WAL/binlog لـ PITR (استرداد نقطة زمنية).
تخزين في منطقة/سحابة أخرى، قم باستعادة الاختبارات بانتظام.
بالنسبة للشظايا، «شريحة» ثابتة (تنسيق الوقت/LSN) أو التطرف التطبيقي على الاسترداد.
تتم كتابة واختبار RPOs/RTOs في أيام اللعبة.

دعم قاعدة PostgreSQL (فكرة):

bash pg_basebackup -D/backups/base -X stream -C -S slot_replica_1 WAL archiving via archive_command or pgBackRest/Barman

12) الأمن والوصول

التجزئة بواسطة VPC/ACL، mTLS بالوكالة.
الأدوار/المنح على أساس مبدأ الحقوق الدنيا ؛ فرادى المستخدمين لكل قطعة/دور.
مراجعة DDL/DCL، حدود الطلبات «الثقيلة» على النسخ المتماثلة.
التشفير عند الراحة (KMS) وعند العبور (TLS).
زر الذعر: «اقرأ فقط» العالمي طوال مدة الحادث/التحقيق.

13) الأدوات والطوب

PostgreSQL: Patroni (HA)، PgBouncer (تجميع/توجيه RO)، repmgr، pgBackRest/Barman (бэкап)، Citus (шардинг)، Pglogical/Logical Replication، pgbadger/pg_stat_statements.
MySQL: Orchestrator (طوبولوجيا/فشل تلقائي)، ProxySQL/MaxScale (توجيه)، Percona XtraBackup (احتياطي)، مجموعة تكرار المجموعة/InnoDB، Vitess (شحن/إعادة).
Distributed SQL: CockroachDB، YugabyteDB (نصاب، شق مدمج/تحديد الموقع الجغرافي).
مركز السيطرة على الأمراض: Debezium + Kafka/Pulsar للأحداث/ETL.

14) الأنماط المضادة

ابتدائي واحد بدون فشل تلقائي وبدون اختبارات DR.
تقسيم القراءة «السحري» باستثناء التأخر → الأخطاء الوهمية/الأخطاء المشبوهة.
الشحن «من أجل الشحن»: التعقيد السابق لأوانه بدلاً من المقياس الرأسي/الفهارس/المخبأ.
نطاق ساخن (نطاق زمني) بدون دلو زمني/ملح هاش → تذوب قطعة واحدة.
2PC الصفقة العالمية بالإضافة إلى عشرات الشظايا في OLTP - ذيل p99 عالي وأقفال متكررة.
نقص الكتابة المزدوجة/القراءة المزدوجة أثناء الهجرات → فقدان/عدم التزامن.
DDL في حث بدون أدوات عبر الإنترنت وبدون توافق أعلام الميزات.

15) قائمة التنفيذ المرجعية (0-60 يوما)

0-15 أيام

تعريف DB SLO، RPO/RTO.
مكّن النسخ المتماثل، مراقبة التأخر، النسخ الاحتياطية الأساسية + PITR.
أدخل جهاز التوجيه (PgBouncer/ProxySQL) وسياسة القراءة بعد الكتابة.

16-30 يومًا

اختر استراتيجية الشحن، ووصف المفاتيح والمخططات.
قم بإعداد أدوات الشحن الزائد (Vitess/Citus/CDC).
دليل الخدمات/الجداول التي تحمل علامة "read-stale-ok" مقابل "strict'.

31-60 يومًا

قم بتشغيل شظية تجريبية وقراءة مزدوجة وردم.
يوم اللعبة: فشل القائد، التعافي من PITR، تبديل المنطقة.
أتمتة مفتاح القشرة الساخنة والإبلاغ عن عدم التكافؤ.

16) مقاييس النضج

نسخة طبق الأصل lag p95 <الهدف (على سبيل المثال 500 مللي ثانية) للقراءات النقدية.
اختبارات DR الناجحة ≥ 1/ربع (استعادة ≤ RTO، وفقدان RPO ≤).
توزيع الأحمال حسب الشظايا: اختلال التوازن <20٪ بواسطة QPS/التخزين.
النسبة المئوية للطلبات ذات الاتساق الصارم الموجهة بشكل صحيح = 100٪.
صفر فقدان البيانات في الحوادث التي تتطلب ضمانات CP (المال/الطلبات).
DDL/الهجرة عبر الإنترنت دون توقف، مع أعلام التوافق.

17) أمثلة وصفة

هاش ملح لمدى زمني (حتى لا تسخن قطعة واحدة):

sql
-- calculate bucket = hash (user_id)% 16, store (bucket, created_at)
PARTITION BY LIST (bucket) SUBPARTITION BY RANGE (created_at)

Read-my-writs middleware (pseudocode):

python lsn = db. leader_query("SELECT pg_current_wal_lsn()")
ctx. sticky_until = now()+5s ctx. min_lsn = lsn in the read router: select a replica with last_lsn> = ctx. min_lsn, otherwise the leader

Vitess VSchema (جزء):

json
{
"tables": {
"orders": { "column_vindexes": [{ "column": "tenant_id", "name": "hash" }] }
}
}

18)

لا يعد التشظي والتكرار تقنية فحسب، بل هما أيضًا عمليتان: التوجيه الواعي بالاتساق، وانضباط الهجرة (الكتابة/القراءة المزدوجة، والملء العكسي)، واختبارات DR المنتظمة، وإمكانية ملاحظة التأخير/القشرة الساخنة. ابدأ leader→replica بسيطة + اقرأ بعد الكتابة، ثم أضف الشحن حيث يتطلب ملف تعريف الحمل ذلك حقًا. استخدم منصات جاهزة (Vitess/Citus/Distributed SQL) واحتفظ ببيانات الأعمال الحرجة في وضع CP - بهذه الطريقة ستتوقف القاعدة عن أن تكون عنق الزجاجة وتصبح أساسًا مرنًا يمكن التنبؤ به للمنصة.

شحن قاعدة البيانات وتكرارها