RDS मास्टर उपयोगकर्ता को SUPER . की भी अनुमति नहीं देता है विशेषाधिकार है, और यह FLUSH TABLES WITH READ LOCK को निष्पादित करने के लिए आवश्यक है। . (यह आरडीएस की एक दुर्भाग्यपूर्ण सीमा है)।
फेलिंग स्टेटमेंट --master-data . द्वारा जेनरेट किया जा रहा है विकल्प, जो निश्चित रूप से आवश्यक है यदि आप सटीक बिनलॉग निर्देशांक सीखने में सक्षम होना चाहते हैं जहां बैकअप शुरू होता है। FLUSH TABLES WITH READ LOCK सभी तालिकाओं पर एक वैश्विक पठन लॉक प्राप्त करता है, जो mysqldump को START TRANSACTION WITH CONSISTENT SNAPSHOT की अनुमति देता है (जैसा कि --single-transaction . के साथ होता है ) और फिर SHOW MASTER STATUS बाइनरी लॉग निर्देशांक प्राप्त करने के लिए, जिसके बाद यह वैश्विक रीड लॉक जारी करता है क्योंकि इसमें एक लेनदेन होता है जो दृश्यमान डेटा को उस लॉग स्थिति के अनुरूप स्थिति में रखेगा।
RDS SUPER . को नकार कर इस तंत्र को तोड़ता है विशेषाधिकार और कोई स्पष्ट समाधान प्रदान नहीं कर रहा है।
इसके आसपास ठीक से काम करने के लिए कुछ हैकी विकल्प उपलब्ध हैं, जिनमें से कोई भी विशेष रूप से आकर्षक नहीं हो सकता है:
-
कम ट्रैफ़िक की अवधि के दौरान बैकअप करें। यदि आपके द्वारा बैकअप शुरू करने के समय और बैकअप के बाद आउटपुट फ़ाइल या गंतव्य सर्वर पर डेटा लिखना शुरू करने के बीच बिनलॉग निर्देशांक नहीं बदले हैं (यह मानते हुए कि आपने
--single-transactionका उपयोग किया है) ) तो यह काम करेगा क्योंकि आप जानते हैं कि प्रक्रिया के चलने के दौरान निर्देशांक नहीं बदले। -
बैकअप शुरू करने से ठीक पहले मास्टर पर बिनलॉग स्थिति का निरीक्षण करें, और इन निर्देशांकों का उपयोग
CHANGE MASTER TOके साथ करें . यदि आपके गुरु काbinlog_formatROW. पर सेट है तो यह काम करना चाहिए, हालांकि आपको कुछ प्रारंभिक त्रुटियों को छोड़ना होगा, लेकिन बाद में कोई त्रुटि नहीं होनी चाहिए। यह काम करता है क्योंकि पंक्ति-आधारित प्रतिकृति बहुत नियतात्मक है और यदि वह पहले से मौजूद किसी चीज़ को सम्मिलित करने का प्रयास करती है या पहले से चली गई किसी चीज़ को हटाने का प्रयास करती है तो वह रुक जाएगी। एक बार त्रुटियों को पार करने के बाद, आप वास्तविक बिनलॉग निर्देशांक पर होंगे जहां से संगत स्नैपशॉट वास्तव में प्रारंभ हुआ था। -
पिछले आइटम की तरह, लेकिन, बैकअप को पुनर्स्थापित करने के बाद
mysqlbinlog --base64-output=decode-rows --verboseका उपयोग करके सही स्थिति निर्धारित करने का प्रयास करें आपके द्वारा प्राप्त किए गए निर्देशांक पर मास्टर के बिनलॉग को पढ़ने के लिए, अपने नए दास की जाँच करके देखें कि स्नैपशॉट के वास्तव में शुरू होने से पहले कौन सी घटनाओं को पहले ही निष्पादित किया जाना चाहिए, और निर्देशांक का उपयोग करकेCHANGE MASTER TOके लिए इस तरह से निर्धारित किया गया है। । -
सर्वर पर प्रत्येक तालिका पर रीड लॉक प्राप्त करने के लिए बाहरी प्रक्रिया का उपयोग करें, जो सभी लेखन को रोक देगा; देखें कि
SHOW MASTER STATUS. से बिनलॉग स्थिति वृद्धि करना बंद कर दिया है, बैकअप प्रारंभ करें, और उन तालों को छोड़ दें।
यदि आप इनमें से किसी भी दृष्टिकोण का उपयोग शायद पिछले एक के अलावा करते हैं, तो यह विशेष रूप से महत्वपूर्ण है कि आप यह सुनिश्चित करने के लिए तालिका तुलना करते हैं कि आपका दास चलने के बाद मास्टर के समान है। यदि आप बाद में प्रतिकृति त्रुटियों को मारते हैं... तो ऐसा नहीं था।
शायद सबसे सुरक्षित विकल्प -- लेकिन शायद सबसे ज़्यादा परेशान करने वाला भी चूंकि ऐसा लगता है कि यह आवश्यक नहीं होना चाहिए - अपने आरडीएस मास्टर की आरडीएस रीड प्रतिकृति बनाकर शुरू करना है। एक बार जब यह तैयार हो जाता है और मास्टर के साथ सिंक्रनाइज़ हो जाता है, तो आप RDS द्वारा प्रदान की गई संग्रहीत कार्यविधि को निष्पादित करके RDS रीड रेप्लिका पर प्रतिकृति को रोक सकते हैं, CALL mysql.rds_stop_replication जिसे RDS 5.6.13 और 5.5.33 में पेश किया गया था जिसके लिए SUPER . की आवश्यकता नहीं है विशेषाधिकार।
RDS रेप्लिका स्लेव बंद होने के साथ, अपना mysqldump लें RDS रीड रेप्लिका से, जिसमें अब मास्टर निर्देशांक के विशिष्ट सेट के रूप में एक अपरिवर्तनीय डेटा सेट होगा। इस बैकअप को अपने ऑफ-साइट स्लेव में पुनर्स्थापित करें और फिर SHOW SLAVE STATUS से RDS रीड रेप्लिका के मास्टर कोऑर्डिनेट्स का उपयोग करें। Exec_Master_Log_Pos और Relay_Master_Log_File अपने CHANGE MASTER TO . के रूप में निर्देशांक।
Exec_Master_Log_Pos . में दिखाया गया मान एक गुलाम पर अगले लेन-देन की शुरुआत है या संसाधित किया जाने वाला ईवेंट
, और यहीं से आपके नए दास को मास्टर पर पढ़ना शुरू करना होगा।
एक बार आपका बाहरी दास उठने और चलने के बाद आप आरडीएस रीड प्रतिकृति को निष्क्रिय कर सकते हैं।
