कठपुतली के साथ डेटाबेस स्वचालन:MySQL और मारियाडीबी गैलेरा क्लस्टर की तैनाती

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

कठपुतली के साथ गैलेरा क्लस्टर

जैसा कि आप जानते होंगे, गैलेरा क्लस्टर के तीन मुख्य प्रदाता हैं:

• MySQL गैलेरा क्लस्टर (कोडरशिप)
• पेरकोना एक्स्ट्राडीबी क्लस्टर (पेरकोना)
• MariaDB क्लस्टर (MariaDB द्वारा MariaDB सर्वर में एम्बेड किया गया)

गैलेरा क्लस्टर परिनियोजन के साथ एक सामान्य अभ्यास लोड संतुलन उद्देश्यों के लिए डेटाबेस क्लस्टर के शीर्ष पर एक अतिरिक्त परत बैठना है। हालांकि, यह एक जटिल प्रक्रिया है जो अपने पद के योग्य है।

कठपुतली फोर्ज में कई कठपुतली मॉड्यूल उपलब्ध हैं जिनका उपयोग गैलेरा क्लस्टर को तैनात करने के लिए किया जा सकता है। यहाँ उनमें से कुछ हैं..

• puppetlabs/mysql - केवल मारियाडीबी गैलेरा
• freenki/galera - Percona XtraDB क्लस्टर और MySQL Galera कोडरशिप से
• edestecd/mariadb - केवल मारियाडीबी क्लस्टर
• फ़िलियाडेटा/पेरकोना - पेरकोना एक्स्ट्राडीबी क्लस्टर

चूंकि हमारा उद्देश्य गैलेरा क्लस्टर के लिए मैनिफेस्ट लिखने और तैनाती को स्वचालित करने की बुनियादी समझ प्रदान करना है, इसलिए हम कठपुतली लैब्स / माइस्क्ल मॉड्यूल का उपयोग करके मारियाडीबी गैलेरा क्लस्टर की तैनाती को कवर करेंगे। अन्य मॉड्यूल के लिए, आप निर्देशों या सुझावों के लिए हमेशा उनके संबंधित दस्तावेज़ देख सकते हैं कि कैसे स्थापित किया जाए।

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

एक बार शुरू होने के बाद, नोड एक प्राथमिक घटक बन जाएगा और शेष नोड्स को मानक mysql स्टार्ट कमांड का उपयोग करके शुरू किया जा सकता है (systemctl start mysql या सेवा mysql start ) के बाद एक पूर्ण-होस्ट कनेक्शन स्ट्रिंग (gcomm://db1,db2,db3)। बूटस्ट्रैपिंग की आवश्यकता केवल तभी होती है जब क्लस्टर में किसी अन्य नोड द्वारा कोई प्राथमिक घटक धारण नहीं किया जाता है (wsrep_cluster_status के साथ जांचें) स्थिति)।

क्लस्टर स्टार्टअप प्रक्रिया को उपयोगकर्ता द्वारा स्पष्ट रूप से किया जाना चाहिए। डेटा हानि के किसी भी जोखिम से बचने के लिए मैनिफेस्ट को पहले रन पर क्लस्टर (किसी भी नोड को बूटस्ट्रैप) शुरू नहीं करना चाहिए। याद रखें, कठपुतली मैनिफेस्ट को यथासंभव निष्क्रिय होने के लिए लिखा जाना चाहिए। पहले से चल रहे MySQL इंस्टेंस को प्रभावित किए बिना कई बार निष्पादित करने के लिए मैनिफेस्ट सुरक्षित होना चाहिए। इसका मतलब है कि हमें मुख्य रूप से रिपोजिटरी कॉन्फ़िगरेशन, पैकेज इंस्टॉलेशन, प्री-रनिंग कॉन्फ़िगरेशन और एसएसटी उपयोगकर्ता कॉन्फ़िगरेशन पर ध्यान केंद्रित करना होगा।

गैलेरा के लिए निम्नलिखित विन्यास विकल्प अनिवार्य हैं:

• wsrep_on :गैलेरा क्लस्टर (केवल मारियाडीबी) के लिए राइटसेट प्रतिकृति एपीआई चालू करने के लिए एक ध्वज।
• wsrep_cluster_name :क्लस्टर का नाम। एक ही क्लस्टर के सभी नोड्स पर समान होना चाहिए।
• wsrep_cluster_address :गैलेरा संचार कनेक्शन स्ट्रिंग, उपसर्ग के साथ gcomm:// और उसके बाद नोड सूची, अल्पविराम द्वारा अलग की जाती है। खाली नोड सूची का मतलब है क्लस्टर इनिशियलाइज़ेशन।
• wsrep_provider :वह रास्ता जहां गैलेरा पुस्तकालय रहता है। ऑपरेटिंग सिस्टम के आधार पर पथ भिन्न हो सकता है।
• bind_address :MySQL बाहरी रूप से पहुंच योग्य होना चाहिए इसलिए मान '0.0.0.0' अनिवार्य है।
• wsrep_sst_method :मारियाडीबी के लिए, पसंदीदा एसएसटी विधि मारियाबैकअप है।
• wsrep_sst_auth :स्नैपशॉट स्थानांतरण करने के लिए MySQL उपयोगकर्ता और पासवर्ड (कोलन द्वारा अलग)। आम तौर पर, हम एक ऐसे उपयोगकर्ता को निर्दिष्ट करते हैं जो एक पूर्ण बैकअप बनाने की क्षमता रखता है।
• wsrep_node_address :गैलेरा संचार और प्रतिकृति के लिए आईपी पता। सही आईपी पता चुनने के लिए कठपुतली कारक का प्रयोग करें।
• wsrep_node_name :FQDN का होस्टनाम। सही होस्टनाम चुनने के लिए कठपुतली कारक का प्रयोग करें।

डेबियन-आधारित परिनियोजन के लिए, पोस्ट-इंस्टॉलेशन स्क्रिप्ट स्वचालित रूप से मारियाडीबी सर्वर को शुरू करने का प्रयास करेगी। अगर हमने wsrep_on=ON (गैलेरा को सक्षम करने के लिए ध्वज) को wsrep_cluster_address में पूरे पते के साथ कॉन्फ़िगर किया है चर, सर्वर स्थापना के दौरान विफल हो जाएगा। ऐसा इसलिए है क्योंकि इसमें कनेक्ट करने के लिए कोई प्राथमिक घटक नहीं है।

गैलेरा में क्लस्टर को ठीक से शुरू करने के लिए पहले नोड (बूटस्ट्रैप नोड कहा जाता है) को प्राथमिक घटक के रूप में नोड शुरू करने के लिए एक खाली कनेक्शन स्ट्रिंग (wsrep_cluster_address =gcomm://) के साथ कॉन्फ़िगर किया जाना है। आप प्रदान की गई बूटस्ट्रैप स्क्रिप्ट भी चला सकते हैं, जिसे galera_new_cluster कहा जाता है, जो मूल रूप से पृष्ठभूमि के अलावा एक समान काम करती है।

गैलेरा क्लस्टर (MariaDB) का परिनियोजन

गैलेरा क्लस्टर के परिनियोजन के लिए एपीटी स्रोत पर पसंदीदा मारियाडीबी संस्करण भंडार स्थापित करने के लिए अतिरिक्त कॉन्फ़िगरेशन की आवश्यकता होती है।

ध्यान दें कि गैलेरा प्रतिकृति मारियाडीबी सर्वर के अंदर एम्बेडेड है और इसे स्थापित करने के लिए कोई अतिरिक्त पैकेज की आवश्यकता नहीं है। कहा जा रहा है, wsrep_on=ON का उपयोग करके गैलेरा को सक्षम करने के लिए एक अतिरिक्त ध्वज की आवश्यकता है। इस ध्वज के बिना, मारियाडीबी एक स्टैंडअलोन सर्वर के रूप में कार्य करेगा।

हमारे डेबियन-आधारित वातावरण में, wsrep_on विकल्प केवल पहली परिनियोजन पूर्ण होने के बाद ही मेनिफेस्ट में मौजूद हो सकता है (जैसा कि परिनियोजन चरणों में और नीचे दिखाया गया है)। यह सुनिश्चित करने के लिए है कि कठपुतली के लिए गैलेरा नोड बनने के लिए पूरी तरह से तैयार होने से पहले नोड का प्रावधान करने के लिए पहला, प्रारंभिक प्रारंभ एक स्टैंडअलोन सर्वर के रूप में कार्य करता है।

आइए नीचे दी गई मेनिफेस्ट सामग्री तैयार करके शुरू करें (यदि आवश्यक हो तो वैश्विक चर अनुभाग को संशोधित करें):

# Puppet manifest for Galera Cluster MariaDB 10.3 on Ubuntu 18.04 (Puppet v6.4.2) 
# /etc/puppetlabs/code/environments/production/manifests/galera.pp

# global vars
$sst_user         = 'sstuser'
$sst_password     = 'S3cr333t$'
$backup_dir       = '/home/backup/mysql'
$mysql_cluster_address = 'gcomm://192.168.0.161,192.168.0.162,192.168.0.163'


# node definition
node "db1.local", "db2.local", "db3.local" {
  Apt::Source['mariadb'] ~>
  Class['apt::update'] ->
  Class['mysql::server'] ->
  Class['mysql::backup::xtrabackup']
}

# apt module must be installed first: 'puppet module install puppetlabs-apt'
include apt

# custom repository definition
apt::source { 'mariadb':
  location => 'http://sfo1.mirrors.digitalocean.com/mariadb/repo/10.3/ubuntu',
  release  => $::lsbdistcodename,
  repos    => 'main',
  key      => {
    id     => 'A6E773A1812E4B8FD94024AAC0F47944DE8F6914',
    server => 'hkp://keyserver.ubuntu.com:80',
  },
  include  => {
    src    => false,
    deb    => true,
  },
}

# Galera configuration
class {'mysql::server':
  package_name            => 'mariadb-server',
  root_password           => '[email protected]#',
  service_name            => 'mysql',
  create_root_my_cnf      => true,
  remove_default_accounts => true,
  manage_config_file      => true,
  override_options        => {
    'mysqld' => {
      'datadir'                 => '/var/lib/mysql',
      'bind_address'            => '0.0.0.0',
      'binlog-format'           => 'ROW',
      'default-storage-engine'  => 'InnoDB',
      'wsrep_provider'          => '/usr/lib/galera/libgalera_smm.so',
      'wsrep_provider_options'  => 'gcache.size=1G',
      'wsrep_cluster_name'      => 'galera_cluster',
      'wsrep_cluster_address'   => $mysql_cluster_address,
      'log-error'               => '/var/log/mysql/error.log',
      'wsrep_node_address'      => $facts['networking']['interfaces']['enp0s8']['ip'],
      'wsrep_node_name'         => $hostname,
      'innodb_buffer_pool_size' => '512M',
      'wsrep_sst_method'        => 'mariabackup',
      'wsrep_sst_auth'          => "${sst_user}:${sst_password}"
    },
    'mysqld_safe' => {
      'log-error'               => '/var/log/mysql/error.log'
    }
  }
}

# force creation of backup dir if not exist
exec { "mkdir -p ${backup_dir}" :
  path   => ['/bin','/usr/bin'],
  unless => "test -d ${backup_dir}"
}

# create SST and backup user
class { 'mysql::backup::xtrabackup' :
  xtrabackup_package_name => 'mariadb-backup',
  backupuser              => "${sst_user}",
  backuppassword          => "${sst_password}",
  backupmethod            => 'mariabackup',
  backupdir               => "${backup_dir}"
}

# /etc/hosts definition
host {
  'db1.local': ip => '192.168.0.161';
  'db2.local': ip => '192.169.0.162';
  'db3.local': ip => '192.168.0.163';
}

इस बिंदु पर थोड़ा स्पष्टीकरण की आवश्यकता है। 'wsrep_node_address' को उसी IP पते पर इंगित किया जाना चाहिए जो wsrep_cluster_address में घोषित किया गया था। इस माहौल में हमारे मेजबानों के पास दो नेटवर्क इंटरफेस हैं और हम गैलेरा संचार के लिए दूसरे इंटरफेस (जिसे enp0s8 कहा जाता है) का उपयोग करना चाहते हैं (जहां 192.168.0.0/24 नेटवर्क से जुड़ा है)। इसलिए हम नोड से जानकारी प्राप्त करने और इसे कॉन्फ़िगरेशन विकल्प पर लागू करने के लिए कठपुतली कारक का उपयोग करते हैं। बाकी बहुत ही आत्म-व्याख्यात्मक है।

प्रत्येक MariaDB नोड पर, कैटलॉग को रूट उपयोगकर्ता के रूप में लागू करने के लिए निम्न कमांड चलाएँ:

$ puppet agent -t

कैटलॉग को इंस्टॉलेशन और तैयारी के लिए प्रत्येक नोड पर लागू किया जाएगा। एक बार हो जाने के बाद, हमें "override_options => mysqld" अनुभाग के अंतर्गत अपने मेनिफेस्ट में निम्न पंक्ति जोड़नी होगी:

      'wsrep_on'                 => 'ON',

उपरोक्त मारियाडीबी के लिए गैलेरा आवश्यकता को पूरा करेगा। फिर, प्रत्येक MariaDB नोड पर एक बार फिर कैटलॉग लागू करें:

$ puppet agent -t

एक बार हो जाने के बाद, हम अपने क्लस्टर को बूटस्ट्रैप करने के लिए तैयार हैं। चूंकि यह एक नया क्लस्टर है, इसलिए हम किसी भी नोड को संदर्भ नोड उर्फ ​​बूटस्ट्रैप नोड के रूप में चुन सकते हैं। आइए db1.local (192.168.0.161) चुनें और निम्न कमांड चलाएँ:

$ galera_new_cluster #db1

एक बार पहला नोड शुरू होने के बाद, हम शेष नोड को मानक स्टार्ट कमांड (एक समय में एक नोड) के साथ शुरू कर सकते हैं:

$ systemctl restart mariadb #db2 and db3

एक बार शुरू करने के बाद, MySQL त्रुटि लॉग पर /var/log/mysql/error.log पर एक नज़र डालें और सुनिश्चित करें कि लॉग निम्न पंक्ति के साथ समाप्त होता है:

2019-06-10  4:11:10 2 [Note] WSREP: Synchronized with group, ready for connections

ऊपर हमें बताता है कि नोड्स समूह के साथ सिंक्रनाइज़ हैं। फिर हम निम्न आदेश का उपयोग करके स्थिति को सत्यापित कर सकते हैं:

$ mysql -uroot -e 'show status like "wsrep%"'

सभी नोड्स पर सुनिश्चित करें, wsrep_cluster_size , wsrep_cluster_status और wsrep_local_state_comment क्रमशः 3, "प्राथमिक" और "समन्वयित" हैं।

MySQL प्रबंधन

इस मॉड्यूल का उपयोग कई MySQL प्रबंधन कार्यों को करने के लिए किया जा सकता है...

• कॉन्फ़िगरेशन विकल्प (संशोधित करें, लागू करें, कस्टम कॉन्फ़िगरेशन)
• डेटाबेस संसाधन (डेटाबेस, उपयोगकर्ता, अनुदान)
• बैकअप (बनाएं, शेड्यूल करें, बैकअप उपयोगकर्ता, संग्रहण)
• साधारण पुनर्स्थापना (केवल mysqldump)
• प्लगइन्स इंस्टालेशन/सक्रियण

सेवा नियंत्रण

कठपुतली के साथ गैलेरा क्लस्टर का प्रावधान करते समय सबसे सुरक्षित तरीका सभी सेवा नियंत्रण कार्यों को मैन्युअल रूप से संभालना है (कठपुतली को इसे संभालने न दें)। एक साधारण क्लस्टर रोलिंग पुनरारंभ के लिए, मानक सेवा कमांड करेगा। निम्न कमांड को एक बार में एक नोड चलाएँ।

$ systemctl restart mariadb # Systemd
$ service mariadb restart # SysVinit

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

डेटाबेस संसाधन

यह सुनिश्चित करने के लिए कि संबद्ध उपयोगकर्ता और विशेषाधिकारों वाला डेटाबेस मौजूद है, mysql::db वर्ग का उपयोग करें, उदाहरण के लिए:

  # make sure the database and user exist with proper grant
  mysql::db { 'mynewdb':
    user          => 'mynewuser',
    password      => 'passw0rd',
    host          => '192.168.0.%',
    grant         => ['SELECT', 'UPDATE']
  } 

उपरोक्त परिभाषा किसी भी नोड को सौंपी जा सकती है क्योंकि गैलेरा क्लस्टर में प्रत्येक नोड एक मास्टर है।

बैकअप लें और पुनर्स्थापित करें

चूंकि हमने xtrabackup वर्ग का उपयोग करके एक SST उपयोगकर्ता बनाया है, इसलिए कठपुतली बैकअप कार्य के लिए सभी पूर्वापेक्षाएँ कॉन्फ़िगर करेगी - बैकअप उपयोगकर्ता बनाना, गंतव्य पथ तैयार करना, स्वामित्व और अनुमति प्रदान करना, क्रॉन जॉब सेट करना और उपयोग करने के लिए बैकअप कमांड विकल्प सेट करना प्रदान की गई बैकअप स्क्रिप्ट में। प्रत्येक नोड को दो बैकअप नौकरियों के साथ कॉन्फ़िगर किया जाएगा (एक साप्ताहिक पूर्ण और दूसरा दैनिक वृद्धि के लिए) डिफ़ॉल्ट रूप से 11:05 अपराह्न तक जैसा कि आप क्रॉस्टैब आउटपुट से बता सकते हैं:

$ crontab -l
# Puppet Name: xtrabackup-weekly
5 23 * * 0 /usr/local/sbin/xtrabackup.sh --target-dir=/home/backup/mysql --backup
# Puppet Name: xtrabackup-daily
5 23 * * 1-6 /usr/local/sbin/xtrabackup.sh --incremental-basedir=/home/backup/mysql --target-dir=/home/backup/mysql/`date +%F_%H-%M-%S` --backup

यदि आप इसके बजाय mysqldump शेड्यूल करना चाहते हैं, तो बैकअप संसाधन तैयार करने के लिए mysql::server::backup क्लास का उपयोग करें। मान लीजिए कि हमारे मैनिफेस्ट में निम्नलिखित घोषणाएं हैं:

  # Prepare the backup script, /usr/local/sbin/mysqlbackup.sh
  class { 'mysql::server::backup':
    backupuser     => 'backup',
    backuppassword => 'passw0rd',
    backupdir      => '/home/backup',
    backupdirowner => 'mysql',
    backupdirgroup => 'mysql',
    backupdirmode  => '755',
    backuprotate   => 15,
    time           => ['23','30'],   #backup starts at 11:30PM everyday
    include_routines  => true,
    include_triggers  => true,
    ignore_events     => false,
    maxallowedpacket  => '64M'
  }

उपरोक्त कठपुतली को बैकअप स्क्रिप्ट को /usr/local/sbin/mysqlbackup.sh पर कॉन्फ़िगर करने और इसे प्रतिदिन 11:30 बजे शेड्यूल करने के लिए कहता है। यदि आप तत्काल बैकअप बनाना चाहते हैं, तो बस आह्वान करें:

$ mysqlbackup.sh

बहाली के लिए, मॉड्यूल केवल mysql::db वर्ग का उपयोग करके डेटाबेस में सीधे SQL फ़ाइल आयात करके, mysqldump बैकअप विधि के साथ बहाली का समर्थन करता है, उदाहरण के लिए:

mysql::db { 'mydb':
  user     => 'myuser',
  password => 'mypass',
  host     => 'localhost',
  grant    => ['ALL PRIVILEGES'],
  sql      => '/home/backup/mysql/mydb/backup.gz',
  import_cat_cmd => 'zcat',
  import_timeout => 900
}

SQL फ़ाइल केवल एक बार लोड की जाएगी और प्रत्येक रन पर नहीं, जब तक कि Enforce_sql => true का उपयोग नहीं किया जाता है।

कॉन्फ़िगरेशन प्रबंधन

इस उदाहरण में, हमने अपनी कॉन्फ़िगरेशन लाइनों को संरचित करने के लिए manage_config_file => true का उपयोग ओवरराइड_ऑप्शन के साथ किया, जिसे बाद में कठपुतली द्वारा बाहर धकेल दिया जाएगा। मेनिफेस्ट फ़ाइल में कोई भी संशोधन केवल लक्ष्य MySQL कॉन्फ़िगरेशन फ़ाइल की सामग्री को प्रतिबिंबित करेगा। यह मॉड्यूल न तो कॉन्फ़िगरेशन को रनटाइम में लोड करेगा और न ही कॉन्फ़िगरेशन फ़ाइल में परिवर्तनों को पुश करने के बाद MySQL सेवा को पुनरारंभ करेगा। परिवर्तनों को सक्रिय करने के लिए सेवा को फिर से शुरू करने की जिम्मेदारी sysadmin की है।

कस्टम MySQL कॉन्फ़िगरेशन जोड़ने के लिए, हम अतिरिक्त फ़ाइलों को "includedir" में रख सकते हैं, डिफ़ॉल्ट रूप से /etc/mysql/conf.d. यह हमें सेटिंग्स को ओवरराइड करने या अतिरिक्त जोड़ने की अनुमति देता है, जो तब मददगार होता है जब आप mysql::server क्लास में ओवरराइड_ऑप्शन का उपयोग नहीं करते हैं। कठपुतली टेम्पलेट का उपयोग करने की यहाँ अत्यधिक अनुशंसा की जाती है। कस्टम कॉन्फ़िगरेशन फ़ाइल को मॉड्यूल टेम्पलेट निर्देशिका के अंतर्गत रखें (डिफ़ॉल्ट रूप से , /etc/puppetlabs/code/environments/production/modules/mysql/templates) और फिर मेनिफेस्ट में निम्न पंक्तियां जोड़ें:

# Loads /etc/puppetlabs/code/environments/production/modules/mysql/templates/my-custom-config.cnf.erb into /etc/mysql/conf.d/my-custom-config.cnf

file { '/etc/mysql/conf.d/my-custom-config.cnf':
  ensure  => file,
  content => template('mysql/my-custom-config.cnf.erb')
}

कठपुतली बनाम क्लस्टर नियंत्रण

क्या आप जानते हैं कि आप ClusterControl का उपयोग करके MySQL या MariaDB Galera परिनियोजन को भी स्वचालित कर सकते हैं? आप इसे स्थापित करने के लिए, या बस इसे हमारी वेबसाइट से डाउनलोड करके ClusterControl कठपुतली मॉड्यूल का उपयोग कर सकते हैं।

ClusterControl से तुलना करने पर, आप निम्न अंतरों की अपेक्षा कर सकते हैं:

• मेनिफेस्ट लिखने से पहले कठपुतली वाक्य रचना, स्वरूपण, संरचनाओं को समझने के लिए थोड़ा सीखने की अवस्था।
• मेनिफेस्ट का नियमित रूप से परीक्षण किया जाना चाहिए। यह बहुत आम है कि आपको कोड पर एक संकलन त्रुटि मिलेगी, खासकर यदि कैटलॉग को पहली बार लागू किया गया हो।
• कठपुतली कोड को बेवकूफ मानती है। परीक्षण/जांच/सत्यापन की स्थिति एक चल रहे सिस्टम के साथ खिलवाड़ से बचने के लिए लेखक की जिम्मेदारी के अंतर्गत आती है।
• कठपुतली को प्रबंधित नोड पर एक एजेंट की आवश्यकता होती है।
• पिछड़ी असंगति। कुछ पुराने मॉड्यूल नए संस्करण पर सही ढंग से नहीं चलेंगे।
• डेटाबेस/होस्ट मॉनिटरिंग को अलग से सेट करना होगा।

ClusterControl का परिनियोजन विज़ार्ड परिनियोजन प्रक्रिया का मार्गदर्शन करता है:

वैकल्पिक रूप से, आप समान परिणाम प्राप्त करने के लिए "s9s" नामक ClusterControl कमांड लाइन इंटरफ़ेस का उपयोग कर सकते हैं। निम्न आदेश एक तीन-नोड Percona XtraDB क्लस्टर बनाता है (बशर्ते सभी नोड्स को पासवर्ड रहित पहले से कॉन्फ़िगर किया गया हो):

$ s9s cluster --create \
  --cluster-type=galera \
  --nodes='192.168.0.21;192.168.0.22;192.168.0.23' \
  --vendor=percona \
  --cluster-name='Percona XtraDB Cluster 5.7' \
  --provider-version=5.7 \
  --db-admin='root' \
  --db-admin-passwd='$ecR3t^word' \
  --log

इसके अतिरिक्त, क्लस्टरकंट्रोल गैलेरा क्लस्टर - HAproxy, ProxySQL और MariaDB MaxScale के लिए लोड बैलेंसर्स की तैनाती का समर्थन करता है - साथ में आपकी डेटाबेस सेवा के लिए विफलता के किसी भी एकल बिंदु को समाप्त करने के लिए एक वर्चुअल आईपी एड्रेस (कीपलाइव द्वारा प्रदान किया गया) के साथ।

परिनियोजन के बाद, नोड्स/क्लस्टर की निगरानी और पूरी तरह से क्लस्टरकंट्रोल द्वारा प्रबंधित किया जा सकता है, जिसमें स्वचालित विफलता का पता लगाना, स्वचालित पुनर्प्राप्ति, बैकअप प्रबंधन, लोड बैलेंसर प्रबंधन, एसिंक्रोनस स्लेव संलग्न करना, कॉन्फ़िगरेशन प्रबंधन आदि शामिल हैं। इन सभी को एक उत्पाद में एक साथ बंडल किया गया है। औसतन, आपका डेटाबेस क्लस्टर 30 मिनट में तैयार हो जाएगा और चलने लगेगा। लक्ष्य नोड्स के लिए केवल पासवर्ड रहित SSH की आवश्यकता है।

आप पहले से चल रहे गैलेरा क्लस्टर को भी आयात कर सकते हैं, जिसे पपेट (या किसी अन्य माध्यम से) द्वारा क्लस्टर कंट्रोल में तैनात किया गया है ताकि अपने क्लस्टर को इसके साथ आने वाली सभी शानदार सुविधाओं के साथ सुपरचार्ज किया जा सके। समुदाय संस्करण (हमेशा के लिए मुफ़्त!) परिनियोजन और निगरानी प्रदान करता है।

अगले एपिसोड में, हम आपको कठपुतली का उपयोग करके MySQL लोड बैलेंसर परिनियोजन के बारे में बताने जा रहे हैं। बने रहें!