क्लीन
डेटाबेसमध्ये असलेली परंतु आता गरज नसलेली माहिती काढून टाका, जेणेकरून तुमची साईट प्रत्यक्षात वापरत असलेल्या डेटापुरताच वर्किंग सेट मर्यादित राहील.
डेटाबेस देखभाल
डेटाबेसची देखभाल जी स्वतःच चालते, गरज भासताच
प्रत्येक WordPress डेटाबेस वयानुसार अधिक जड होत जातो. Zinn Digital® याला सपोर्ट तिकीट न मानता एक अभियांत्रिकी समस्या मानतो: स्वच्छ करणे, ऑप्टिमाइझ करणे आणि दुरुस्त करणे हे एका क्लिकवर विकत घेणार्या स्वयंचलित कार्यप्रवाहाच्या रूपात चालतात - आणि डेटाबेस फुगत असल्याचे दिसताच प्लॅटफॉर्म ते तुम्हाला ऑफर करतो. उपलब्धता: MCP वरील बॅकअप आणि रिस्टोअर आणि प्रति-साइट डेटाबेस थ्रॉटलिंग सक्रिय विकासात आहेत आणि अद्याप उपलब्ध नाहीत. येथे वर्णन केलेल्या इतर सर्व गोष्टी आज थेट उपलब्ध आहेत.
- ६५०,०००+जगभरात होस्ट केलेले साइट्स
- झिरो-टचस्वयंचलित पूर्तता, कोणतीही तिकीट रांग नाही
- ३० दिवसFootprint-Free प्लॅनवर दैनिक बॅकअप धारणा
- १४ दिवसकार्ड-मुक्त PBN चाचणी, ५ साइट्सपर्यंत
डेटाबेस कसे नकळत अडथळा बनतात
WordPress साइटच्या फाइल्स तुम्ही जितक्या आकाराच्या बनवल्या होत्या साधारणपणे तितक्याच आकाराच्या राहतात. तिचा डेटाबेस राहत नाही. टेबल जमा होतात, इंडेक्स विसविशीत होतात, स्टोरेज इंजिन्स अशी जागा वाटप करून ठेवतात जी आता कोणीही वापरत नाही, आणि क्वचित प्रसंगी एखादे टेबल अशा स्थितीत संपते ज्याला ट्युनिंगऐवजी दुरुस्तीची गरज असते. यापैकी कशाचीही पूर्वकल्पना मिळत नाही. साइट फक्त संथ होते, क्वेरीजला जास्त वेळ लागतो, आणि ज्या पानाचा वेग पूर्वी झटपट वाटायचा ते आता वाटत नाही हे लक्षात येणारी पहिली व्यक्ती असते.
एकाच साइटवर ही केवळ एक अडचण असते. शेकडो साइट्सच्या पोर्टफोलिओ किंवा नेटवर्कमध्ये हा एक वाढणारा कर आहे — त्यातील प्रत्येक साइट गरजेपेक्षा थोडी जड असते, आणि त्यातील प्रत्येक साइट डेटाबेस सर्व्हरवर असायला हवी त्यापेक्षा जास्त ताण टाकते.
Zinn Digital® हे इतर प्लॅटफॉर्मप्रमाणेच हाताळते: एक स्वयंचलित, पुनरावृत्ती करण्यायोग्य प्रक्रिया म्हणून. डेटाबेस देखभाल ही डॅशबोर्डवरून तुम्ही खरेदी केलेली प्रथम-पक्ष सेवा आहे आणि ती खरेदी केल्याने ऑप्टिमायझेशन जॉब ताबडतोब सुरू होतो. यात सामील होण्यासाठी कोणतीही रांग नाही आणि प्रतीक्षा करण्यासाठी कोणतीही अभियंता नाही.
मेंटेनन्स रन काय करतो
साइटच्या MariaDB डेटाबेसची सफाई, ऑप्टिमायझेशन, दुरुस्ती आणि रिपोर्टिंग, एकाच जॉब म्हणून चालवले जाते.
ऑप्टिमाइझ करा
वाटप केलेल्या परंतु न वापरलेल्या टेबल स्पेसचा ताबा पुन्हा मिळवा आणि इंडेक्स आणि आकडेवारीला क्वेरी प्लॅनरच्या अपेक्षेनुसार पूर्ववत करा, जेणेकरून वाचन क्रिया आवश्यकतेपेक्षा जास्त काम करणे थांबवतील.
दुरुस्त करा
खराब स्थितीत पोहोचलेल्या टेबल्स शोधा आणि त्यांची दुरुस्ती करा — ही अशी त्रुटी आहे जी दुर्लक्ष केल्यास एका संथ साईटला पूर्णपणे बंद पडणाऱ्या साईटमध्ये बदलू शकते.
अहवाल पाठवा
खरेदीचे शुल्क बिलिंग किंवा तुमच्या वॉलेटमधून आकारले जाते, ती पूर्ण होते, तुम्हाला सूचित करते आणि स्वतःला पूर्ण म्हणून चिन्हांकित करते. जर काही गडबड झाली, तर परतावे आणि वाद तुम्ही आमच्याकडून विकत घेतलेल्या इतर प्रत्येक गोष्टीप्रमाणेच त्याच बिलिंग मार्गावरून चालतात.
स्वयंचलित पूर्तता, समर्थनाची रांग नाही
या प्लॅटफॉर्मवरील फर्स्ट-पार्टी सेवा दोन स्वरूपांत येतात. काही कर्मचारी-पूर्ण केल्या जातात: त्या विकत घेतल्याने आमच्या ॲडमिन रांगेत एक कार्य तयार होते, जे योग्य विभागाकडे पाठवले जाते, ट्रॅक केले जाते आणि अपडेट केले जाते. डेटाबेस मेंटेनन्स त्यापैकी एक नाही. ते स्वयंचलित आहे — खरेदीमुळे एक Temporal वर्कफ्लो सुरू होतो जो तुमच्या साइटवर थेट ऑप्टिमायझेशन जॉब चालवतो. झटपट, शून्य-स्पर्श.
याला जितके वाटते त्यापेक्षा जास्त महत्त्व आहे. Temporal वर्कफ्लो हे रचनेनुसारच टिकाऊ, पुन्हा प्रयत्न करता येण्यासारखे आणि आयडempotेंट असतात, जे या प्लॅटफॉर्मवरील प्रत्येक दीर्घकाळ चालणाऱ्या ऑपरेशनसाठी पाळले जाणारे मानक आहे. एखादी पायरी अर्ध्यातच अपयशी ठरल्यास, वर्कफ्लो अर्धे काम पूर्ण करून तुमच्या डेटाबेसची स्थिती संदिग्ध ठेवण्याऐवजी जिथून थांबला होता तिथूनच पुन्हा प्रयत्न करतो. पुनरावृत्तीमुळे आधीच यशस्वी झालेले ऑपरेशन पुन्हा रन झाले, तर ते रचनेनुसारच सुरक्षित असते.
याचा अर्थ असाही आहे की लोड वाढल्यावर सेवेचा दर्जा कमी होत नाही. एकाच वेळी डेटाबेस मेंटेनन्स खरेदी करणारे दहा ग्राहक एकाच इंजिनियरची वाट पाहत रांगेत उभे राहत नाहीत — ते दहा वर्कफ्लो एक्झिक्युशन असतात आणि प्लॅटफॉर्म त्यांना क्षैतिज स्वरूपात (horizontally) वाढवण्यासाठी बनवलेला असतो.
- खरेदीमुळे नोकरी ताबडतोब सुरू होते — शुल्क आकारले जाते,पूर्र्ती केली जाते,सूचना दिली जाते,पूर्ण होते.
- एक टिकाऊ Temporal वर्कफ्लो म्हणून चालते: पुन्हा प्रयत्न करण्यायोग्य आणि आयडेम्पोटंट, फायर-अँड-फॉरगेट स्क्रिप्ट नाही.
- प्रत्येक रन वर्कफ्लोच्या इतिहासामध्ये दृश्यमान असते, त्यामुळे काय आणि कधी चालले याचा रेकॉर्ड असतो.
- प्लॅन्स आणि ॲड-ऑन्स प्रमाणेच परतावे (refunds) आणि वाद (disputes) देखील त्याच बिलिंग मार्गाद्वारे हाताळले जातात.
योग्य वेळी दिली जाते, मेनूमध्ये लपवून ठेवलेली नाही
प्लॅटफॉर्म आधीपासूनच तुमच्या साइट्सवर लक्ष ठेवून आहे. योग्य वेळी योग्य सेवा देण्यासाठी ते त्याच्या निरीक्षणाचा वापर करते.
डॅशबोर्डमध्ये एक समर्पित एक्स्ट्राज विभाग आहे जिथे तुम्ही जेव्हा पाहिजे तेव्हा प्रथम-पक्ष सेवा ब्राउझ करू शकता आणि खरेदी करू शकता. परंतु अधिक उपयुक्त मार्ग तो आहे जो तुम्हाला शोधतो: संदर्भात्मक अपसेल. डेटाबेस मेंटेनन्स एका फुगीर डेटाबेससमोर समोर आणला जातो, गती ऑप्टिमायझेशन धीम्या साइटविरुद्ध जे Core Web Vitals मध्ये अपयशी ठरत आहे, मालवेअर साफ करणे फ्लॅग केलेल्या साइटविरुद्ध, साइनअपच्या वेळी मायग्रेशन.
ते प्रॉम्प्ट्स वास्तविक ऑब्झर्वाबिलिटी सिग्नलद्वारे चालवले जातात — तेच प्रति-साइट मेट्रिक्स आणि रिसॉर्ट टेलिमेट्री जे प्लॅटफॉर्म फ्लीट चालवण्यासाठी गोळा करतो, कोणतेही सर्वसाधारण मासिक त्रासदायक स्मरणपत्र नाही. आणि एआय असिस्टंट तुम्हाला सेवा सुचवू शकतो आणि ती तुमच्यासाठी सुरू करू शकतो, त्यामुळे समस्या लक्षात येणे आणि ती दुरुस्ती करणे यामधील अंतर हा एखादा प्रकल्प असण्यापेक्षा एक संभाषण असते.
तुमच्याकडे ήδη असलेले डेटाबेस टूल्स
देखभाल हे वरील स्वयंचलित स्तर आहे. अंतर्गत, प्रत्येक साइट संपूर्ण डेटाबेस नियंत्रणासह येते.
प्रति साइट मारियाडीबी
प्रत्येक साइटला स्वतःचा डेटाबेस मिळतो, आणि जिथे प्रकल्पाला गरज असेल तिथे एकापेक्षा जास्त डेटाबेस व एकापेक्षा जास्त डेटाबेस वापरकर्त्यांसाठी (users) समर्थन मिळते.
phpMyAdmin आणि Adminer, एम्बेड केलेले
दोन्ही डॅशबोर्डमध्ये इन-बिल्ट आहेत आणि सिंगल-साइन-ऑन केलेले आहेत — व्यवस्थापित करण्यासाठी कोणतीही स्वतंत्र क्रेडेन्शियल्स नाहीत, संरक्षित करण्यासाठी कोणतीही स्वतंत्र लॉगिन नाही.
रिमोट ॲक्सेस टॉगल
जेव्हा एखाद्या टूलला किंवा डेव्हलपरला त्याची गरज असेल तेव्हा बाह्य डेटाबेस प्रवेश सुरू करा आणि गरज नसेल तेव्हा तो बंद करा. डीफॉल्टनुसार बंद असणे हीच योग्य स्थिती आहे.
प्रति-साइट Redis ऑब्जेक्ट कॅशे
वारंवार होणारी वाचण्याची कामे Redis कडे सोपवा, जेणेकरून डेटाबेसमध्ये सुरुवातीपासूनच कमी क्वेरी जातील. उपचारापेक्षा प्रतिबंध उत्तम.
MySQL Governor: तुमच्या क्वेरी, तुमची समस्या — आणि फक्त तुमचीच
शेअर केलेल्या इन्फ्रास्ट्रक्चरवरील डेटाबेस कामगिरीचा उरलेला अर्धा भाग असा आहे ज्यावर तुमचे नियंत्रण नाही: इतर प्रत्येच्या साइट्स त्याच सर्व्हरवर काय करत आहेत. आमचा वर्कर फ्लीट CloudLinux MySQL Governor सह MariaDB चालवतो, जो प्रत्येक साइटनुसार डेटाबेसचा वापर मर्यादित (थ्रॉटल) करतो. भारी क्वेरीज चालवणारी एक साइट शेजाऱ्यांसाठी सर्व्हरचा वेग कमी करण्याऐवजी स्वतःच्या मर्यादेतच नियंत्रित ठेवल्या जाते.
हे इतर आयसोलेशन स्टॅकच्या बाजूला काम करते — CPU, RAM, IO, IOPS आणि प्रक्रियांवरील LVE कॅप्स आणि प्रत्येक टेनंटला आयसोलेटेड फाइलसिस्टम व्ह्यू देणारे CageFS. संपूर्ण डिझाइनचा उद्देश हाच आहे: एका साइटवरील समस्या त्याच साइटवर राहते.
जेव्हा तुमचा डेटाबेस सुस्त असतो, तेव्हा त्यावर तुम्ही प्रत्यक्ष कृती करू शकता असे उत्तर मिळते. तो तुमचा डेटाबेस आहे आणि डेटाबेसची देखभाल करणे हे ते ठीक करणारे बटण आहे.
हे तुमच्या एआय (AI) टूलमधून चालवा
डेटाबेस ऑपरेशन्स हे MCP टूल कॅटलॉगचा भाग आहेत, त्यामुळे कोणतीही MCP-सक्षम एजंट तुमच्या वतीने ते चालवू शकते.
आमचे होस्टेड MCP सर्व्हर प्लॅटफॉर्म Claude Code, Cursor, ChatGPT, Claude Desktop आणि इतर कोणत्याही MCP-सक्षम एजंटसमोर उघडे करते — प्रत्येक टूलसाठी स्वतंत्र एकत्रिकरणाऐवजी एकच कनेक्शन. त्या कॅटलॉग मधील डेटाबेस टूल्समध्ये गार्डेड क्वेरी, ऑप्टिमाइज आणि बॅकअप आणि रिस्टोअर यांचा समावेश होतो. अतिरिक्त खरेदी (Buying Extras) देखील स्पष्ट पुष्टीकरण पायरीच्या मागे उघडी केली जाते.
एजंट जे काही करू शकतो ते ते ज्या ओळखीने कनेक्ट झाले आहे त्याद्वारे मर्यादित आहे. टोकन्स OAuth 2.1 द्वारे जारी केले जातात, जे तुमच्या संस्थेसाठी आणि तुमच्या RBAC परवानग्यांसाठी सीमित, प्रति-साधन आणि रद्द करण्यायोग्य असतात. विनाशकारी कृतींसाठी स्पष्ट पुष्टीकरणाची आवश्यकता असते, AI-द्वारे ट्रिगर केलेल्या शोधप्रारूप (पेड) कृतींना खर्च मर्यादा लागू होते आणि प्रत्येक MCP कृती ही ओळख, साधन, युक्तिवाद (arguments) आणि निकालासह ऑडिट लॉगमध्ये लिहीली जाते.
व्यवहारात: तुमचा एजंट डेटाबेस जड असल्याचे लक्षात आणून देतो, देखरेख रन करावी की नाही हे विचारतो, तुम्ही पुष्टी करता आणि वर्कफ्लो रन होतो. AI हा एक ड्रायव्हर आहे, अनियंत्रित ऑपरेटर नाही.
प्लॅनसारखा विकत घेतलेला, सर्व्हिससारख्या किमतीत
फर्स्ट-पार्टी सेवा हा या प्लॅटफॉर्मवरील डेटा आहे, हार्डकोडेड वैशिष्ट्ये नाहीत.
- आमचा स्टाफ प्रशासकीय कन्सोलमध्ये सेवा जोडतात, संपादित करतात, किंमत ठरवतात आणि सुरू करतात, ज्याप्रमाणे प्लॅन व्यवस्थापित केले जातात — कोणतीही सेवा सुरू करण्यासाठी किंवा त्यात बदल करण्यासाठी कोडमध्ये बदल करण्याची गरज नाही.
- किमती प्रत्येक चलनानुसार, वन-ऑफ किंवा आवर्ती म्हणून सेट केल्या जातात, जेणेकरून तुम्ही आधीच ज्या चलनात पैसे देता त्याच चलनात खरेदी करू शकता.
- सेवांमध्ये उत्पादन-श्रेणीची पात्रता असते, त्यामुळे जे ऑफर केले जाते ते तुम्ही प्रत्यक्षात चालवत असलेल्या गोष्टीशी जुळते.
- चार्जिंग बिलिंग किंवा तुमच्या वॉलेट शिल्लक द्वारे, तुमच्या सदस्यतेसह जाते — एक खाते, इन्व्हॉइसेसचा एक संच.
- खरेदी हा सामान्य व्यापार आहे: पूर्ण झाल्यावर सूचित केले जाते, परतावा मिळू शकतो, वाद घालता येतो.
What it costs
A one-off job per site, run automatically once you buy it.
Database Maintenance & Optimization
₹२,७४०.९९one-off
It runs within 1 day of purchase, and a full backup is taken before anything is changed. Add-ons are bought per site from your dashboard and appear on your normal invoice — no separate account, no second bill and no minimum term. Prices exclude tax, which is worked out from your billing country at checkout.
सतत विचारले जाणारे प्रश्न
माझ्या डेटाबेसची देखभाल करणे आवश्यक आहे हे मला कसे कळेल?
बहुतेक प्रकरणांमध्ये तुम्हाला हे स्वतः करावे लागणार नाही. प्लॅटफॉर्म प्रत्येक साइटच्या संसाधन वापरावर लक्ष ठेवतो आणि जेव्हा डेटाबेसचा आकार वाढलेला दिसतो तेव्हा संदर्भात्मक ऑफर म्हणून डेटाबेस मेंटेनन्स समोर आणतो, तसेच AI सहाय्यक ते चिन्हांकित करून तुमच्यासाठी ही प्रक्रिया सुरू करू शकतो. तुम्ही डॅशबोर्डच्या Extras विभागातून ते कधीही ब्राउझ करून खरेदी करू शकता आणि एम्बेडेड phpMyAdmin किंवा Adminer द्वारे स्वतः डेटाबेस तand तपासू शकता.
देखभालीच्या (maintenance) प्रक्रियेदरम्यान माझा डेटा धोक्यात आहे का?
आम्ही जोखीम दूर करण्याचा आव आणण्याऐवजी ती कमी करतो. हे काम Temporal वर्कफ्लो म्हणून चालते—टिकाऊ, पुन्हा प्रयत्न करता येण्यासारखे आणि आयडempotंट—त्यामुळे अयशस्वी झालेली पायरी अर्धवट काम सोडून देण्याऐवजी पुन्हा प्रयत्न करते आणि वारंवार केलेले ऑपरेशन डिझाईननुसार सुरक्षित असते. प्रत्येक रन वर्कफ्लो इतिहासात रेकॉर्ड केला जातो. Footprint-Free प्लॅन्सवर, एका क्लिकवर रिस्टोअर करण्याच्या सुविधेसह दैनिक बॅकअप ३० दिवसांसाठी ठेवले जातात, त्यामुळे तुम्हाला हवे असल्यास मागे जाण्यासाठी नेहमीच अलीकडील रिस्टोअर पॉइंट उपलब्ध असतो. कोणतीही महत्त्वाची डेटाबेस बदलाची कृती करण्यापूर्वी बॅकअप घेणे ही एक चांगली पद्धत आहे, मग ती कोणीही करत असो.
हे माझ्या पॅनलमधील डेटाबेस टूल्सची जागा घेते का?
हे त्यांच्या पूरक आहे. प्रत्येक साइट स्वतःचा MariaDB डेटाबेस एम्बेडेड, सिंगल-साइन-ऑन केलेल्या phpMyAdmin आणि Adminer सह, एकाधिक डेटाबेस व युजर्ससाठी समर्थन आणि रिमोट ऍक्सेस टॉगलसह राखते. डेटाबेस मेंटेनन्स हे नियमित कामाची स्वयंचलित आवृत्ती आहे — स्वच्छता करणे, ऑप्टिमाइझ करणे, दुरुस्ती करणे — जेव्हा तुम्ही हाताने चालवण्यापेक्षा निकाल विकत घेणे पसंत कराल.
हे सामान्य सपोर्ट तिकीट पेक्षा कसे वेगळे आहे?
या व्यासपीठावरील सेवा दोनपैकी एका मार्गाने पूर्ण केल्या जातात. कर्मचारी-पूर्ण सेवा आमच्या प्रशासकीय रांगेत एक कार्य तयार करतात, ज्यामध्ये स्थिती ट्रॅकिंग आणि ग्राहक अद्यतनांसह योग्य विभागाकडे पाठवले जाते. डेटाबेस देखभाल स्वयंचलित असते: ती खरेदी केल्याने थेट वर्कफ्लो ट्रिगर होतो, ज्यामध्ये मध्ये कोणतीही मानवी पायरी नसते. प्रक्रियेऐवजी वर्कफ्लो म्हणून तयार करण्याचा मूळ उद्देश हाच आहे.
माझा AI एजंट माझ्यासाठी हे चालवू शकतो का?
होय. डेटाबेस ऑप्टिमाइज, सुरक्षित क्वेरी, आणि बॅकअप आणि रिस्टोअर हे सर्व MCP टूल कॅटलॉगमध्ये उपलब्ध आहेत आणि अतिरिक्त फीचर्स (Extras) खरेदी करण्यासाठी पुष्टीकरण पायरी असते. तुमचा एजंट तुमच्या संस्थेसाठी आणि तुमच्या RBAC परवान्यांसाठी स्कोप केलेल्या टोकनसह OAuth 2.1 द्वारे जोडला जातो — प्रति-टूल, रद्द करण्यायोग्य, सशुल्क कृतींवर खर्च-मर्यादित, आणि प्रत्येक कॉलचे ऑडिट-लॉग केले जाते. तुम्ही जे करू शकला असता, तेच ते करू शकते.
कोणत्या प्लॅन्समध्ये हे समाविष्ट आहे?
डेटाबेस मेन्टेनन्स ही योजना समाविष्ट सेवा नसून विकत घेता येणारी प्रथम-पक्ष सेवा आहे — डॅशबोर्डमध्ये तुमच्या चलनात दर्शविलेल्या किंमतीनुसार, तुमच्या बिलिंग खात्यावर किंवा वॉलेटमधून शुल्क आकारले जाऊन तुम्हाला जेव्हा गरज असेल तेव्हा तुम्ही ती विकत घेऊ शकता. पात्रता प्रत्येक उत्पादन श्रेणीनुसार ठरवली जाते, त्यामुळे तुमच्या अतिरिक्त (Extras) विभागात जे दिसते ते तुम्ही ज्या उत्पादन श्रेणीवर आहात ती दर्शवते. प्लॅटफॉर्म वापरून पाहण्यासाठी तुम्हाला आवश्यक असलेली प्रत्येक गोष्ट कार्ड-मुक्त १४-दिवसांच्या चाचणीमध्ये आहे: कोणतीही पेमेंट माहिती नाही, Footprint-Free Hosting वर पाच साइट्सपर्यंत.
एकाच साईटचा जास्त डेटाबेस वापर इतर साईट्सचा वेग मंदावेल का?
आमच्या फleet मध्ये MariaDB सोबत CloudLinux MySQL Governor चालतो, जो प्रत्येक साइटचा डेटाबेस वापर विशिष्ट प्रकारे मर्यादित करतो जेणेकरून एका साइटच्या जड क्वेरींमुळे इतर साइटसाठी सर्व्हरचा वेग मंदावणार नाही. हे LVE संसाधन मर्यादा आणि CageFS फाइलसिस्टम आयसोलेशन सोबत काम करते. संपूर्ण रचनेचे उद्दिष्ट प्रतिबंध करणे हे आहे — समस्या ज्या पिंजऱ्यात सुरू झाल्या, त्याच पिंजऱ्यात राहतात.
संबंधित
तुम्हाला न दिसणारा डेटाबेस सोबत बाळगणे थांबवा
Footprint-Free Hosting वर कार्ड-मुक्त १४ दिवसांची चाचणी सुरू करा — कोणतीही पेमेंट तपशील नाही, पाच साइट्सपर्यंत — आणि प्लॅटफॉर्म अशा समस्या कशा उघडकीस आणतो आणि दुरुस्त करतो ते पहा ज्या तुम्हाला अन्यथा संथ पेजवरून समजल्या असत्या.
विनाशुल्क सुरू करा