PostgreSQL 18 में लगभग तुरंत database clone लागू करना

 (boringsql.com)
1 पॉइंट द्वारा GN⁺ 2025-12-24 | अभी कोई टिप्पणी नहीं है. | WhatsApp पर शेयर करें
  • PostgreSQL 18, फ़ाइल कॉपी रणनीति (FILE_COPY) और फ़ाइल सिस्टम clone फ़ीचर को मिलाकर database को लगभग तुरंत clone कर सकता है
  • नया configuration value file_copy_method = clone इस्तेमाल करने पर XFS, ZFS, APFS जैसे आधुनिक file system के clone फ़ीचर (FICLONE) का उपयोग किया जा सकता है
  • benchmark नतीजों में, 6GB database को clone करते समय मौजूदा WAL_LOG तरीका लगभग 67 सेकंड लेता है, जबकि clone तरीका लगभग 0.2 सेकंड में पूरा होता है
  • clone किया गया database शुरुआत में वही physical block साझा करता है, लेकिन write होने पर copy-on-write के ज़रिए अलग हो जाता है
  • हालांकि, सिर्फ तब clone किया जा सकता है जब कोई active connection न हो, और यह केवल एक ही file system के भीतर काम करता है

PostgreSQL की template-आधारित cloning संरचना

  • PostgreSQL में CREATE DATABASE dbname कमांड चलाने पर अंदरूनी रूप से template1 database को clone करके नया database बनाया जाता है
    • यह CREATE DATABASE dbname TEMPLATE template1 के समान व्यवहार है
  • template1 की जगह किसी दूसरे database को चुना जा सकता है, इसलिए custom template का उपयोग करके cloning संभव है
  • PostgreSQL 18 में इसी template system को लगभग तुरंत clone किए जा सकने वाले ढांचे तक बढ़ाया गया है

CREATE DATABASE ... STRATEGY

  • PostgreSQL 15 से CREATE DATABASE ... STRATEGY parameter जोड़ा गया, जिससे cloning method चुनना संभव हुआ
    • default WAL_LOG है, जो Write-Ahead Log के ज़रिए block-level cloning करता है
    • यह तरीका I/O load कम करता है और concurrency support बेहतर बनाता है, लेकिन बड़े clone में धीमा है
  • STRATEGY=FILE_COPY देने पर पुराने file copy तरीके पर लौटा जा सकता है, और PostgreSQL 18 में इसी के आधार पर नया cloning option जोड़ा गया है

FILE_COPY और file_copy_method

  • PostgreSQL 18 की file_copy_method setting OS-level file cloning method को नियंत्रित करती है
    • default copy है, जो हर byte को पढ़कर नई जगह लिखता है
    • clone पर बदलने से file system का clone फ़ीचर (FICLONE) इस्तेमाल होता है, जिससे तुरंत clone और अतिरिक्त space खर्च नहीं होता
  • supported file system: XFS, ZFS, APFS, FreeBSD ZFS
  • configuration प्रक्रिया
    • संबंधित file system पर PostgreSQL cluster बनाएं
    • file_copy_method = clone सेट करके reload करें

benchmark नतीजे

  • लगभग 6GB आकार का test database (source_db) बनाने के बाद दो तरीकों की तुलना की गई
    • WAL_LOG तरीका: 67,000ms (लगभग 67 सेकंड)
    • FILE_COPY + clone तरीका: 212ms
  • समान data size पर लगभग 300 गुना से अधिक performance improvement देखा गया
  • clone किया गया database (fast_clone) लगभग कोई अतिरिक्त disk space इस्तेमाल नहीं करता

clone किए गए data का काम करने का तरीका

  • file_copy_method = clone इस्तेमाल करने पर सिर्फ file system metadata clone होता है, इसलिए दोनों database एक ही physical block साझा करते हैं
  • PostgreSQL जो database size दिखाता है, वह logical size (लगभग 6GB) के रूप में समान रहता है
  • write होने पर copy-on-write (COW) काम करता है और संबंधित page अलग हो जाता है
    • वह page जिसमें बदली गई row शामिल है
    • वह page जिसमें नया tuple लिखा जाता है
    • index page, FSM, visibility map page आदि
  • VACUUM चलाने पर भी अतिरिक्त page separation होता है

XFS में shared block की जांच

  • filefrag -v कमांड से दो database के physical block shared हैं या नहीं यह जांचा जा सकता है
    • शुरुआती स्थिति में सभी extents shared के रूप में दिखते हैं
    • कुछ row update करने पर पहले 40 block (लगभग 160KB) अलग होकर अलग physical address पर चले जाते हैं
    • बाकी extents अब भी shared रहते हैं

सावधानियां और सीमाएं

  • clone बनाते समय source database पर active connection नहीं होना चाहिए
    • यह PostgreSQL की सीमा है, file system की समस्या नहीं
    • production environment में आम तौर पर अलग template database इस्तेमाल किया जाता है
  • cloning केवल एक ही file system के भीतर संभव है
    • अगर कई tablespace अलग-अलग mount point पर हों, तो सामान्य copy इस्तेमाल होगी
  • cloud managed services (AWS RDS, Google Cloud SQL आदि) में file system access उपलब्ध नहीं होने के कारण यह फ़ीचर इस्तेमाल नहीं किया जा सकता
    • अपने VM या bare metal environment में पूरा control संभव है

निष्कर्ष

  • PostgreSQL 18 का file_copy_method = clone फ़ीचर सीधे OS-level clone capability का उपयोग करके
    बड़े database clone समय को नाटकीय रूप से कम करता है
  • testing, development और learning environment में तुरंत clone और reset किए जा सकने वाले database workflow बनाए जा सकते हैं
  • हालांकि, active connection की सीमा और single file system को ध्यान में रखकर operation design करना होगा

संबंधित पढ़ाई

अभी कोई टिप्पणी नहीं है.

अभी कोई टिप्पणी नहीं है.