मेनू
"जापानी टेक और करी की दुनिया"
  1. Home
  2. शिक्षा
  3. MySQL 9.1 अपडेट के बाद WordPress बैकअप समस्या का समाधान: RHEL/AlmaLinux केस स्टडी

MySQL 9.1 अपडेट के बाद WordPress बैकअप समस्या का समाधान: RHEL/AlmaLinux केस स्टडी

शिक्षा

MySQL 9.1 अपडेट के बाद WordPress बैकअप समस्या का समाधान: RHEL/AlmaLinux केस स्टडी

WordPress बैकअप एक महत्वपूर्ण कार्य है, विशेष रूप से RHEL/AlmaLinux वातावरण में। हाल ही में, हमारे सिस्टम को MySQL 9.1 में अपग्रेड करने के बाद, एक गंभीर समस्या का सामना करना पड़ा – हमारी बैकअप प्रणाली काम करना बंद कर दी।

विषयसूची

वातावरण की जानकारी

हमारा सिस्टम निम्नलिखित कॉन्फ़िगरेशन पर आधारित है:

  • ऑपरेटिंग सिस्टम: AlmaLinux (RHEL संगत)
  • आर्किटेक्चर: ARM64/v8
  • Docker और Docker Compose
  • WordPress (नवीनतम संस्करण)
  • MySQL 9.1

परियोजना संरचना

हमारी परियोजना की फ़ाइल संरचना इस प्रकार है:

Copywordpress-docker/
├── docker-compose.yml (कंटेनर कॉन्फ़िगरेशन)
├── Dockerfile (WordPress कंटेनर कस्टमाइज़ेशन)
├── entrypoint.sh (प्रारंभिक स्क्रिप्ट)
├── setup.sh (वातावरण सेटअप स्क्रिप्ट)
├── .env (वातावरण वेरिएबल)
├── php.ini (PHP कॉन्फ़िगरेशन)
└── backup/ (बैकअप स्टोरेज डायरेक्टरी)

प्रारंभिक समस्या

सिस्टम अपडेट के दौरान, जब हमने MySQL को 9.1 वर्जन में अपग्रेड किया, तब एक गंभीर समस्या सामने आई। हमारी दैनिक बैकअप प्रणाली पूरी तरह से काम करना बंद कर दी। यह समस्या तब पता चली जब मैंने रूटीन चेक के दौरान देखा कि बैकअप फ़ाइलें नहीं बन रही थीं।

अप्रत्याशित त्रुटियां और प्रारंभिक जांच

सिस्टम की जांच करते समय, मुझे एक परेशान करने वाली त्रुटि का सामना करना पड़ा:

template parsing error: template: :1:8: executing "" at <.State.Health.Status>: map has no entry for key "Health"

यह Docker कंटेनर हेल्थचेक से संबंधित समस्या विशेष रूप से दिलचस्प थी, क्योंकि यह कभी-कभी अपने आप दिखाई देती और कभी-कभी बिना किसी हस्तक्षेप के ठीक हो जाती थी।

समस्या के मूल कारण

Docker वातावरण में, इस तरह की अनियमित समस्याएं असामान्य नहीं हैं। मेरी जांच में, कई संभावित कारण सामने आए:

  • Docker डेमन कैश का साफ होना
  • सिस्टम रीस्टार्ट के बाद स्थिति का रीसेट
  • Docker का स्वचालित अपडेट
  • कंटेनर स्टार्टअप टाइमिंग और निर्भरता संबंधी मुद्दे

मजबूत समाधान का कार्यान्वयन

इन समस्याओं को हल करने के लिए, मैंने docker-compose.yml फ़ाइल में मजबूत हेल्थचेक कॉन्फ़िगरेशन जोड़े:

WordPress कंटेनर कॉन्फ़िगरेशन:

healthcheck:
  test: ["CMD", "curl", "-f", "http://localhost:80"]
  interval: 30s
  timeout: 10s
  retries: 3
  start_period: 40s

डेटाबेस कंटेनर कॉन्फ़िगरेशन:

healthcheck:
  test: ["CMD", "mysqladmin", "ping", "-h", "localhost"]
  interval: 30s
  timeout: 10s
  retries: 3
  start_period: 40s

इन कॉन्फ़िगरेशन का उद्देश्य है कंटेनर की स्थिति की निरंतर निगरानी और समस्याओं का समय पर पता लगाना।

सेटअप स्क्रिप्ट में सुधार

सिस्टम को और अधिक मजबूत बनाने के लिए, setup.sh स्क्रिप्ट को बेहतर कंटेनर स्थिति सत्यापन के साथ अपग्रेड किया:

while true; do
    status=$(docker inspect wordpress 2>/dev/null | jq -r '.[0].State.Status')
    if [ "$status" = "running" ]; then
        if docker exec wordpress curl -s -f http://localhost:80 >/dev/null 2>&1; then
            echo "WordPress कंटेनर सक्रिय और स्वस्थ है"
            break
        fi
    fi
    echo "WordPress कंटेनर के आरंभ होने की प्रतीक्षा कर रहे हैं..."
    sleep 5
done

संचालन के लिए सर्वोत्तम प्रथाएं

इस अनुभव से, मैंने कुछ महत्वपूर्ण कार्यप्रणालियां विकसित की हैं:

नियमित लॉग निगरानी

docker compose logs > docker_logs_$(date +%Y%m%d).txt

सिस्टम स्थिति की जांच

# हाल की घटनाओं की निगरानी
docker system events --since 30m

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

docker exec wordpress-db mysqldump -u root -p wordpress > backup_$(date +%Y%m%d).sql

मुख्य समस्या: डेटाबेस बैकअप की विफलता

सिस्टम स्थिरता में सुधार के बावजूद, हम एक और गंभीर समस्या का सामना कर रहे थे। हमारा डेटाबेस बैकअप पूरी तरह से विफल हो रहा था।

जब मैंने मानक बैकअप कमांड का प्रयास किया:

docker exec wordpress-db mysqldump -u root -p dbin > backup_$(date +%Y%m%d).sql

तब यह महत्वपूर्ण त्रुटि सामने आई:

Enter password: 
mysqldump: Got error: 1045: Access denied for user 'root'@'localhost' (using password: NO) when trying to connect

यह विफलता विशेष रूप से चिंताजनक थी, कई कारणों से:

  • दैनिक बैकअप काम नहीं कर रहे थे
  • आपदा रिकवरी असंभव हो गई थी
  • सिस्टम सुरक्षा खतरे में थी

मूल कारण की समझ

यह समस्या विशेष रूप से MySQL 9.1 अपग्रेड के बाद सामने आई। पहले सही काम कर रही बैकअप प्रक्रिया अचानक बंद हो गई, जो MySQL 9.1 के सुरक्षा मॉडल में महत्वपूर्ण बदलावों को दर्शाता है।

समाधान की यात्रा

1. प्रारंभिक प्रयास

सबसे पहले मैंने विभिन्न पारंपरिक बैकअप विधियों का प्रयास किया, लेकिन सभी विफल रहे। कंटेनर के अंदर से डेटाबेस तक सीधी पहुंच का प्रयास करने पर:

docker exec -it wordpress-db bash
mysqldump -u root -p dbin > dbin_backup.sql

या बाहर से प्रयास करने पर:

docker exec wordpress-db mysqldump -u root -p dbin > dbin_backup.sql

दोनों प्रयासों में एक ही त्रुटि मिली:

mysqldump: Got error: 1045: Access denied for user 'root'@'localhost' (using password: YES) when trying to connect

गहन जांच से पता चला कि मैं MySQL में लॉगिन भी नहीं कर सकता था – जो स्पष्ट रूप से दर्शाता था कि समस्या केवल बैकअप अनुमतियों तक ही सीमित नहीं थी।

2. कारगर समाधान

व्यापक परीक्षण के बाद, मैंने एक ऐसा समाधान विकसित किया जो इन प्रमाणीकरण समस्याओं को सफलतापूर्वक दूर करता है। यहाँ चरण-दर-चरण दृष्टिकोण दिया गया है:

सबसे पहले, अस्थायी डायरेक्टरी तैयार करें:

# अस्थायी डायरेक्टरी बनाएं
mkdir -p temp_mysql_data temp_run_mysqld

# डेटाबेस फ़ाइलें कॉपी करें
sudo cp -r db_data/* temp_mysql_data/

फिर, अस्थायी कंटेनर का उपयोग करके बैकअप निष्पादित करें:

docker run --rm --platform linux/arm64/v8 \
  -v $(pwd)/temp_mysql_data:/var/lib/mysql \
  -v $(pwd)/temp_run_mysqld:/var/run/mysqld \
  -v $(pwd)/backup:/backup \
  mysql:9.1 \
  bash -c 'docker-entrypoint.sh mysqld --skip-grant-tables --skip-networking & sleep 30 && mysqldump --no-tablespaces --skip-add-drop-table --all-databases > /backup/full_backup_$(date +%Y%m%d_%H%M%S).sql && sleep 5'

अंत में, सफाई करें:

# अस्थायी डायरेक्टरी हटाएं
sudo rm -rf temp_mysql_data temp_run_mysqld

यह समाधान प्रभावी क्यों है?

इस समाधान की सफलता के पीछे कई कारण हैं:

  1. प्रमाणीकरण बाईपास
    --skip-grant-tables का उपयोग करके, हम डेटा अखंडता बनाए रखते हुए MySQL 9.1 की कड़ी प्रमाणीकरण आवश्यकताओं को सुरक्षित रूप से बाईपास करते हैं।
  2. सुरक्षा विचार
    --skip-networking फ्लैग सुनिश्चित करता है कि प्रमाणीकरण बाईपास होने के बावजूद, नेटवर्क एक्सेस को रोककर डेटाबेस सुरक्षित रहता है।

कमांड संरचना को समझना

आइए हमारे समाधान के प्रमुख घटकों को विस्तार से समझें:

1. कंटेनर कॉन्फ़िगरेशन

docker run --rm --platform linux/arm64/v8 \
  -v $(pwd)/temp_mysql_data:/var/lib/mysql \
  -v $(pwd)/temp_run_mysqld:/var/run/mysqld \
  -v $(pwd)/backup:/backup \
  mysql:9.1

प्रत्येक फ्लैग का विशिष्ट उद्देश्य है:

  • --rm: कार्य पूरा होने के बाद कंटेनर को स्वचालित रूप से हटाता है
  • --platform: ARM64 आर्किटेक्चर संगतता निर्दिष्ट करता है
  • -v विकल्प: डेटा एक्सेस और बैकअप स्टोरेज के लिए आवश्यक डायरेक्टरी माउंट करते हैं

2. कमांड निष्पादन विवरण

bash -c 'docker-entrypoint.sh mysqld --skip-grant-tables --skip-networking & sleep 30 && \
mysqldump --no-tablespaces --skip-add-drop-table --all-databases > \
/backup/full_backup_$(date +%Y%m%d_%H%M%S).sql && sleep 5'

कमांड के प्रत्येक भाग का विवरण

1. प्रारंभिकरण

  • docker-entrypoint.sh mysqld: MySQL सर्वर को उचित रूप से आरंभ करता है
  • यह Docker आधिकारिक इमेज की मानक स्टार्टअप प्रक्रिया है

2. सुरक्षा विकल्प

  • --skip-grant-tables: प्रमाणीकरण आवश्यकताओं को बाईपास करता है
  • --skip-networking: नेटवर्क एक्सेस को अक्षम करके सुरक्षा बढ़ाता है

3. समय नियंत्रण

  • sleep 30: MySQL के पूर्ण आरंभीकरण को सुनिश्चित करता है
  • सिस्टम प्रदर्शन के आधार पर समायोजित किया जा सकता है

4. बैकअप कॉन्फ़िगरेशन

  • --no-tablespaces: टेबलस्पेस जानकारी को छोड़ देता है
  • --skip-add-drop-table: मौजूदा टेबल संरचनाओं को संरक्षित करता है
  • --all-databases: सभी डेटाबेस का व्यापक बैकअप

5. आउटपुट प्रबंधन

  • फ़ाइलनाम में टाइमस्टैम्प अद्वितीय बैकअप सुनिश्चित करता है
  • प्रारूप: YYYYMMDD_HHMMSS.sql

कार्यान्वयन के लिए महत्वपूर्ण बिंदु

इस समाधान का उपयोग करते समय, निम्नलिखित बातों का ध्यान रखें:

1. डायरेक्टरी प्रबंधन

  • अस्थायी डायरेक्टरी का उचित निर्माण आवश्यक है
  • पर्याप्त डिस्क स्पेस सुनिश्चित करें
  • बैकअप के बाद सफाई महत्वपूर्ण है

2. अनुमति आवश्यकताएं

  • फ़ाइल ऑपरेशन के लिए sudo एक्सेस आवश्यक हो सकता है
  • वॉल्यूम माउंटिंग के लिए उचित अनुमतियां महत्वपूर्ण हैं

3. समय समायोजन

निम्नलिखित के आधार पर स्लीप अवधि समायोजित करें:

  • सिस्टम प्रदर्शन
  • डेटाबेस का आकार
  • उपलब्ध संसाधन

अधिक व्यावहारिक संचालन समाधान

हालांकि हमारा पिछला समाधान मैनुअल बैकअप के लिए अच्छी तरह से काम करता है, मैंने दीर्घकालिक संचालन के लिए एक अधिक स्थायी दृष्टिकोण विकसित किया है।

1. स्वचालित बैकअप कार्यान्वयन

docker-compose.yml में संशोधन करके, हम एक अधिक मजबूत स्वचालित बैकअप प्रणाली बना सकते हैं:

services:
  db:
    healthcheck:
      test: ["CMD", "mysqladmin", "ping", "-h", "localhost"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 40s

  wpsql:
    depends_on:
      db:
        condition: service_healthy
    command: >
      /bin/bash -c "
      while ! mysqladmin ping -h \"$$MYSQL_HOST\" --silent; do
        sleep 1;
      done;
      while true; do
        echo 'Starting backup...';
        MYSQL_PWD=$$MYSQL_PASSWORD mysqldump -h $$MYSQL_HOST -u $$MYSQL_USER ${MYSQL_DATABASE} > /backup/${MYSQL_DATABASE}_backup.sql;
        echo 'Backup complete.';
        sleep 86400;
      done"

द्विस्तरीय बैकअप रणनीति

अधिकतम डेटा सुरक्षा सुनिश्चित करने के लिए, मैं दो पूरक बैकअप विधियों को लागू करने की सलाह देता हूं:

1. wpsql कंटेनर द्वारा स्वचालित दैनिक बैकअप

  • एकीकृत सिस्टम घटक के रूप में चलता है
  • कंटेनर हेल्थ चेकिंग का लाभ उठाता है
  • नियमित, निर्धारित बैकअप प्रदान करता है
  • न्यूनतम मैनुअल हस्तक्षेप की आवश्यकता होती है

2. अस्थायी वातावरण का उपयोग कर मैनुअल बैकअप

  • डिप्लॉयमेंट से पहले सत्यापन के लिए उपयुक्त
  • प्रमुख सिस्टम परिवर्तनों से पहले आवश्यक
  • टेस्ट डेटा कॉपी बनाने के लिए उपयोगी
  • आपातकालीन बैकअप विकल्प प्रदान करता है

3. उन्नत निगरानी और प्रबंधन

बैकअप विश्वसनीयता सुनिश्चित करने के लिए कई निगरानी प्रथाओं को लागू किया है:

निगरानी के विस्तृत तरीके

A. हेल्थ चेक निगरानी

# कंटेनर स्थिति की जांच
docker ps

# हेल्थ चेक विवरण सत्यापित करें
docker inspect wordpress-db | grep -A 10 Health

B. बैकअप सत्यापन

# बैकअप फ़ाइलों की सूची
ls -l backup/

# हाल की बैकअप फ़ाइल का आकार जांचें
find backup/ -type f -name "*.sql" -mtime -1 -ls

C. लॉग निगरानी

# बैकअप कंटेनर के लॉग की जांच
docker logs wpsql

4. रिकवरी प्रक्रियाएं

A. बैकअप से पुनर्स्थापना

# डेटाबेस की पुनर्स्थापना
docker exec -i wordpress-db mysql -u root -p${MYSQL_ROOT_PASSWORD} < backup/[बैकअप_फ़ाइल_नाम].sql

B. आपातकालीन रिकवरी चरण

  1. प्रभावित कंटेनर को रोकें
docker-compose stop
  1. डेटा डायरेक्टरी का बैकअप बनाएं
sudo cp -r db_data db_data_backup_$(date +%Y%m%d)
  1. नए कंटेनर को आरंभ करें
docker-compose up -d
  1. डेटा की पुनर्स्थापना
docker exec -i wordpress-db mysql -u root -p${MYSQL_ROOT_PASSWORD} < backup/[बैकअप_फ़ाइल_नाम].sql

तैयार WordPress समाधान

यदि आप इस समाधान को लागू करना चाहते हैं, तो मैंने सभी आवश्यक स्क्रिप्ट और कॉन्फ़िगरेशन के साथ एक GitHub रिपॉजिटरी बनाई है:

GitHub रिपॉजिटरी: wpbk

निष्कर्ष

MySQL 9.1 और WordPress बैकअप के साथ इस अनुभव से, मैंने सीखा कि एक विश्वसनीय बैकअप प्रणाली के लिए कई तत्व महत्वपूर्ण हैं:

1. उचित हेल्थ चेक कार्यान्वयन

  • नियमित कंटेनर स्थिति निगरानी
  • स्वचालित स्वास्थ्य सत्यापन
  • समस्याओं का त्वरित पता लगाना

2. बैकअप रणनीतियों की द्विस्तरीय प्रणाली

  • स्वचालित दैनिक बैकअप
  • मैनुअल बैकअप क्षमताएं
  • कई बैकअप स्टोरेज स्थान

3. निरंतर निगरानी

  • नियमित लॉग समीक्षा
  • बैकअप फ़ाइल सत्यापन
  • सिस्टम स्थिति की जांच

4. स्पष्ट रिकवरी प्रक्रियाएं

  • प्रलेखित पुनर्स्थापना चरण
  • परीक्षण किए गए रिकवरी प्रक्रियाएं
  • आपातकालीन प्रतिक्रिया योजनाएं

इन तत्वों को लागू करके, हमने RHEL/AlmaLinux पर MySQL 9.1 के साथ WordPress वातावरण के लिए एक अधिक मजबूत और विश्वसनीय बैकअप प्रणाली बनाई है।

शिक्षा

If you like this article, please
Follow !

आइये इस पोस्ट को साझा करें!
विषयसूची