mirror of
https://github.com/ClickHouse/ClickHouse.git
synced 2024-12-03 21:12:28 +00:00
cd14f9ebcb
* split up select.md * array-join.md basic refactoring * distinct.md basic refactoring * format.md basic refactoring * from.md basic refactoring * group-by.md basic refactoring * having.md basic refactoring * additional index.md refactoring * into-outfile.md basic refactoring * join.md basic refactoring * limit.md basic refactoring * limit-by.md basic refactoring * order-by.md basic refactoring * prewhere.md basic refactoring * adjust operators/index.md links * adjust sample.md links * adjust more links * adjust operatots links * fix some links * adjust aggregate function article titles * basic refactor of remaining select clauses * absolute paths in make_links.sh * run make_links.sh * remove old select.md locations * translate docs/es * translate docs/fr * translate docs/fa * remove old operators.md location * change operators.md links * adjust links in docs/es * adjust links in docs/es * minor texts adjustments * wip * update machine translations to use new links * fix changelog * es build fixes * get rid of some select.md links * temporary adjust ru links * temporary adjust more ru links * improve curly brace handling * adjust ru as well * fa build fix * ru link fixes * zh link fixes * temporary disable part of anchor checks
219 lines
22 KiB
Markdown
219 lines
22 KiB
Markdown
---
|
||
machine_translated: true
|
||
machine_translated_rev: 72537a2d527c63c07aa5d2361a8829f3895cf2bd
|
||
toc_priority: 31
|
||
toc_title: "\u062A\u06A9\u0631\u0627\u0631 \u062F\u0627\u062F\u0647 \u0647\u0627"
|
||
---
|
||
|
||
# تکرار داده ها {#table_engines-replication}
|
||
|
||
تکرار تنها برای جداول در خانواده ادغام پشتیبانی می شود:
|
||
|
||
- تکرار غذای اصلی
|
||
- تکرار می شود
|
||
- جایگزینی تکراری
|
||
- تکرار پلاکتی مگرمرگتری
|
||
- تکرار تغییرات
|
||
- تکرار مجدد محصول
|
||
- تکرار کننده
|
||
|
||
تکرار کار می کند در سطح یک جدول فردی, نه کل سرور. سرور می تواند هر دو جدول تکرار و غیر تکرار در همان زمان ذخیره کنید.
|
||
|
||
تکرار بستگی ندارد sharding. هر سفال تکرار مستقل خود را دارد.
|
||
|
||
داده های فشرده برای `INSERT` و `ALTER` نمایش داده شد تکرار شده است (برای اطلاعات بیشتر, اسناد و مدارک برای دیدن [ALTER](../../../sql-reference/statements/alter.md#query_language_queries_alter)).
|
||
|
||
`CREATE`, `DROP`, `ATTACH`, `DETACH` و `RENAME` نمایش داده شد بر روی یک سرور اجرا و تکرار نیست:
|
||
|
||
- این `CREATE TABLE` پرس و جو ایجاد یک جدول تکرار جدید بر روی سرور که پرس و جو اجرا شده است. اگر این جدول در حال حاضر بر روی سرور های دیگر وجود دارد, اضافه می کند یک ماکت جدید.
|
||
- این `DROP TABLE` پرس و جو حذف ماکت واقع در سرور که پرس و جو اجرا شده است.
|
||
- این `RENAME` پرس و جو تغییر نام جدول در یکی از کپی. به عبارت دیگر, جداول تکرار می توانید نام های مختلف در کپی های مختلف دارند.
|
||
|
||
استفاده از کلیک [سرویس پرداخت درونبرنامهای پلی](https://zookeeper.apache.org) برای ذخیره سازی اطلاعات متا کپی. استفاده از باغ وحش نسخه 3.4.5 یا جدیدتر.
|
||
|
||
برای استفاده از تکرار, پارامترهای مجموعه ای در [باغ وحش](../../../operations/server-configuration-parameters/settings.md#server-settings_zookeeper) بخش پیکربندی سرور.
|
||
|
||
!!! attention "توجه"
|
||
هنوز تنظیمات امنیتی غفلت نیست. تاتر از `digest` [طرح اکل](https://zookeeper.apache.org/doc/current/zookeeperProgrammers.html#sc_ZooKeeperAccessControl) از زیر سیستم امنیتی باغ وحش.
|
||
|
||
به عنوان مثال از تنظیم نشانی های خوشه باغ وحش:
|
||
|
||
``` xml
|
||
<zookeeper>
|
||
<node index="1">
|
||
<host>example1</host>
|
||
<port>2181</port>
|
||
</node>
|
||
<node index="2">
|
||
<host>example2</host>
|
||
<port>2181</port>
|
||
</node>
|
||
<node index="3">
|
||
<host>example3</host>
|
||
<port>2181</port>
|
||
</node>
|
||
</zookeeper>
|
||
```
|
||
|
||
شما می توانید هر خوشه باغ وحش موجود را مشخص کنید و سیستم یک دایرکتوری را برای داده های خود استفاده می کند (دایرکتوری هنگام ایجاد یک جدول تکرار شده مشخص می شود).
|
||
|
||
اگر باغ وحش در فایل پیکربندی تنظیم نشده, شما می توانید جداول تکرار ایجاد کنید, و هر جداول تکرار موجود خواهد شد فقط به عنوان خوانده شده.
|
||
|
||
باغ وحش در استفاده نمی شود `SELECT` نمایش داده شد به دلیل تکرار می کند عملکرد تاثیر نمی گذارد `SELECT` و نمایش داده شد اجرا فقط به همان سرعتی که برای جداول غیر تکرار انجام می دهند. هنگامی که پرس و جو جداول تکرار توزیع, رفتار کلیک است که توسط تنظیمات کنترل [\_شروع مجدد \_شروع مجدد \_شروع مجدد \_کاربری](../../../operations/settings/settings.md#settings-max_replica_delay_for_distributed_queries) و [شناسه بسته:](../../../operations/settings/settings.md#settings-fallback_to_stale_replicas_for_distributed_queries).
|
||
|
||
برای هر `INSERT` پرس و جو, حدود ده ورودی از طریق معاملات چند به باغ وحش دار اضافه. (به عبارت دقیق تر, این است که برای هر بلوک قرار داده شده از داده; پرس و جو درج شامل یک بلوک و یا یک بلوک در هر `max_insert_block_size = 1048576` ردیف) این منجر به زمان شروع کمی طولانی تر برای `INSERT` در مقایسه با جداول غیر تکرار. اما اگر شما به دنبال توصیه برای وارد کردن داده ها در دسته بیش از یک `INSERT` در هر ثانیه هیچ مشکلی ایجاد نمی کند. کل خوشه محل کلیک مورد استفاده برای هماهنگی یک خوشه باغ وحش در مجموع چند صد است `INSERTs` در هر ثانیه. توان در درج داده (تعداد ردیف در ثانیه) فقط به عنوان بالا به عنوان داده های غیر تکرار شده است.
|
||
|
||
برای خوشه های بسیار بزرگ, شما می توانید خوشه باغ وحش های مختلف برای خرده ریز های مختلف استفاده کنید. با این حال, این لازم در یاندکس ثابت نشده.متریکا خوشه (تقریبا 300 سرور).
|
||
|
||
تکرار ناهمزمان و چند استاد است. `INSERT` نمایش داده شد (و همچنین `ALTER`) را می توان به هر سرور در دسترس ارسال می شود. داده ها بر روی سرور قرار می گیرند که پرس و جو اجرا می شود و سپس به سرورهای دیگر کپی می شود. زیرا ناهمگام است, داده به تازگی قرار داده شده در کپی دیگر با برخی از تاخیر به نظر می رسد. اگر بخشی از کپی در دسترس نیست, داده ها نوشته شده است که در دسترس تبدیل. اگر یک ماکت در دسترس است, تاخیر مقدار زمان لازم برای انتقال بلوک از داده های فشرده بر روی شبکه است.
|
||
|
||
به طور پیش فرض, پرس و جو درج منتظر تایید نوشتن داده ها از تنها یک ماکت. اگر داده ها با موفقیت به تنها یک ماکت نوشته شده بود و سرور با این ماکت متوقف به وجود, داده های ذخیره شده از دست خواهد رفت. برای فعال کردن گرفتن تایید داده ها می نویسد: از کپی های متعدد با استفاده از `insert_quorum` انتخاب
|
||
|
||
هر بلوک از داده ها به صورت اتمی نوشته شده است. پرس و جو درج شده است را به بلوک تا تقسیم `max_insert_block_size = 1048576` ردیف به عبارت دیگر اگر `INSERT` پرس و جو کمتر از 1048576 ردیف, این است که به صورت اتمی ساخته شده.
|
||
|
||
بلوک های داده تقسیم می شوند. برای چند می نویسد از بلوک داده های مشابه (بلوک های داده از همان اندازه حاوی ردیف در همان جهت) بلوک تنها یک بار نوشته شده است. دلیل این کار این است که در صورت شکست شبکه زمانی که نرم افزار سرویس گیرنده نمی داند که اگر داده ها به دسی بل نوشته شده بود, بنابراین `INSERT` پرس و جو به سادگی می تواند تکرار شود. مهم نیست که درج ماکت با داده های یکسان فرستاده شد. `INSERTs` ژولیده اند. پارامترهای تقسیم بندی توسط [ادغام](../../../operations/server-configuration-parameters/settings.md#server_configuration_parameters-merge_tree) تنظیمات سرور.
|
||
|
||
در طول تکرار, تنها داده های منبع برای وارد کردن بر روی شبکه منتقل. تحول داده های بیشتر (ادغام) هماهنگ و در تمام کپی در همان راه انجام. این به حداقل می رساند استفاده از شبکه, به این معنی که تکرار خوبی کار می کند زمانی که کپی در مراکز داده های مختلف اقامت. (توجه داشته باشید که تکثیر داده ها در مراکز داده های مختلف هدف اصلی از تکرار است.)
|
||
|
||
شما می توانید هر تعداد از کپی از داده های مشابه داشته باشد. یاندکسمتریکا از تکرار دوگانه در تولید استفاده می کند. هر سرور با استفاده از حمله-5 و یا حمله-6, و حمله-10 در برخی موارد. این یک راه حل نسبتا قابل اعتماد و راحت است.
|
||
|
||
سیستم نظارت بر هماهنگ سازی داده ها در کپی و قادر به بازیابی پس از شکست است. عدم موفقیت خودکار است (برای تفاوت های کوچک در داده ها) و یا نیمه اتوماتیک (زمانی که داده ها متفاوت بیش از حد, که ممکن است یک خطای پیکربندی نشان می دهد).
|
||
|
||
## ایجاد جداول تکرار شده {#creating-replicated-tables}
|
||
|
||
این `Replicated` پیشوند به نام موتور جدول اضافه شده است. به عنوان مثال:`ReplicatedMergeTree`.
|
||
|
||
**تکرار \* پارامترهای ادغام**
|
||
|
||
- `zoo_path` — The path to the table in ZooKeeper.
|
||
- `replica_name` — The replica name in ZooKeeper.
|
||
|
||
مثال:
|
||
|
||
``` sql
|
||
CREATE TABLE table_name
|
||
(
|
||
EventDate DateTime,
|
||
CounterID UInt32,
|
||
UserID UInt32
|
||
) ENGINE = ReplicatedMergeTree('/clickhouse/tables/{layer}-{shard}/table_name', '{replica}')
|
||
PARTITION BY toYYYYMM(EventDate)
|
||
ORDER BY (CounterID, EventDate, intHash32(UserID))
|
||
SAMPLE BY intHash32(UserID)
|
||
```
|
||
|
||
<details markdown="1">
|
||
|
||
<summary>به عنوان مثال در نحو توصیه</summary>
|
||
|
||
``` sql
|
||
CREATE TABLE table_name
|
||
(
|
||
EventDate DateTime,
|
||
CounterID UInt32,
|
||
UserID UInt32
|
||
) ENGINE = ReplicatedMergeTree('/clickhouse/tables/{layer}-{shard}/table_name', '{replica}', EventDate, intHash32(UserID), (CounterID, EventDate, intHash32(UserID), EventTime), 8192)
|
||
```
|
||
|
||
</details>
|
||
|
||
به عنوان مثال نشان می دهد, این پارامترها می تواند تعویض در براکت فرفری شامل. مقادیر جایگزین از گرفته ‘macros’ بخش از فایل پیکربندی. مثال:
|
||
|
||
``` xml
|
||
<macros>
|
||
<layer>05</layer>
|
||
<shard>02</shard>
|
||
<replica>example05-02-1.yandex.ru</replica>
|
||
</macros>
|
||
```
|
||
|
||
مسیر به جدول در باغ وحش باید منحصر به فرد برای هر جدول تکرار شود. جداول در خرده ریز های مختلف باید مسیرهای مختلف داشته باشد.
|
||
در این مورد مسیر شامل قسمت های زیر است:
|
||
|
||
`/clickhouse/tables/` پیشوند رایج است. ما توصیه می کنیم با استفاده از دقیقا این یکی.
|
||
|
||
`{layer}-{shard}` شناسه سفال است. در این مثال شامل دو بخش از یاندکس.متریکا خوشه با استفاده از دو سطح شاردینگ. برای بسیاری از وظایف, شما می توانید فقط جایگزینی {سفال} ترک, خواهد شد که به شناسه سفال گسترش.
|
||
|
||
`table_name` نام گره برای جدول در باغ وحش است. این یک ایده خوب را به همان نام جدول است. این است که به صراحت تعریف, چرا که در مقابل به نام جدول, این کار پس از یک پرس و جو تغییر نام نمی.
|
||
*HINT*: شما می توانید یک نام پایگاه داده در مقابل اضافه کنید `table_name` همینطور E. g. `db_name.table_name`
|
||
|
||
نام ماکت شناسایی کپی های مختلف از همان جدول. شما می توانید نام سرور برای این استفاده, همانطور که در مثال. نام تنها نیاز به منحصر به فرد در هر سفال.
|
||
|
||
شما می توانید پارامترهای صراحت به جای استفاده از تعویض تعریف کنیم. این ممکن است مناسب برای تست و برای پیکربندی خوشه های کوچک. با این حال, شما می توانید نمایش داده شد توزیع دی ال استفاده کنید (`ON CLUSTER`) در این مورد.
|
||
|
||
هنگام کار با خوشه های بزرگ, توصیه می کنیم با استفاده از تعویض زیرا احتمال خطا را کاهش می دهد.
|
||
|
||
اجرای `CREATE TABLE` پرس و جو در هر ماکت. این پرس و جو ایجاد یک جدول تکرار جدید, و یا می افزاید: یک ماکت جدید به یک موجود.
|
||
|
||
اگر شما اضافه کردن یک ماکت جدید پس از جدول در حال حاضر شامل برخی از داده ها در کپی های دیگر کپی داده ها از کپی های دیگر کپی به یکی از جدید پس از اجرای پرس و جو. به عبارت دیگر, ماکت جدید خود را با دیگران همگام سازی.
|
||
|
||
برای حذف یک ماکت, اجرا `DROP TABLE`. However, only one replica is deleted – the one that resides on the server where you run the query.
|
||
|
||
## بازیابی پس از شکست {#recovery-after-failures}
|
||
|
||
اگر باغ وحش در دسترس نیست که یک سرور شروع می شود, جداول تکرار تبدیل به حالت فقط خواندنی. این سیستم به صورت دوره ای تلاش برای اتصال به باغ وحش.
|
||
|
||
اگر باغ وحش در طول یک در دسترس نیست `INSERT`, یا یک خطا رخ می دهد در هنگام تعامل با باغ وحش, یک استثنا پرتاب می شود.
|
||
|
||
پس از اتصال به باغ وحش, سیستم چک چه مجموعه ای از داده ها در سیستم فایل محلی منطبق بر مجموعه مورد انتظار از داده ها (باغ وحش ذخیره این اطلاعات). اگر تناقضات کوچک وجود دارد, سیستم با همگام سازی داده ها با کپی حل.
|
||
|
||
اگر سیستم تشخیص داده های شکسته قطعات (با اندازه اشتباه از فایل ها) و یا قطعات ناشناخته (قطعات نوشته شده به فایل سیستم اما ثبت نشده در باغ وحش) این حرکت را به `detached` دایرکتوری فرعی(حذف نمی شوند). هر بخش از دست رفته از کپی کپی کپی کپی.
|
||
|
||
توجه داشته باشید که تاتر هیچ اقدامات مخرب مانند به طور خودکار حذف مقدار زیادی از داده ها را انجام نمی دهد.
|
||
|
||
هنگامی که سرور شروع می شود (و یا ایجاد یک جلسه جدید با باغ وحش), این تنها چک مقدار و اندازه تمام فایل های. اگر اندازه فایل مطابقت اما بایت در جایی در وسط تغییر یافته است, این بلافاصله شناسایی نشده, اما تنها زمانی که تلاش برای خواندن داده ها برای یک `SELECT` پرس و جو. پرس و جو می اندازد یک استثنا در مورد کنترلی غیر تطبیق و یا اندازه یک بلوک فشرده. در این مورد, قطعات داده ها به صف تایید اضافه شده و کپی از کپی در صورت لزوم.
|
||
|
||
اگر مجموعه ای محلی از داده های متفاوت بیش از حد از یک انتظار, یک مکانیزم ایمنی باعث شده است. سرور وارد این در ورود به سیستم و حاضر به راه اندازی. دلیل این کار این است که این مورد ممکن است یک خطای پیکربندی نشان می دهد, مانند اگر یک ماکت در سفال به طور تصادفی مانند یک ماکت در سفال های مختلف پیکربندی شده بود. با این حال, مانع برای این مکانیزم نسبتا کم, و این وضعیت ممکن است در طول بهبود شکست طبیعی رخ می دهد. در این مورد داده ها به صورت نیمه اتوماتیک بازسازی می شوند “pushing a button”.
|
||
|
||
برای شروع بازیابی گره ایجاد کنید `/path_to_table/replica_name/flags/force_restore_data` در باغ وحش با هر یک از مطالب, و یا اجرای دستور برای بازگرداندن تمام جداول تکرار:
|
||
|
||
``` bash
|
||
sudo -u clickhouse touch /var/lib/clickhouse/flags/force_restore_data
|
||
```
|
||
|
||
سپس سرور راه اندازی مجدد. در ابتدا سرور این پرچم ها را حذف می کند و شروع به بازیابی می کند.
|
||
|
||
## بازیابی پس از از دست دادن اطلاعات کامل {#recovery-after-complete-data-loss}
|
||
|
||
اگر تمام داده ها و ابرداده از یکی از سرورها ناپدید شد, این مراحل را برای بازیابی دنبال:
|
||
|
||
1. نصب کلیک بر روی سرور. تعریف تعویض به درستی در فایل پیکربندی که شامل شناسه سفال و کپی, در صورت استفاده از.
|
||
2. اگر شما تا به حال جداول سه برابر است که باید به صورت دستی بر روی سرور تکرار, کپی اطلاعات خود را از یک ماکت (در دایرکتوری `/var/lib/clickhouse/data/db_name/table_name/`).
|
||
3. تعاریف جدول کپی واقع در `/var/lib/clickhouse/metadata/` از یک ماکت. اگر یک شناسه سفال یا ماکت به صراحت در تعاریف جدول تعریف, اصلاح به طوری که به این ماکت مربوط. (متناوبا, شروع سرور و تمام `ATTACH TABLE` نمایش داده شد که باید در شده .در حال بارگذاری `/var/lib/clickhouse/metadata/`.)
|
||
4. برای شروع بازیابی, ایجاد گره باغ وحش `/path_to_table/replica_name/flags/force_restore_data` با هر محتوا, و یا اجرای دستور برای بازگرداندن تمام جداول تکرار: `sudo -u clickhouse touch /var/lib/clickhouse/flags/force_restore_data`
|
||
|
||
سپس سرور شروع (راه اندازی مجدد, اگر در حال حاضر در حال اجرا). داده خواهد شد از کپی دانلود.
|
||
|
||
گزینه بازیابی جایگزین این است که حذف اطلاعات در مورد ماکت از دست رفته از باغ وحش (`/path_to_table/replica_name`), سپس ایجاد ماکت دوباره به عنوان شرح داده شده در “[ایجاد جداول تکرار شده](#creating-replicated-tables)”.
|
||
|
||
در طول بازیابی هیچ محدودیتی در پهنای باند شبکه وجود ندارد. این را در ذهن اگر شما در حال بازگرداندن بسیاری از کپی در یک بار.
|
||
|
||
## تبدیل از ادغام به تکرار غذای اصلی {#converting-from-mergetree-to-replicatedmergetree}
|
||
|
||
ما از اصطلاح استفاده می کنیم `MergeTree` برای اشاره به تمام موتورهای جدول در `MergeTree family`, همان است که برای `ReplicatedMergeTree`.
|
||
|
||
اگر شما تا به حال `MergeTree` جدول که به صورت دستی تکرار شد, شما می توانید به یک جدول تکرار تبدیل. شما ممکن است نیاز به انجام این کار اگر شما در حال حاضر مقدار زیادی از داده ها در یک `MergeTree` جدول و در حال حاضر شما می خواهید برای فعال کردن تکرار.
|
||
|
||
اگر داده ها در کپی های مختلف متفاوت, برای اولین بار همگام سازی, و یا حذف این داده ها در تمام کپی به جز یکی.
|
||
|
||
تغییر نام جدول ادغام موجود, سپس ایجاد یک `ReplicatedMergeTree` جدول با نام های قدیمی.
|
||
انتقال داده ها از جدول قدیمی به `detached` دایرکتوری فرعی در داخل دایرکتوری با داده های جدول جدید (`/var/lib/clickhouse/data/db_name/table_name/`).
|
||
سپس اجرا کنید `ALTER TABLE ATTACH PARTITION` در یکی از کپی برای اضافه کردن این قطعات داده به مجموعه کار.
|
||
|
||
## تبدیل از تکراری به ادغام {#converting-from-replicatedmergetree-to-mergetree}
|
||
|
||
ایجاد یک جدول ادغام با نام های مختلف. انتقال تمام داده ها از دایرکتوری با `ReplicatedMergeTree` داده های جدول به دایرکتوری داده جدول جدید. سپس حذف `ReplicatedMergeTree` جدول و راه اندازی مجدد سرور.
|
||
|
||
اگر شما می خواهید برای خلاص شدن از شر `ReplicatedMergeTree` جدول بدون راه اندازی سرور:
|
||
|
||
- حذف متناظر `.sql` پرونده در فهرست راهنمای فراداده (`/var/lib/clickhouse/metadata/`).
|
||
- حذف مسیر مربوطه در باغ وحش (`/path_to_table/replica_name`).
|
||
|
||
بعد از این, شما می توانید سرور راه اندازی, ایجاد یک `MergeTree` جدول, انتقال داده ها به دایرکتوری خود, و سپس راه اندازی مجدد سرور.
|
||
|
||
## بازیابی هنگامی که ابرداده در خوشه باغ وحش از دست داده و یا صدمه دیده است {#recovery-when-metadata-in-the-zookeeper-cluster-is-lost-or-damaged}
|
||
|
||
اگر داده های موجود در باغ وحش از دست رفته یا صدمه دیده بود می توانید داده ها را با حرکت دادن به یک جدول بدون علامت همانطور که در بالا توضیح داده شد ذخیره کنید.
|
||
|
||
[مقاله اصلی](https://clickhouse.tech/docs/en/operations/table_engines/replication/) <!--hide-->
|