🐡 👎🏾 ☮️ कुबेरनेट्स टिप्स एंड ट्रिक्स: बड़े डेटाबेस के बूटस्ट्रैप को तेज करना 🏺 🎈 🐩

इस लेख के साथ, हम व्यावहारिक निर्देशों के साथ प्रकाशनों की एक श्रृंखला खोलते हैं कि कैसे खुद को (ऑपरेशन) और डेवलपर्स को विभिन्न स्थितियों में आसान बनाया जाए जो कि हर दिन शाब्दिक रूप से होते हैं। उन सभी को ग्राहकों से समस्याओं को हल करने में वास्तविक अनुभव से एकत्र किया गया है और समय के साथ सुधार हुआ है, लेकिन फिर भी आदर्श होने का दावा नहीं करते हैं - उन्हें विचारों और रिक्तता के रूप में अधिक समझें।

मैं विभिन्न जरूरतों के लिए अपनी त्वरित तैनाती के लिए MySQL और PostgreSQL जैसे बड़े डेटाबेस डंप तैयार करने में एक "ट्रिक" से शुरू करूंगा - सबसे पहले, डेवलपर्स के लिए प्लेटफार्मों पर। नीचे वर्णित कार्यों का संदर्भ हमारा विशिष्ट वातावरण है, जिसमें एक कामकाजी कुबेरनेट क्लस्टर और सीआई / सीडी के लिए गिटलैब (और डैप ) का उपयोग शामिल है। चलो चलते हैं!

सुविधा शाखा का उपयोग करते समय कुबेरनेट्स में मुख्य दर्द बड़े डेटाबेस होते हैं, जब डेवलपर्स उत्पादन से पूर्ण (या लगभग पूर्ण) डेटाबेस पर अपने परिवर्तनों का परीक्षण / प्रदर्शन करना चाहते हैं। उदाहरण के लिए:

1 टीबी और 10 डेवलपर्स के लिए MySQL में एक डेटाबेस के साथ एक एप्लिकेशन है जो अपनी विशेषताओं को विकसित करते हैं।
डेवलपर्स व्यक्तिगत परीक्षण लूप चाहते हैं और परीक्षण और / या डेमो के लिए कुछ और विशिष्ट लूप्स।
इसके अलावा, एक संत समय के लिए अपने परीक्षण सर्किट में उत्पादन आधार के नाइट डंप को बहाल करने की आवश्यकता है - क्लाइंट या बग के साथ समस्या को पुन: उत्पन्न करने के लिए।
अंत में, डेटाबेस के आकार को कम से कम 150 जीबी तक कम करना संभव है - इतना नहीं, लेकिन फिर भी अंतरिक्ष को बचाएं। यानी हमें अभी भी किसी तरह डंप तैयार करने की आवश्यकता है।

नोट : आमतौर पर हम पेरकोना से इनोबैकअप का उपयोग करके MySQL का बैकअप लेते हैं, जो हमें सभी डेटाबेस और उपयोगकर्ताओं को बचाने की अनुमति देता है ... - संक्षेप में, वह सब कुछ जो आवश्यक हो सकता है। यह एक ऐसा उदाहरण है जिसे लेख में आगे माना जाता है, हालांकि सामान्य मामले में यह बिल्कुल मायने नहीं रखता है कि आप बैकअप कैसे बनाते हैं।

तो, मान लें कि हमारे पास एक डेटाबेस बैकअप है। आगे क्या करना है?

चरण 1: डंप से एक नया डेटाबेस तैयार करना

सबसे पहले, हम कुबेरनेट्स परिनियोजन में बनाएंगे, जिसमें दो इनिट कंटेनर (यानी, ऐसे विशेष कंटेनर शामिल होंगे जो एप्लिकेशन के चूल्हे से पहले चलते हैं और आपको पूर्व-विन्यास करने की अनुमति देते हैं) और एक चूल्हा।

लेकिन इसे कहां रखें? हमारे पास एक बड़ा डेटाबेस (1 टीबी) है और हम इसके दस उदाहरणों को उठाना चाहते हैं - हमें एक बड़ी डिस्क (10% टीबी) वाले सर्वर की आवश्यकता है। हम इसे इस कार्य के लिए अलग से ऑर्डर करते हैं और इस सर्वर के साथ नोड को एक विशेष लेबल के साथ चिह्नित करते हैं dedicated: non-prod-db । उसी समय, हम नामांकित टेंट का उपयोग करेंगे, जिसे कुबेरनेट्स कहेंगे कि केवल ऐसे अनुप्रयोग जो कि प्रतिरोधी ( सहनशीलता ) हैं, इस नोड में रोल कर सकते हैं, अर्थात, कुबेरनेट्स को भाषा में अनुवाद करते हुए, dedicated Equal non-prod-db डीएलबी dedicated Equal non-prod-db ।

nodeSelector और tolerations का उपयोग करते हुए tolerations वांछित नोड (एक बड़ी डिस्क के साथ सर्वर पर स्थित) का चयन करें:

  nodeSelector: dedicated: non-prod-db tolerations: - key: "dedicated" operator: "Equal" value: "non-prod-db" effect: "NoExecute"

... और इस नोड की सामग्री का विवरण लें।

Init कंटेनर: get-bindump

पहला get-bindump कंटेनर जिसे हम get-bindump । यह emptyDir ( /var/lib/mysql in /var/lib/mysql ) को माउंट करता है, जहां बैकअप सर्वर से प्राप्त डेटाबेस डंप को जोड़ा जाएगा। ऐसा करने के लिए, कंटेनर में वह सब कुछ है जो आपको चाहिए: SSH कुंजियाँ, बैकअप सर्वर पते। हमारे मामले में इस चरण में लगभग 2 घंटे लगते हैं।

तैनाती में इस कंटेनर का विवरण निम्नानुसार है:

  - name: get-bindump image: db-dumps imagePullPolicy: Always command: [ "/bin/sh", "-c", "/get_bindump.sh" ] resources: limits: memory: "5000Mi" cpu: "1" requests: memory: "5000Mi" cpu: "1" volumeMounts: - name: dump mountPath: /dump - name: mysqlbindir mountPath: /var/lib/mysql - name: id-rsa mountPath: /root/.ssh

कंटेनर में प्रयुक्त get_bindump.sh स्क्रिप्ट:

 #!/bin/bash date if [ -f /dump/version.txt ]; then echo "Dump file already exists." exit 0 fi rm -rf /var/lib/mysql/* borg extract --stdout user@your.server.net:somedb-mysql::${lastdump} stdin | xbstream -x -C /var/lib/mysql/ echo $lastdump > /dump/version.txt

इनिट कंटेनर: रेडी-बिंदंप

बैकअप डाउनलोड करने के बाद, दूसरा prepare-bindump कंटेनर लॉन्च किया गया है - prepare-bindump । यह innobackupex --apply-log क्रियान्वित करता है (चूंकि फाइलें पहले से ही /var/lib/mysql - get-bindump से emptyDir के लिए धन्यवाद) और MySQL सर्वर शुरू होता है।

यह इस init कंटेनर में है कि हम डेटाबेस के लिए सभी आवश्यक रूपांतरण करते हैं, इसे चयनित एप्लिकेशन के लिए तैयार कर रहे हैं: हम उन तालिकाओं को साफ़ करते हैं जिनके लिए यह अनुमेय है, डेटाबेस के अंदर एक्सेस को बदलते हैं, आदि। तब हम MySQL सर्वर को बंद कर देते हैं और बस एक टारगेज फ़ाइल में संपूर्ण /var/lib/mysql को संग्रहीत करते हैं। नतीजतन, डंप 100 जीबी फ़ाइल में फिट बैठता है, जो पहले से ही मूल 1 टीबी से छोटे परिमाण का एक आदेश है। इस चरण में लगभग 5 घंटे लगते हैं।

परिनियोजन में दूसरे इनिट कंटेनर का विवरण:

  - name: prepare-bindump image: db-dumps imagePullPolicy: Always command: [ "/bin/sh", "-c", "/prepare_bindump.sh" ] resources: limits: memory: "5000Mi" cpu: "1" requests: memory: "5000Mi" cpu: "1" volumeMounts: - name: dump mountPath: /dump - name: mysqlbindir mountPath: /var/lib/mysql - name: debian-cnf mountPath: /etc/mysql/debian.cnf subPath: debian.cnf

prepare_bindump.sh उपयोग किया गया लिपि कुछ इस प्रकार है:

 #!/bin/bash date if [ -f /dump/healthz ]; then echo "Dump file already exists." exit 0 fi innobackupex --apply-log /var/lib/mysql/ chown -R mysql:mysql /var/lib/mysql chown -R mysql:mysql /var/log/mysql echo "`date`: Starting mysql" /usr/sbin/mysqld --character-set-server=utf8 --collation-server=utf8_general_ci --innodb-data-file-path=ibdata1:200M:autoextend --user=root --skip-grant-tables & sleep 200 echo "`date`: Creating mysql root user" echo "update mysql.user set Password=PASSWORD('password') WHERE user='root';" | mysql -uroot -h 127.0.0.1 echo "delete from mysql.user where USER like '';" | mysql -uroot -h 127.0.0.1 echo "delete from mysql.user where user = 'root' and host NOT IN ('127.0.0.1', 'localhost');" | mysql -uroot -h 127.0.0.1 echo "FLUSH PRIVILEGES;" | mysql -uroot -h 127.0.0.1 echo "truncate somedb.somedb_table_one;" | mysql -uroot -h 127.0.0.1 -ppassword somedb /usr/bin/mysqladmin shutdown -uroot -ppassword cd /var/lib/mysql/ tar -czf /dump/mysql_bindump.tar.gz ./* touch /dump/healthz rm -rf /var/lib/mysql/*

नीचे

अंतिम राग मुख्य चूल्हा का प्रक्षेपण है, जो इनिट कंटेनर के निष्पादन के बाद होता है। फली में, हमारे पास एक सरल emtpyDir , और emtpyDir माध्यम से 100 जीबी का emtpyDir संपीड़ित और फसली डंप emtpyDir । इस नग्नेक्स का कार्य इस डंप को देना है।

चूल्हा विन्यास:

  - name: nginx image: nginx:alpine resources: requests: memory: "1500Mi" cpu: "400m" lifecycle: preStop: exec: command: ["/usr/sbin/nginx", "-s", "quit"] livenessProbe: httpGet: path: /healthz port: 80 scheme: HTTP timeoutSeconds: 7 failureThreshold: 5 volumeMounts: - name: dump mountPath: /usr/share/nginx/html - name: nginx-config mountPath: /etc/nginx/nginx.conf subPath: nginx.conf readOnly: false volumes: - name: dump emptyDir: {} - name: mysqlbindir emptyDir: {}

यह वही है जो तैनाती अपने initContainers के साथ दिखता है ...

 --- apiVersion: apps/v1beta1 kind: Deployment metadata: name: db-dumps spec: strategy: rollingUpdate: maxUnavailable: 0 revisionHistoryLimit: 2 template: metadata: labels: app: db-dumps spec: imagePullSecrets: - name: regsecret nodeSelector: dedicated: non-prod-db tolerations: - key: "dedicated" operator: "Equal" value: "non-prod-db" effect: "NoExecute" initContainers: - name: get-bindump image: db-dumps imagePullPolicy: Always command: [ "/bin/sh", "-c", "/get_bindump.sh" ] resources: limits: memory: "5000Mi" cpu: "1" requests: memory: "5000Mi" cpu: "1" volumeMounts: - name: dump mountPath: /dump - name: mysqlbindir mountPath: /var/lib/mysql - name: id-rsa mountPath: /root/.ssh - name: prepare-bindump image: db-dumps imagePullPolicy: Always command: [ "/bin/sh", "-c", "/prepare_bindump.sh" ] resources: limits: memory: "5000Mi" cpu: "1" requests: memory: "5000Mi" cpu: "1" volumeMounts: - name: dump mountPath: /dump - name: mysqlbindir mountPath: /var/lib/mysql - name: log mountPath: /var/log/mysql - name: debian-cnf mountPath: /etc/mysql/debian.cnf subPath: debian.cnf containers: - name: nginx image: nginx:alpine resources: requests: memory: "1500Mi" cpu: "400m" lifecycle: preStop: exec: command: ["/usr/sbin/nginx", "-s", "quit"] livenessProbe: httpGet: path: /healthz port: 80 scheme: HTTP timeoutSeconds: 7 failureThreshold: 5 volumeMounts: - name: dump mountPath: /usr/share/nginx/html - name: nginx-config mountPath: /etc/nginx/nginx.conf subPath: nginx.conf readOnly: false volumes: - name: dump emptyDir: {} - name: mysqlbindir emptyDir: {} - name: log emptyDir: {} - name: id-rsa secret: defaultMode: 0600 secretName: somedb-id-rsa - name: nginx-config configMap: name: somedb-nginx-config - name: debian-cnf configMap: name: somedb-debian-cnf --- apiVersion: v1 kind: Service metadata: name: somedb-db-dump spec: clusterIP: None selector: app: db-dumps ports: - name: http port: 80

अतिरिक्त नोट:

हमारे मामले में, हम GitLab में अनुसूचित नौकरी का उपयोग करके हर रात एक नया डंप तैयार करते हैं। यानी हर रात, यह परिनियोजन स्वचालित रूप से रोल आउट हो जाता है, जो एक ताज़ा डंप खींचता है और इसे सभी परीक्षण डेवलपर वातावरण में वितरण के लिए तैयार करता है।
क्यों हम मात्रा /dump को init कंटेनरों में फेंक रहे हैं (और स्क्रिप्ट में /dump/version.txt के अस्तित्व की /dump/version.txt )? यह उस स्थिति में किया जाता है जब सर्वर जिस के तहत चलता है उसे फिर से चालू किया जाता है। कंटेनर शुरू हो जाएंगे और इस जांच के बिना, डंप फिर से डाउनलोड करना शुरू कर देगा। यदि हमने पहले ही एक बार एक डंप तैयार कर लिया है, तो अगली शुरुआत में (सर्वर रिबूट के मामले में), /dump/version.txt फ्लैग /dump/version.txt इस बारे में सूचित करेगी।

db-dumps क्या है? हम इसे डैप के साथ इकट्ठा करते हैं और इसका Dappfile इस तरह दिखता है:

 dimg: "db-dumps" from: "ubuntu:16.04" docker: ENV: TERM: xterm ansible: beforeInstall: - name: "Install percona repositories" apt: deb: https://repo.percona.com/apt/percona-release_0.1-4.xenial_all.deb - name: "Add repository for borgbackup" apt_repository: repo="ppa:costamagnagianfranco/borgbackup" codename="xenial" update_cache=yes - name: "Add repository for mysql 5.6" apt_repository: repo: deb http://archive.ubuntu.com/ubuntu trusty universe state: present update_cache: yes - name: "Install packages" apt: name: "{{`{{ item }}`}}" state: present with_items: - openssh-client - mysql-server-5.6 - mysql-client-5.6 - borgbackup - percona-xtrabackup-24 setup: - name: "Add get_bindump.sh" copy: content: | {{ .Files.Get ".dappfiles/get_bindump.sh" | indent 8 }} dest: /get_bindump.sh mode: 0755 - name: "Add prepare_bindump.sh" copy: content: | {{ .Files.Get ".dappfiles/prepare_bindump.sh" | indent 8 }} dest: /prepare_bindump.sh mode: 0755

चरण 2: डेटाबेस को डेवलपर वातावरण में लॉन्च करना

डेवलपर के परीक्षण वातावरण में MySQL डेटाबेस को रोल आउट करते समय, इसमें GitLab का एक बटन होता है, जो कि RollingUpdate.maxUnavailable: 0 रणनीति के साथ MySQL के साथ परिनियोजन का पुन: लॉन्च करता है RollingUpdate.maxUnavailable: 0 :

इसे कैसे लागू किया जाता है?

GitLab में, जब आप पुनः लोड db पर क्लिक करते हैं, तो निम्न विनिर्देशन के साथ परिनियोजन लागू होता है:

 spec: strategy: rollingUpdate: maxUnavailable: 0

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

इस योजना के बारे में विवरण निम्नलिखित सामग्रियों में पाया जा सकता है:

एक रोलिंग अपडेट (कुबेरनेट्स प्रलेखन) का प्रदर्शन ;
कुबरनेट्स डिप्लॉयमेंट (टा-चिंग चेन) के साथ रोलिंग अपडेट ;
कुबेरनेट्स तैनाती रणनीतियाँ (कंटेनर समाधान) ।

चुना हुआ दृष्टिकोण हमें तब तक प्रतीक्षा करने की अनुमति देता है जब तक कि एक नया डंप डाउनलोड नहीं किया जाता है, अनज़िप और लॉन्च किया जाता है, और उसके बाद ही पुराने को MySQL से हटा दिया जाएगा। इस प्रकार, जब हम एक नया डंप तैयार कर रहे हैं, हम चुपचाप पुराने आधार के साथ काम कर रहे हैं।

इस परिनियोजन के init कंटेनर निम्न आदेश का उपयोग करता है:

 curl "$DUMP_URL" | tar -C /var/lib/mysql/ -xvz

यानी हम चरण 1 में तैयार किया गया संपीड़ित डेटाबेस डंप डाउनलोड करते हैं, इसे /var/lib/mysql अनज़िप करते हैं, और फिर परिनियोजन के अंतर्गत शुरू होता है, जिसमें MySQL पहले से तैयार किए गए डेटा के साथ लॉन्च किया जाता है। यह सब लगभग 2 घंटे लगते हैं।

और तैनाती इस प्रकार है ...

 apiVersion: apps/v1beta1 kind: Deployment metadata: name: mysql spec: strategy: rollingUpdate: maxUnavailable: 0 template: metadata: labels: service: mysql spec: imagePullSecrets: - name: regsecret nodeSelector: dedicated: non-prod-db tolerations: - key: "dedicated" operator: "Equal" value: "non-prod-db" effect: "NoExecute" initContainers: - name: getdump image: mysql-with-getdump command: ["/usr/local/bin/getdump.sh"] resources: limits: memory: "6000Mi" cpu: "1.5" requests: memory: "6000Mi" cpu: "1.5" volumeMounts: - mountPath: /var/lib/mysql name: datadir - mountPath: /etc/mysql/debian.cnf name: debian-cnf subPath: debian.cnf env: - name: DUMP_URL value: "http://somedb-db-dump.infra-db.svc.cluster.local/mysql_bindump.tar.gz" containers: - name: mysql image: mysql:5.6 resources: limits: memory: "1024Mi" cpu: "1" requests: memory: "1024Mi" cpu: "1" lifecycle: preStop: exec: command: ["/etc/init.d/mysql", "stop"] ports: - containerPort: 3306 name: mysql protocol: TCP volumeMounts: - mountPath: /var/lib/mysql name: datadir - mountPath: /etc/mysql/debian.cnf name: debian-cnf subPath: debian.cnf env: - name: MYSQL_ROOT_PASSWORD value: "password" volumes: - name: datadir emptyDir: {} - name: debian-cnf configMap: name: somedb-debian-cnf --- apiVersion: v1 kind: Service metadata: name: mysql spec: clusterIP: None selector: service: mysql ports: - name: mysql port: 3306 protocol: TCP --- apiVersion: v1 kind: ConfigMap metadata: name: somedb-debian-cnf data: debian.cnf: | [client] host = localhost user = debian-sys-maint password = password socket = /var/run/mysqld/mysqld.sock [mysql_upgrade] host = localhost user = debian-sys-maint password = password socket = /var/run/mysqld/mysqld.sock

परिणाम

यह पता चला है कि हमारे पास हमेशा परिनियोजन होता है , जो हर रात रोल आउट करता है और निम्नलिखित कार्य करता है:

एक नया डेटाबेस डंप हो जाता है
किसी तरह यह इसे एक परीक्षण वातावरण में सही संचालन के लिए तैयार करता है (उदाहरण के लिए, कुछ टेबलों को ट्रैंक्विटिट करता है, वास्तविक उपयोगकर्ता डेटा को बदलता है, आवश्यक उपयोगकर्ता बनाता है, आदि);
प्रत्येक डेवलपर को सीआई में एक बटन दबाकर तैनाती में अपने नाम स्थान पर ऐसे तैयार डेटाबेस को रोल-अप करने का अवसर प्रदान करता है - इसमें उपलब्ध सेवा के लिए धन्यवाद, डेटाबेस mysql पर उपलब्ध होगा (उदाहरण के लिए, यह नामस्थान में सेवा का नाम हो सकता है)।

उदाहरण के लिए हमने जांच की, एक वास्तविक प्रतिकृति से डंप बनाने में लगभग 6 घंटे लगते हैं, एक "बेस इमेज" तैयार करने में 7 घंटे लगते हैं, और डेवलपर के वातावरण में डेटाबेस को अपडेट करने में 2 घंटे लगते हैं। चूंकि पहले दो कार्य "पृष्ठभूमि में" किए जाते हैं और डेवलपर्स के लिए अदृश्य होते हैं, वास्तव में वे उसी 2 घंटों के लिए डेटाबेस (1 टीबी के आकार के साथ) के उत्पादन संस्करण को तैनात कर सकते हैं।

प्रस्तावित योजना और इसके घटकों के प्रश्नों, आलोचनाओं और सुधारों का टिप्पणियों में स्वागत है!

PS, निश्चित रूप से, हम समझते हैं कि VMware और कुछ अन्य उपकरणों के मामले में, वर्चुअल स्नैपशॉट बनाने और स्नैपशॉट से एक नया वायरसकाल्का लॉन्च करना संभव होगा (जो कि और भी तेज है), लेकिन इस विकल्प में आधार तैयार करना शामिल नहीं है, यह ध्यान में रखते हुए कि यह वही होगा। समय ... इस तथ्य का उल्लेख नहीं करना कि सभी के पास वाणिज्यिक उत्पादों का उपयोग करने का अवसर या इच्छा नहीं है।

पी पी एस

K8s टिप्स एंड ट्रिक्स चक्र से अन्य:

हमारे ब्लॉग में भी पढ़ें:

" डब और GitLab CI का उपयोग करके कुबेरनेट्स में एप्लिकेशन बनाएं और स्थापित करें ";
“ डैप के साथ अभ्यास करें। भाग 1: सरल अनुप्रयोगों का निर्माण ";
“ डैप के साथ अभ्यास करें। भाग 2. हेल्म का उपयोग करते हुए कुबेरनेट्स में डॉकर छवियों की तैनाती ";
" कुबेरनेट्स में कॉकरोच डीबीएमएस ऑर्केस्ट्रेशन ";
" छोटी परियोजनाओं में कुबेरनेट्स के साथ हमारा अनुभव " (वीडियो रिपोर्ट, जिसमें कुबेरनेट्स के तकनीकी उपकरण का परिचय शामिल है);
" कुबेरनेट्स के साथ काम करते समय उपयोगी उपयोगिताएँ ।"

कुबेरनेट्स टिप्स एंड ट्रिक्स: बड़े डेटाबेस के बूटस्ट्रैप को तेज करना