GH GambleHub

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

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

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
-- на лидере
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; -- перезапуск
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 через archive_command или 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
-- вычисляйте bucket = hash(user_id) % 16, храните (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 в роутере чтений: выбираем реплику с last_lsn >= ctx.min_lsn, иначе лидер
Vitess VSchema (جزء):
json
{
"tables": {
"orders": { "column_vindexes": [{ "column": "tenant_id", "name": "hash" }] }
}
}

18)

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

Contact

اتصل بنا

تواصل معنا لأي أسئلة أو دعم.نحن دائمًا جاهزون لمساعدتكم!

بدء التكامل

البريد الإلكتروني — إلزامي. تيليغرام أو واتساب — اختياري.

اسمك اختياري
البريد الإلكتروني اختياري
الموضوع اختياري
الرسالة اختياري
Telegram اختياري
@
إذا ذكرت تيليغرام — سنرد عليك هناك أيضًا بالإضافة إلى البريد الإلكتروني.
WhatsApp اختياري
الصيغة: رمز الدولة + الرقم (مثال: +971XXXXXXXXX).

بالنقر على الزر، فإنك توافق على معالجة بياناتك.