Apache DolphinScheduler 3.x इसके आर्किटेक्चर को पूरी तरह से बदल देता है। जो टीमें अभी भी 1.3 पर हैं, उन्हें अपग्रेड करने से पहले अपने क्लस्टर लेआउट को फिर से व्यवस्थित करना होगा और डेटाबेस स्कीमा को फिर से लिखना होगा। पुराना सिंगल-नोड मास्टर अब खत्म हो गया है, और उसकी जगह एक प्लग-इन-संचालित (plug-in-driven), विकेंद्रीकृत (decentralized) सिस्टम ने ले ली है जो जॉब्स को अलग तरह से शेड्यूल, स्टोर और लॉग करता है।

यह बदलाव क्यों महत्वपूर्ण है

वर्जन 1.3 एक सेंट्रलाइज्ड मास्टर पर निर्भर था जो हर शेड्यूलिंग निर्णय को संभालता था और केवल बारह इन-बिल्ट टास्क प्रकार प्रदान करता था। 3.x इसे एक माइक्रोकर्नेल (microkernel) से बदल देता है जो टास्क प्रकारों और स्टोरेज एडेप्टर को प्लगइन्स के रूप में लोड करता है, और यह मास्टर्स और वर्कर्स को एक रजिस्ट्री सर्विस के माध्यम से बात करने की अनुमति देकर 'सिंगल पॉइंट ऑफ फेलियर' (single point of failure) को खत्म कर देता है। ऑपरेटर्स को स्केलेबिलिटी और रेजिलिएंस (resilience) मिलती है; डेवलपर्स कोर कोड में बदलाव करने के बजाय केवल एक JAR फाइल डालकर शेड्यूलर का विस्तार कर सकते हैं।

आर्किटेक्चरल ओवरहॉल (Architectural overhaul)

  • माइक्रोकर्नेल प्लग-इन सिस्टम – टास्क डेफिनिशन, रिसोर्स हैंडलर और कस्टम हेल्थ चेक अब अलग-अलग मॉड्यूल में रहते हैं। इसके प्लग-इन को क्लासपाथ (classpath) पर रखकर और प्रभावित नोड्स को रीस्टार्ट करके एक नया टास्क प्रकार जोड़ें।
  • विकेंद्रीकृत समन्वय (Decentralized coordination) – मास्टर्स और वर्कर्स एक रजिस्ट्री के माध्यम से एक-दूसरे को पहचानते हैं। रजिस्ट्री ZooKeeper (पुराना डिफॉल्ट), एक JDBC-आधारित रिलेशनल डेटाबेस, या Etcd क्लस्टर हो सकती है। ऐसी तकनीक चुनें जो आपके मौजूदा स्टैक से मेल खाती हो।
  • विस्तारित टास्क कैटलॉग – इन-बिल्ट टास्क की संख्या 12 से बढ़कर 30 से अधिक हो गई है, जिसमें क्लाउड-नेटिव वर्कलोड और मशीन-लर्निंग पाइपलाइन शामिल हैं।
  • MasterServer बनाम WorkerServer – MasterServer अब DAG पार्टिशनिंग, सबमिशन और हेल्थ मॉनिटरिंग को संभालता है। WorkerServer एक शुद्ध एक्जीक्यूशन इंजन के रूप में कार्य करता है जो लॉग्स को स्ट्रीम भी करता है। यह विभाजन जिम्मेदारियों को स्पष्ट करता है और आपको प्रत्येक लेयर को स्वतंत्र रूप से स्केल करने की अनुमति देता है।
  • Watcher के माध्यम से फॉल्ट टॉलरेंस – Watcher नोड फेलियर के लिए रजिस्ट्री पर नज़र रखता है। जब कोई मास्टर या वर्कर डाउन होता है, तो रजिस्ट्री एक ऑटोमैटिक फेलओवर (failover) ट्रिगर करती है।
  • gRPC लॉग ट्रांसपोर्ट – रिमोट लॉग रिट्रीवल को Netty-आधारित प्रोटोकॉल से gRPC पर स्थानांतरित कर दिया गया है, जिसके बारे में सोर्स का कहना है कि यह बेहतर प्रदर्शन देता है।

डेटाबेस रिफैक्टरिंग जिसे आप नजरअंदाज नहीं कर सकते

स्कीमा ओवरहॉल किसी भी अपग्रेड के लिए सबसे बड़ी बाधा है:

1.3 टेबल 3.x टेबल क्या बदला
t_ds_process_definition t_ds_workflow_definition UI और API शब्दावली से मेल खाने के लिए "process" शब्द को बदलकर "workflow" कर दिया गया है।
t_ds_process_instance t_ds_workflow_instance रनटाइम रिकॉर्ड्स के लिए भी यही सिमेंटिक बदलाव किया गया है।

नाम बदलने के अलावा, 3.x टास्क मेटाडेटा को (जो पहले JSON ब्लब्स के अंदर रहता था) समर्पित रिलेशनल टेबल्स में निकाल लेता है, जिससे डेटा मैनेजमेंट अधिक व्यवस्थित हो जाता है।

माइग्रेशन चेकलिस्ट

  1. सब कुछ बैकअप करें – पूरे 1.3 डेटाबेस डंप को एक्सपोर्ट करें और conf डायरेक्टरी को कॉपी करें।
  2. पुरानी टेबल्स को नए नामों से मैप करें – एक स्क्रिप्ट चलाएं जो t_ds_process_definition को t_ds_workflow_definition में और t_ds_process_instance को t_ds_workflow_instance में बदल दे। इसके बाद फॉरेन-की (foreign-key) कंस्ट्रेंट्स को सत्यापित करें।
  3. JSON टास्क फील्ड्स को माइग्रेट करें – JSON-एन्कोडेड टास्क डेटा को नई रिलेशनल टेबल्स में कॉपी करें। यह पुष्टि करने के लिए कुछ DAGs का परीक्षण करें कि शेड्यूलर नए लेआउट को सही ढंग से पढ़ रहा है।
  4. एक रजिस्ट्री चुनें – यदि आप पहले से ही ZooKeeper चला रहे हैं तो उसे ही रखें; अन्यथा एक JDBC-आधारित रजिस्ट्री या Etcd क्लस्टर सेटअप करें और सभी नोड्स को नए पते पर पॉइंट करें।
  5. प्लग-इन्स तैनात करें – 1.3 में उपयोग किए गए किसी भी कस्टम टास्क प्रकार को 3.x-संगत प्लग-इन्स के रूप में पैकेज करें और उन्हें प्रत्येक MasterServer पर तैनात करें।
  6. सबसे पहले MasterServer रोल आउट करें – माइग्रेट किए गए डेटाबेस को पॉइंट करते हुए एक नया MasterServer इंस्टेंस शुरू करें। सत्यापित करें कि यह मौजूदा वर्कफ़्लो को सूचीबद्ध करता है और हेल्थ डैशबोर्ड में कोई त्रुटि नहीं दिख रही है।
  7. WorkerServers जोड़ें – WorkerServers को एक-एक करके शुरू करें। सफल रजिस्ट्रेशन के लिए रजिस्ट्री पर नज़र रखें और पुष्टि करें कि लॉग्स gRPC के माध्यम से प्रवाहित हो रहे हैं।
  8. स्मोक टेस्ट (smoke tests) चलाएं – सबसे सामान्य टास्क प्रकारों को कवर करने वाले कुछ कम जोखिम वाले DAGs को ट्रिगर करें। जांचें कि लॉग्स UI में दिखाई दे रहे हैं और टास्क स्टेटस अपडेट सही ढंग से अपडेट हो रहे हैं।
  9. फेलओवर की निगरानी करें – MasterServer क्रैश का अनुकरण (simulate) करें और देखें कि Watcher एक स्टैंडबाय को प्रमोट करता है या नहीं। पुष्टि करें कि चल रहे (in-flight) टास्क बिना किसी मैनुअल रीस्टार्ट के जारी रहते हैं।

क्या समस्या आ सकती है

नया प्लग-इन मॉडल शक्तिशाली है, लेकिन यह कस्टम डेवलपमेंट के लिए मानक (bar) को बढ़ा देता है।

निष्कर्ष: 1.3 से 3.x पर जाना केवल एक साधारण वर्ज़न अपडेट नहीं है; इसके लिए एक समन्वित डेटाबेस रीनेम, JSON-to-relational माइग्रेशन, और प्लग-इन-सक्षम, रजिस्ट्री-संचालित मॉडल के आधार पर आपके क्लस्टर के पुनर्गठन की आवश्यकता होती है। चेकलिस्ट का चरण-दर-चरण पालन करें, समय रहते परीक्षण करें, और आपको एक ऐसा शेड्यूलर मिलेगा जो स्केल आउट कर सकता है, स्वचालित रूप से रिकवर कर सकता है, और आधुनिक क्लाउड सेवाओं के समान ही प्रोटोकॉल का उपयोग करता है।