MySQL/MariaDB के लिए Azure डेटाबेस को ऑन-प्रेम सर्वर पर माइग्रेट करना

डेटाबेस माइग्रेशन बड़ी चुनौतियों का सामना कर सकता है जब आप विचार करते हैं कि कैसे शुरू करना है, कौन से टूल्स का उपयोग करना है, और सफलतापूर्वक पूर्ण डेटाबेस माइग्रेशन कैसे प्राप्त करना है। इससे पहले, हमने शीर्ष ओपन सोर्स को सूचीबद्ध किया है जिसका उपयोग आप MySQL या MariaDB के लिए माइग्रेशन पर कर सकते हैं। इस ब्लॉग में, हम आपको दिखाएंगे कि MySQL या MariaDB के लिए Microsoft Azure डेटाबेस से डेटा माइग्रेट कैसे करें।

Microsoft Azure अब दो अन्य क्लाउड टेक दिग्गजों:AWS और Google क्लाउड के खिलाफ एक प्रतियोगी के रूप में जाना जाता है। यह अपने Microsoft उत्पादों में विशेष रूप से उनके घरेलू MSSQL मालिकाना डेटाबेस में विशेषज्ञता रखता है। लेकिन इतना ही नहीं, सार्वजनिक रूप से पेश करने के लिए उनके पूरी तरह से प्रबंधित सेवा डेटाबेस में से एक के रूप में खुले स्रोत भी हैं। इसके समर्थित डेटाबेस में MySQL और MariaDB हैं।

MySQL/MariaDB के लिए Azure डेटाबेस से बाहर निकलना थकाऊ हो सकता है लेकिन यह इस बात पर निर्भर करता है कि आपने अपने वर्तमान क्लाउड प्रदाता के रूप में अपने Azure में किस प्रकार का आर्किटेक्चर और किस प्रकार का डेटासेट होस्ट किया है। सही उपकरणों के साथ, इसे प्राप्त किया जा सकता है और एक पूर्ण प्रवासन किया जा सकता है।

हम उन टूल पर ध्यान केंद्रित करेंगे जिनका उपयोग हम MySQL या MariaDB पर डेटा माइग्रेशन के लिए कर सकते हैं। इस ब्लॉग के लिए, मैं आवश्यक पैकेज स्थापित करने के लिए RHEL/CentOS का उपयोग कर रहा हूं। आइए देखें और इसे कैसे करें, इसके चरणों और प्रक्रियाओं को परिभाषित करें।

MySQL या MariaDB के लिए Azure डेटाबेस से माइग्रेट करना

Azure डेटाबेस से एक ऑन-प्रिमाइसेस सर्वर पर अपने डेटा को माइग्रेट करने का एक विशिष्ट तरीका एक तार्किक प्रतिलिपि का उपयोग करके बैकअप लेना है। यह बैकअप उपयोगिता समाधानों का उपयोग करके किया जा सकता है जो MySQL या MariaDB के लिए Azure डेटाबेस के साथ संचालित करने के लिए संगत हैं जो पूरी तरह से प्रबंधित सेवा है। पूरी तरह से प्रबंधित डेटाबेस सेवाएं SSH लॉगिन की पेशकश नहीं करती हैं, इसलिए बैकअप की भौतिक प्रतिलिपि एक विकल्प नहीं है।

इससे पहले कि आप Azure से अपने मौजूदा डेटाबेस को माइग्रेट या डंप कर सकें, आपको निम्नलिखित बातों पर ध्यान देना होगा।

डंप के लिए सामान्य उपयोग-मामले और ऑन-प्रिमाइसेस पुनर्स्थापित करें

सबसे आम उपयोग के मामले हैं:

लॉजिकल बैकअप (जैसे कि mysqldump, mysqlpump या mydumper/myloader) का उपयोग करना और रिस्टोर करना ही एकमात्र विकल्प है। MySQL या MariaDB के लिए Azure डेटाबेस भौतिक संग्रहण तक भौतिक पहुँच का समर्थन नहीं करता है क्योंकि यह पूरी तरह से प्रबंधित डेटाबेस सेवा है।
केवल InnoDB और मेमोरी स्टोरेज इंजन का समर्थन करता है। वैकल्पिक स्टोरेज इंजन से InnoDB में माइग्रेट करना। MySQL या MariaDB के लिए Azure डेटाबेस केवल InnoDB संग्रहण इंजन का समर्थन करता है, और इसलिए वैकल्पिक संग्रहण इंजन का समर्थन नहीं करता है। यदि आपकी तालिकाएँ अन्य संग्रहण इंजनों के साथ कॉन्फ़िगर की गई हैं, तो उन्हें MySQL के लिए Azure डेटाबेस में माइग्रेट करने से पहले InnoDB इंजन प्रारूप में परिवर्तित करें।
उदाहरण के लिए, यदि आपके पास MyISAM तालिकाओं का उपयोग करने वाला एक WordPress या WebApp है, तो पहले MySQL के लिए Azure डेटाबेस में पुनर्स्थापित करने से पहले उन तालिकाओं को InnoDB प्रारूप में माइग्रेट करके कनवर्ट करें। नई तालिका बनाते समय उपयोग किए गए इंजन को सेट करने के लिए ENGINE=InnoDB क्लॉज का उपयोग करें, फिर डेटा को पुनर्स्थापित करने से पहले संगत तालिका में स्थानांतरित करें।
यदि आपका स्रोत Azure डेटाबेस किसी विशिष्ट संस्करण पर है, तो आपका लक्ष्य ऑन-प्रिमाइसेस सर्वर भी स्रोत Azure डेटाबेस के समान संस्करण रहा है।

इसलिए इन सीमाओं के साथ, आप केवल यह उम्मीद करते हैं कि Azure से आपका डेटा InnoDB संग्रहण इंजन या मेमोरी होना चाहिए, यदि आपके डेटासेट में ऐसा है।

Azure डेटाबेस से तार्किक बैकअप लेने के लिए प्रदर्शन संबंधी विचार

Azure के साथ तार्किक बैकअप लेने का एकमात्र तरीका mysqldump या mysqlpump का उपयोग करना है। इन उपकरणों का उपयोग करते हुए डंप लेते समय प्रदर्शन को अनुकूलित करने के लिए, बड़े डेटाबेस को डंप करते समय इन बातों पर ध्यान दें:

डेटाबेस को डंप करते समय mysqldump में बहिष्कृत-ट्रिगर विकल्प का उपयोग करें। डेटा रिस्टोर के दौरान ट्रिगर कमांड फ़ायरिंग से बचने के लिए डंप फ़ाइलों से ट्रिगर्स को बाहर करें।
लेन-देन आइसोलेशन मोड को दोहराने योग्य पढ़ने के लिए सेट करने के लिए एकल-लेन-देन विकल्प का उपयोग करें और डेटा डंप करने से पहले सर्वर को एक स्टार्ट ट्रांज़ेक्शन SQL स्टेटमेंट भेजें। एक ही लेन-देन के भीतर कई तालिकाओं को डंप करने से पुनर्स्थापना के दौरान कुछ अतिरिक्त संग्रहण की खपत होती है। एकल-लेनदेन विकल्प और लॉक-टेबल विकल्प परस्पर अनन्य हैं क्योंकि LOCK TABLES किसी भी लंबित लेनदेन को निहित रूप से प्रतिबद्ध करने का कारण बनता है। बड़ी तालिकाओं को डंप करने के लिए, एकल-लेन-देन विकल्प को त्वरित विकल्प के साथ संयोजित करें।
विस्तारित-सम्मिलित बहु-पंक्ति सिंटैक्स का उपयोग करें जिसमें कई VALUE सूचियां शामिल हैं। यह एक छोटी डंप फ़ाइल में परिणत होता है और जब फ़ाइल को पुनः लोड किया जाता है तो सम्मिलन को गति देता है।
डेटाबेस को डंप करते समय mysqldump में क्रम-दर-प्राथमिक विकल्प का उपयोग करें, ताकि डेटा प्राथमिक कुंजी क्रम में स्क्रिप्ट किया जा सके।
डेटा डंप करते समय mysqldump में अक्षम-कुंजी विकल्प का उपयोग करें, लोड से पहले विदेशी कुंजी बाधाओं को अक्षम करने के लिए। विदेशी कुंजी चेक अक्षम करने से प्रदर्शन लाभ मिलता है। संदर्भात्मक अखंडता सुनिश्चित करने के लिए बाधाओं को सक्षम करें और लोड के बाद डेटा सत्यापित करें।
उपयुक्त होने पर विभाजित तालिकाओं का उपयोग करें।
डेटा को समानांतर में लोड करें। बहुत अधिक समानता से बचें जो आपको संसाधन सीमा तक पहुंचने का कारण बने, और Azure पोर्टल में उपलब्ध मीट्रिक का उपयोग करके संसाधनों की निगरानी करें।
डेटाबेस को डंप करते समय mysqlpump में defer-table-indexes विकल्प का उपयोग करें, ताकि तालिका का डेटा लोड होने के बाद अनुक्रमणिका निर्माण हो सके।
mysqlpump में स्किप-डिफाइनर विकल्प का उपयोग करके व्यू और स्टोर की गई प्रक्रियाओं के लिए क्रिएट स्टेटमेंट से डिफाइनर और SQL SECURITY क्लॉज को छोड़ दें। जब आप डंप फ़ाइल को पुनः लोड करते हैं, तो यह ऑब्जेक्ट बनाता है जो डिफ़ॉल्ट DEFINER और SQL सुरक्षा मानों का उपयोग करता है।
बैकअप फ़ाइलों को Azure ब्लॉब/स्टोर में कॉपी करें और वहां से रिस्टोर करें, जो पूरे इंटरनेट पर रिस्टोर करने की तुलना में बहुत तेज होना चाहिए।

असमर्थित

निम्नलिखित असमर्थित हैं:

DBA भूमिका:प्रतिबंधित। वैकल्पिक रूप से, आप व्यवस्थापक उपयोगकर्ता (नए सर्वर निर्माण के दौरान बनाए गए) का उपयोग कर सकते हैं, जिससे आप अधिकांश डीडीएल और डीएमएल स्टेटमेंट निष्पादित कर सकते हैं।
सुपर विशेषाधिकार:इसी तरह, सुपर विशेषाधिकार प्रतिबंधित है।
DEFINER:बनाने के लिए सुपर विशेषाधिकारों की आवश्यकता होती है और यह प्रतिबंधित है। यदि बैकअप का उपयोग करके डेटा आयात कर रहे हैं, तो मैन्युअल रूप से बनाएं या mysqldump निष्पादित करते समय --स्किप-डिफाइनर कमांड का उपयोग करके क्रिएट डेफिनर कमांड को हटा दें।
सिस्टम डेटाबेस:mysql सिस्टम डेटाबेस केवल पढ़ने के लिए है और विभिन्न PaS कार्यक्षमता का समर्थन करने के लिए उपयोग किया जाता है। आप mysql सिस्टम डेटाबेस में परिवर्तन नहीं कर सकते।
चुनें ... आउटफाइल में:सेवा में समर्थित नहीं है।

mysqldump का उपयोग करना

mysqldump का उपयोग करके अपने लक्षित डेटाबेस नोड में समय-समय पर स्थापित किया जाना चाहिए। इसे Azure डेटाबेस नोड की प्रतिकृति के रूप में तैयार किया जाना है ताकि बाद के सभी लेनदेन नोड में दोहराए जा सकें। ऐसा करने के लिए, नीचे दिए गए चरणों का पालन करें।

mysqldump स्थापित करें

रिपॉजिटरी तैयार करें।

# MySQL के लिए

$ yum install https://dev.mysql.com/get/mysql80-community-release-el7-3.noarch.rpm

# मारियाडीबी के लिए

$ curl -sS https://downloads.mariadb.com/MariaDB/mariadb_repo_setup | sudo bash

mysql-client पैकेज स्थापित करें

# MySQL के लिए

$ yum install -y mysql-community-client.x86_64

# मारियाडीबी के लिए

$ yum install -y MariaDB-client

एक डेटा डंप बनाएं mysqldump का उपयोग करके इसे लक्ष्य नोड के अंदर निष्पादित करके।

$ MYSQL_PWD=<YOUR_MYSQL_PASS> mysqldump -h<YOUR_AZURE_DB_HOSTNAME>  -u<YOUR_AZURE_USERNAME> --single-transaction --master-data=2 --extended-insert --order-by-primary --disable-keys --databases maximusdb db2 db3 > backups/dump.sql

लक्ष्य डेटाबेस नोड में MySQL/MariaDB सर्वर स्थापित करें

# MySQL के लिए

$  yum install mysql-community-server.x86_64 mysql-community-client mysql-community-common

# मारियाडीबी के लिए

$ yum install MariaDB-server.x86_64

MySQL/MariaDB सर्वर इंस्टेंस सेट करें (my.cnf, फ़ाइल अनुमतियां, निर्देशिका), और सर्वर प्रारंभ करें

# my.cnf सेट करना (ClusterControl द्वारा my.cnf परिनियोजन उपयोग का उपयोग करके)

[MYSQLD]

user=mysql

basedir=/usr/

datadir=/var/lib/mysql

socket=/var/lib/mysql/mysql.sock

pid_file=/var/lib/mysql/mysql.pid

port=3306

log_error=/var/log/mysql/mysqld.log

log_warnings=2

slow_query_log_file=/var/log/mysql/mysql-slow.log

long_query_time=2

slow_query_log=OFF

log_queries_not_using_indexes=OFF

innodb_buffer_pool_size=2G

innodb_flush_log_at_trx_commit=2

innodb_file_per_table=1

innodb_data_file_path=ibdata1:100M:autoextend

innodb_read_io_threads=4

innodb_write_io_threads=4

innodb_doublewrite=1

innodb_log_file_size=256M

innodb_log_buffer_size=32M

innodb_buffer_pool_instances=1

innodb_log_files_in_group=2

innodb_thread_concurrency=0

innodb_flush_method=O_DIRECT

innodb_rollback_on_timeout=ON

innodb_autoinc_lock_mode=2

innodb_stats_on_metadata=0

default_storage_engine=innodb

server_id=1126

binlog_format=ROW

log_bin=binlog

log_slave_updates=1

relay_log=relay-bin

expire_logs_days=7

read_only=OFF

report_host=192.168.10.226

key_buffer_size=24M

tmp_table_size=64M

max_heap_table_size=64M

max_allowed_packet=512M

skip_name_resolve=true

memlock=0

sysdate_is_now=1

max_connections=500

thread_cache_size=512

query_cache_type=0

query_cache_size=0

table_open_cache=1024

lower_case_table_names=0

performance_schema=OFF

performance-schema-max-mutex-classes=0

performance-schema-max-mutex-instances=0



[MYSQL]

socket=/var/lib/mysql/mysql.sock



[client]

socket=/var/lib/mysql/mysql.sock



[mysqldump]

socket=/var/lib/mysql/mysql.sock

max_allowed_packet=512M

## डेटा निर्देशिका को रीसेट करें और डेटाबेस सिस्टम फ़ाइलों को फिर से स्थापित करें

$ rm -rf /var/lib/mysql/*

## लॉग निर्देशिका बनाएं

$ mkdir /var/log/mysql

$ chown -R mysql.mysql /var/log/mysql

## MySQL के लिए

$ mysqld --initialize

## मारियाडीबी के लिए

$ mysql_install_db

MySQL/MariaDB सर्वर प्रारंभ करें

## MySQL के लिए

$ systemctl start mysqld

## मारियाडीबी के लिए

$ systemctl start mariadb

हमारे द्वारा Azure डेटाबेस से लिए गए डेटा डंप को समय-समय पर लक्ष्य डेटाबेस नोड में लोड करें

$ mysql --show-warnings < backups/dump.sql

अपने Azure डेटाबेस स्रोत नोड से प्रतिकृति उपयोगकर्ता बनाएं

CREATE USER 'repl_user'@'<your-target-node-ip>' IDENTIFIED BY 'repl_passw0rd';

GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO [email protected]'<your-target-node-ip>' IDENTIFIED BY 'repl_passw0rd';

सुनिश्चित करें कि आप अपने लक्षित नोड के आईपी पते को उस क्लाइंट के रूप में बदलते हैं जिससे आप जुड़ना चाहते हैं।

MySQL/MariaDB सर्वर को Azure डेटाबेस स्रोत नोड की प्रतिकृति/दास के रूप में सेट करें

## सबसे पहले, आइए चेंज मास्टर कमांड को खोजें या खोजें

$ grep -rn -E -i 'change master to master' backups/dump.sql |head -1

22:-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000006', MASTER_LOG_POS=2938610;

## CHANGE MASTER कथन चलाएँ लेकिन प्रतिकृति उपयोगकर्ता/पासवर्ड और होस्टनाम निम्नानुसार जोड़ें,

CHANGE MASTER TO MASTER_HOST='<YOUR_AZURE_DB_HOSTNAME>', MASTER_LOG_FILE='mysql-bin.000006', MASTER_LOG_POS=2938610, MASTER_USER='repl_user', MASTER_PASSWORD='repl_passw0rd';

## कुछ मामलों में, आपको mysql स्कीमा को अनदेखा करना पड़ सकता है। निम्नलिखित कथन चलाएँ:

SET GLOBAL replicate_wild_ignore_table='mysql.%';

## फिर स्लेव थ्रेड प्रारंभ करें

START SLAVE;

## गुलाम की स्थिति जांचें कि यह कैसे जाता है

SHOW SLAVE STATUS \G

अब जबकि हम अंततः Azure डेटाबेस से या तो MySQL/MariaDB के लिए समय-समय पर स्थित आपकी प्रतिकृति के स्रोत के रूप में दोहराने में सक्षम हो गए हैं।

माईडम्पर का उपयोग करना

MySQL या MariaDB के लिए Azure डेटाबेस वास्तव में सुझाव देता है कि विशेष रूप से 1TB जैसे बड़े बैकअप के लिए mydumper का उपयोग करना आपका वैकल्पिक विकल्प हो सकता है। स्रोत Azure डेटाबेस नोड से आपके डेटासेट की डंप या बैकअप कॉपी लेते समय यह समानता और गति प्रदान करता है।

mydumper को स्थापित करने से लेकर उसे अपने गंतव्य ऑन-प्रिमाइसेस सर्वर पर लोड करने के लिए नीचे दिए गए चरणों का पालन करें।

बाइनरी स्थापित करें। बायनेरिज़ यहां https://github.com/maxbube/mydumper/releases पर स्थित हो सकते हैं।

 $ yum install https://github.com/maxbube/mydumper/releases/download/v0.9.5/mydumper-0.9.5-2.el6.x86_64.rpm

Azure डेटाबेस स्रोत नोड से बैकअप लें। उदाहरण के लिए,

[[email protected] mydumper]# MYSQL_PWD=<YOUR_AZURE_DB_PASSWORD> /usr/bin/mydumper --outputdir=. --verbose=3 --host=<YOUR_AZURE_DB_HOSTNAME>  -u <YOUR_AZURE_USER>@<YOUR_AZURE_DB_HOSTNAME> --port=3306 --kill-long-queries --chunk-filesize=5120 --build-empty-files --events --routines --triggers --compress --less-locking --success-on-1146 --regex='(maximusdb\.|db1\.|db2\.)'

** Message: Connected to a MySQL server

** Message: Using Percona Backup Locks



** (mydumper:28829): CRITICAL **: Couldn't acquire LOCK BINLOG FOR BACKUP, snapshots will not be consistent: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'BINLOG FOR BACKUP' at line 1

** Message: Started dump at: 2020-10-26 01:34:05



** Message: Written master status

** Message: Multisource slave detected.

** Message: Thread 5 connected using MySQL connection ID 64315

** Message: Thread 6 connected using MySQL connection ID 64345

** Message: Thread 7 connected using MySQL connection ID 64275

** Message: Thread 8 connected using MySQL connection ID 64283

** Message: Thread 1 connected using MySQL connection ID 64253

** Message: Thread 2 connected using MySQL connection ID 64211

** Message: Thread 3 connected using MySQL connection ID 64200

** Message: Thread 4 connected using MySQL connection ID 64211



** (mydumper:28829): CRITICAL **: Error: DB: mysql - Could not execute query: Access denied for user 'mysqldbadmin'@'%' to database 'mysql'

** Message: Thread 5 shutting down

** Message: Thread 6 shutting down

** Message: Thread 7 shutting down

** Message: Thread 8 shutting down

** Message: Thread 1 dumping data for `db1`.`TB1`

** Message: Thread 2 dumping data for `db1`.`tb2

….

जैसा कि आप देख सकते हैं, Azure जैसे प्रबंधित डेटाबेस से बैकअप लेने की एक सीमा है। आप देख सकते हैं,

** (mydumper:28829): CRITICAL **: Couldn't acquire LOCK BINLOG FOR BACKUP, snapshots will not be consistent: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'BINLOG FOR BACKUP' at line 1

ऐसा इसलिए है, क्योंकि सुपर प्रिविलेज समर्थित या प्रतिबंधित नहीं है। आदर्श रूप से, ऐसा करने का सबसे अच्छा विकल्प है कि आप अपने Azure डेटाबेस की प्रतिकृति से बैकअप लें। हम इस बारे में बाद में बात करेंगे।

अब, इस बिंदु पर, mydumper *.gz फाइलों के रूप में एक बैकअप फाइल लेगा

इसे अपने गंतव्य ऑन-प्रिमाइसेस सर्वर पर लोड करें

$ myloader --host localhost --directory=$(pwd) --queries-per-transaction=10000 --threads=8 --compress-protocol --verbose=3

** Message: 8 threads created

** Message: Creating database `maximusdb`

** Message: Creating table `maximusdb`.`usertbl`

** Message: Creating table `maximusdb`.`familytbl`

** Message: Creating table `db2`.`t1`

** Message: Creating table `db3`.`test1`

…

….

गंतव्य नोड को दास/प्रतिकृति के रूप में सेट करें। MyDumper में मेटाडेटा नामक एक फ़ाइल शामिल होगी जिसमें बाइनरी लॉग निर्देशांक शामिल हैं, जिसमें GTID पदों सहित शामिल हैं, उदाहरण के लिए:

$ cat metadata

Started dump at: 2020-10-26 01:35:12

SHOW MASTER STATUS:

        Log: mysql-bin.000007

        Pos: 801

        GTID:0-3649485694-1705



Finished dump at: 2020-10-26 01:37:12

## फिर प्रतिकृति या अपने लक्ष्य गंतव्य MySQL/MariaDB डेटाबेस नोड से एक परिवर्तन मास्टर चलाएं

CHANGE MASTER TO MASTER_HOST='<YOUR_AZURE_DB_HOSTNAME>', MASTER_LOG_FILE='mysql-bin.000007', MASTER_LOG_POS=801, MASTER_USER='repl_user', MASTER_PASSWORD='repl_passw0rd';

## स्लेव प्रारंभ करें

START SLAVE;

इस बिंदु पर, आपने अब MySQL/MariaDB चलाने वाले Azure डेटाबेस इंस्टेंस से दोहराया है। एक बार जब आपका एप्लिकेशन आपके एज़्योर डेटाबेस इंस्टेंस से दूर जाने के लिए तैयार हो जाता है, तो अपने ऑन-प्रिमाइसेस सर्वर पर जाने वाले एंडपॉइंट को सेटअप करें और आपके एज़्योर इंस्टेंस से शेष सभी लेनदेन को आपके ऑन-प्रिमाइसेस में दोहराया जाएगा, जिससे कोई डेटा आपके ऑन- प्रेम सर्वर।

Azure में MySQL या MariaDB के लिए प्रबंधित डेटाबेस के साथ सीमाओं को संभालना

सीमाओं से निपटना विशेष रूप से जब आपके डेटासेट का बैकअप डंप लेते समय बैकअप डंप लेने के समय से 100% सटीक होना चाहिए। बेशक, यह आपके ऑन-प्रिमाइसेस के लिए एक आदर्श प्रवास है। इससे निपटने के लिए, आपके Azure डेटाबेस में एक प्रतिकृति टोपोलॉजी उपस्थिति होना सबसे अच्छा आर्किटेक्चर सेटअप है।

एक बार जब आप इसे प्राप्त कर लेते हैं और माइग्रेशन के लिए तैयार हो जाते हैं, तो mysqldump/mysqlpump या mydumper को इसके स्रोत के रूप में Azure डेटाबेस प्रतिकृति का उपयोग करना होगा। उस Azure डेटाबेस प्रतिकृति के भीतर, सुनिश्चित करें कि SQL_THREAD को रोक दिया गया है ताकि आप SHOW SLAVE STATUS के परिणाम से सही MASTER_LOG_FILE और EXEC_MASTER_LOG_POS को स्नैपशॉट या रिकॉर्ड कर सकें।

बेशक, एक बार बैकअप हो जाने के बाद, इसके प्रतिकृति थ्रेड को फिर से शुरू करने के लिए अपनी Azure डेटाबेस प्रतिकृति प्रारंभ करना न भूलें।

डेटा विसंगतियों की जांच करें

एक बार जब आप अपना डेटा लोड कर लेते हैं या अपने ऑन-प्रिमाइसेस सर्वर पर डंप कर देते हैं जो Azure डेटाबेस इंस्टेंस से प्रतिकृति के रूप में कार्य करता है, तो आपको यह निर्धारित करने के लिए चेकसम गणना चलाकर इसे दोबारा जांचना चाहिए कि आपका डेटा कितनी दूर है स्रोत Azure डेटाबेस। हमारा सुझाव है कि आप Percona टूलकिट से pt-table-checksum टूल का उपयोग करें, लेकिन आप md5 या sha256 जैसे चेकसमिंग टूल का उपयोग करके अपना स्वयं का बना सकते हैं, लेकिन ऐसा करने में समय लगता है। इसके अतिरिक्त, पेरकोना टूलकिट से पीटी-अपग्रेड का उपयोग करने से इस प्रतिकृति दृष्टिकोण का उपयोग करके आपके डेटा माइग्रेशन के बाद भी मदद मिल सकती है।

निष्कर्ष

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