பல தசாப்தங்களாக, mysqldump என்பது MySQL தரவுத்தள காப்புப்பிரதிகளுக்கான (backups) ஈடு இணையற்ற கருவியாக இருந்து வருகிறது. இது எங்கும் நிறைந்திருக்கும், எளிமையானது மற்றும் ஒவ்வொரு MySQL மற்றும் MariaDB விநியோகத்திலும் முன்பே நிறுவப்பட்டிருக்கும். சிறிய மற்றும் நடுத்தர அளவிலான தரவுத்தளங்களுக்கு, இது சிறப்பாகச் செயல்படுகிறது.
இருப்பினும், நிறுவனங்கள் வளரும்போதும், தரவுத்தொகுப்புகள் 100GB, 500GB அல்லது பல டெராபைட் அளவைத் தாண்டும்போதும், mysqldump-ஐ நம்பியிருப்பது சிறந்த நடைமுறையிலிருந்து ஒரு முக்கியமான கட்டமைப்பு பாதிப்பாக (architectural vulnerability) மாறுகிறது. நீங்கள் பெரிய அளவிலான உற்பத்தி தரவுத்தளங்களை நிர்வகிக்கும் DBA அல்லது DevOps பொறியாளராக இருந்தால், லாஜிக்கல் டம்ப்களுடன் (logical dumps) தொடர்புடைய அமைதியான தோல்விகள், உற்பத்தித் திறன் குறைதல் மற்றும் ஏற்றுக்கொள்ள முடியாத மீட்பு நேர இலக்குகள் (RTO) ஆகியவற்றை நீங்கள் அனுபவித்திருக்க வாய்ப்புள்ளது.
இந்தக் கட்டுரையில், mysqldump-ன் கட்டமைப்பு வரம்புகளைப் பிரித்தாய்வோம், அது ஏன் பெரிய அளவில் தோல்வியடைகிறது என்பதை ஆராய்வோம், மேலும் உங்கள் முக்கியமான தரவைப் பாதுகாக்க நிறுவன அளவிலான பிசிக்கல் பேக்கப் (physical backup) உத்திகளை எவ்வாறு செயல்படுத்துவது என்பதை விரிவாகப் பார்ப்போம்.
mysqldump-ன் கட்டமைப்பு வரம்புகள்
mysqldump ஏன் பெரிய அளவில் தோல்வியடைகிறது என்பதைப் புரிந்துகொள்ள, அது எவ்வாறு செயல்படுகிறது என்பதை நாம் ஆராய வேண்டும். mysqldump என்பது லாஜிக்கல் பேக்கப்களை செய்கிறது. இது தரவுத்தள இயந்திரத்தை வினவி (query), தரவைப் படித்து, அதை SQL அறிக்கைகளாக (முதன்மையாக CREATE TABLE மற்றும் INSERT INTO) மாற்றுகிறது.
இது மிகவும் எளிதாகக் கையாளக்கூடிய, மனிதர்கள் படிக்கக்கூடிய கோப்பை உருவாக்கினாலும், அதிக செயல்திறன் கொண்ட சூழல்களில் இது கடுமையான தடைகளை ஏற்படுத்துகிறது.
1. ஒற்றை-இழை (Single-Threaded) தடை
வடிவமைப்பின்படி, mysqldump ஒரு ஒற்றை-இழை செயல்பாடாகும். இது ஒரு நேரத்தில் ஒரு அட்டவணையை, வரி வரியாகச் செயலாக்குகிறது. நவீன வன்பொருள்கள் டஜன் கணக்கான CPU கோர்கள் மற்றும் வினாடிக்கு ஜிகாபைட் செயல்திறன் கொண்ட NVMe சேமிப்பகத்தைக் கொண்டிருந்தாலும், mysqldump இந்த வளங்களில் ஒரு சிறிய பகுதியை மட்டுமே பயன்படுத்துகிறது.
InnoDB அட்டவணைகளுக்கான நிலையான கொடிகளைப் பயன்படுத்தும்போதும் கூட:
mysqldump -u root -p --single-transaction --routines --triggers --events --quick production_db > backup.sql
--quick கொடியானது, முழு அட்டவணையையும் நினைவகத்தில் சேமிப்பதற்குப் பதிலாக, வரி வரியாகப் பெற mysqldump-ஐ கட்டாயப்படுத்துகிறது, இது கிளையண்ட் பக்கத்தில் நினைவகப் பற்றாக்குறை (OOM) பிழைகளைத் தடுக்கிறது. இருப்பினும், ஒற்றை-இழை தன்மையின் காரணமாக, 500GB தரவுத்தளத்தை டம்பிங் செய்ய 10 முதல் 15 மணிநேரம் ஆகலாம், இது உங்கள் மீட்பு புள்ளி இலக்கை (RPO) கடுமையாகப் பாதிக்கிறது.
2. InnoDB பஃபர் பூல் மாசுபடுதல்
mysqldump ஒவ்வொரு அட்டவணையின் ஒவ்வொரு வரியையும் படிக்கும்போது, அது தரவை வட்டில் இருந்து InnoDB பஃபர் பூலுக்கு ஏற்ற MySQL இயந்திரத்தை கட்டாயப்படுத்துகிறது. ஒரு உற்பத்தி சூழலில், உங்கள் பஃபர் பூல் உங்கள் “ஹாட்” (hot) தரவுத்தொகுப்பால் கவனமாக நிரப்பப்பட்டிருக்கும்.
ஒரு பெரிய லாஜிக்கல் டம்ப் பஃபர் பூலை ஸ்கேன் செய்து, அடிக்கடி அணுகப்படும் குறியீடுகள் மற்றும் தரவுப் பக்கங்களை வெளியேற்றி, காப்புப்பிரதி எடுக்கப்படும் பழைய தரவுகளுக்கு இடமளிக்கும். இது வட்டு I/O-வில் திடீர் மற்றும் மிகப்பெரிய அதிகரிப்பை ஏற்படுத்துகிறது, ஏனெனில் உற்பத்தி வினவல்கள் வட்டில் இருந்து படிக்க வேண்டிய கட்டாயத்திற்கு உள்ளாகின்றன, இது கடுமையான பயன்பாட்டு தாமதத்திற்கு (latency) வழிவகுக்கிறது.
3. மெட்டாடேட்டா பூட்டுகள் மற்றும் DDL மோதல்கள்
நிலைத்தன்மையை பராமரிக்க, DBA-க்கள் --single-transaction கொடியை நம்பியிருக்கிறார்கள், இது பரிவர்த்தனை தனிமைப்படுத்தல் நிலையை REPEATABLE READ என அமைத்து, தரவை டம்பிங் செய்வதற்கு முன் ஒரு பரிவர்த்தனையைத் தொடங்குகிறது.
இது அட்டவணை-நிலை வாசிப்பு பூட்டுகளை (FLUSH TABLES WITH READ LOCK) தவிர்த்தாலும், தரவு வரையறை மொழி (DDL) மாற்றங்களுக்கு எதிராக இது பாதுகாப்பு அளிக்காது. mysqldump இயங்கும்போது ஒரு அட்டவணையில் ALTER TABLE, DROP TABLE அல்லது TRUNCATE TABLE கட்டளை செயல்படுத்தப்பட்டால், table definition has changed, please retry transaction என்ற பிழையுடன் காப்புப்பிரதி செயலிழக்கும். அடிக்கடி ஸ்கீமா மாற்றங்கள் நடக்கும் CI/CD சூழல்களில், இது தொடர்ச்சியான காப்புப்பிரதி தோல்விகளை ஏற்படுத்துகிறது.
4. RTO கனவு: மீட்பு நேரங்கள்
mysqldump-ன் மிக மோசமான தோல்வி காப்புப்பிரதியின் போது அல்ல, மீட்டெடுக்கும் போதுதான் உணரப்படுகிறது.
ஒரு லாஜிக்கல் டம்பை மீட்டெடுக்க, MySQL இயந்திரம் மில்லியன் கணக்கான INSERT அறிக்கைகளை பாகுபடுத்தி செயல்படுத்த வேண்டும். செருகப்படும் ஒவ்வொரு வரிக்கும், MySQL பின்வருவனவற்றைச் செய்ய வேண்டும்:
* கட்டுப்பாடுகளைச் சரிபார்க்கவும் (Foreign Keys, Unique Keys).
* இரண்டாம் நிலை குறியீடுகளை (secondary indexes) உடனுக்குடன் மீண்டும் உருவாக்கவும்.
* InnoDB redo log-ல் எழுதவும்.
* binlog-ல் ஃப்ளஷ் செய்யவும் (இயக்கப்பட்டிருந்தால்).
ஒரு 1TB தரவுத்தளத்தை லாஜிக்கல் டம்பிலிருந்து மீட்டெடுக்க பல நாட்கள் ஆகலாம். உங்கள் வணிகத்திற்கு 4 மணிநேர RTO இருந்தால், mysqldump உங்கள் சேவை நிலை ஒப்பந்தத்தை (SLA) நீங்கள் மீறுவதை உறுதி செய்கிறது.
நிறுவன அளவிலான மாற்றுகள்: பிசிக்கல் பேக்கப்களுக்கு மாறுதல்
பெரிய தரவுத்தொகுப்புகளுக்கு விரைவான காப்புப்பிரதிகள் மற்றும் மீட்டெடுப்புகளை அடைய, நீங்கள் லாஜிக்கல் பேக்கப்களைக் கைவிட்டு பிசிக்கல் பேக்கப்களை தேர்ந்தெடுக்க வேண்டும்.
பிசிக்கல் பேக்கப்கள் MySQL SQL செயல்பாட்டு இயந்திரத்தை முழுமையாகத் தவிர்க்கின்றன. அதற்குப் பதிலாக, அவை அடிப்படை பைனரி தரவுக் கோப்புகளை (.ibd கோப்புகள், redo logs மற்றும் undo logs) நேரடியாக கோப்பு முறைமையிலிருந்து நகலெடுக்கின்றன. அவை கோப்புகளை மட்டுமே நகலெடுப்பதால், அவை உங்கள் சேமிப்பக வன்பொருளின் அதிகபட்ச தொடர்ச்சியான வாசிப்பு/எழுதுதல் வேகத்தில் செயல்பட முடியும் மற்றும் அதிக அளவில் இணையாக (parallelized) செய்யப்பட முடியும்.
Percona XtraBackup: தொழில் தரநிலை
InnoDB மற்றும் XtraDB இயந்திரங்களுக்கு, Percona XtraBackup முதன்மையான திறந்த மூல பிசிக்கல் பேக்கப் கருவியாகும். இது MySQL தரவுத்தளங்களின் ஹாட், பிளாக் செய்யாத காப்புப்பிரதிகளைச் செய்கிறது.
XtraBackup எவ்வாறு செயல்படுகிறது
- தரவை நகலெடுத்தல்: XtraBackup InnoDB தரவுக் கோப்புகளை (
.ibd) நகலெடுக்கத் தொடங்குகிறது. - பதிவு கண்காணிப்பு: தரவுத்தளம் நேரலையில் இருப்பதால், கோப்புகள் நகலெடுக்கப்படும்போது தரவு மாறும். XtraBackup ஒரு பின்னணி இழையை (thread) உருவாக்குகிறது, இது காப்புப்பிரதி காலத்தின் போது ஏற்படும் எந்தவொரு பரிவர்த்தனைக்கும் InnoDB redo log-ஐ (
ib_logfile0, போன்றவை) கண்காணித்து நகலெடுக்கிறது. - தயாரிப்பு (Crash Recovery): காப்புப்பிரதிக்குப் பிறகு, நகலெடுக்கப்பட்ட தரவுக் கோப்புகள் சீரற்ற நிலையில் இருக்கும். XtraBackup நகலெடுக்கப்பட்ட redo log-களை தரவுக் கோப்புகளில் பயன்படுத்துகிறது (MySQL தொடக்கத்தில் கிராஷ் ரிகவரி செய்வது போல), இது காப்புப்பிரதி முடிந்த அதே தருணத்தில் தரவுத்தளத்தின் முழுமையான சீரான ஸ்னாப்ஷாட்டை உருவாக்குகிறது.
பிசிக்கல் பேக்கப் உத்தியைச் செயல்படுத்துதல்
Percona XtraBackup-ஐப் பயன்படுத்தி பிசிக்கல் பேக்கப் உத்தியைச் செயல்படுத்துவதற்கான தொழில்நுட்ப வழிமுறை இதோ.
படி 1: காப்புப்பிரதியை ஸ்ட்ரீமிங் செய்தல்
ஒரு பெரிய காப்புப்பிரதியை உள்ளூர் வட்டில் எழுதுவது பெரும்பாலும் கொள்ளளவு சிக்கல்களை ஏற்படுத்துகிறது. காப்புப்பிரதியை நேரடியாக ஒரு காப்பக வடிவத்திற்கு ஸ்ட்ரீமிங் செய்வது, அதை சுருக்குவது மற்றும் அதை ஒரு ஸ்டேஜிங் பகுதிக்கு அல்லது நேரடியாக ஒரு காப்புப்பிரதி தளத்திற்கு அனுப்புவது சிறந்த நடைமுறையாகும்.
xbstream-ஐப் பயன்படுத்தி, நாம் காப்புப்பிரதியை இணையாகச் செய்து, அதை உடனுக்குடன் சுருக்கலாம்:
xtrabackup --backup
--user=backup_user
--password=SecurePassword!
--parallel=4
--stream=xbstream | lz4 > /mnt/backups/mysql_prod_backup.xbstream.lz4
--parallel=4: தரவுக் கோப்புகளை ஒரே நேரத்தில் படிக்க 4 இழைகளைப் பயன்படுத்துகிறது.--stream=xbstream: Percona-வின் தனிப்பயன் ஸ்ட்ரீமிங் வடிவத்தில் காப்புப்பிரதியை வெளியிடுகிறது.lz4: மிக வேகமான, குறைந்த CPU சுருக்கத்தை வழங்குகிறது.
படி 2: மீட்டெடுப்பிற்காக காப்புப்பிரதியைத் தயார் செய்தல்
ஒரு பிசிக்கல் பேக்கப்பை மீட்டெடுப்பதற்கு முன், அது “தயார்” செய்யப்பட வேண்டும் (redo log-களைப் பயன்படுத்துதல்). முதலில், ஸ்ட்ரீமை பிரித்தெடுத்து சுருக்கத்தை நீக்கவும்:
mkdir -p /data/restore
lz4 -d /mnt/backups/mysql_prod_backup.xbstream.lz4 | xbstream -x -C /data/restore
அடுத்து, தயாரிப்பு கட்டத்தை இயக்கவும். இந்த படிக்கு நினைவகம் தேவை, எனவே சேவையகத்தில் போதுமான RAM ஒதுக்கப்பட்டுள்ளதா என்பதை உறுதிப்படுத்தவும்:
xtrabackup --prepare --use-memory=4G --target-dir=/data/restore
படி 3: தரவுத்தளத்தை மீட்டெடுத்தல்
மீட்டெடுக்க, இலக்கு MySQL தரவு அடைவு முற்றிலும் காலியாக இருக்க வேண்டும். MySQL சேவையை நிறுத்தி, அடைவைச் சுத்தம் செய்து, கோப்புகளை மீண்டும் நகலெடுக்கவும்:
systemctl stop mysql
rm -rf /var/lib/mysql/*
xtrabackup --copy-back --target-dir=/data/restore
இறுதியாக, சேவையைத் தொடங்குவதற்கு முன் கோப்பு முறைமை அனுமதிகளைச் சரிசெய்யவும்:
chown -R mysql:mysql /var/lib/mysql
systemctl start mysql
தரவுக் கோப்புகள் ஏற்கனவே கட்டமைக்கப்பட்டு, குறியீடுகள் ஏற்கனவே தொகுக்கப்பட்டுள்ளதால், தரவுத்தளம் உடனடியாகத் தொடங்குகிறது. mysqldump மூலம் 48 மணிநேரம் எடுத்த மீட்டெடுப்பு, இப்போது உங்கள் நெட்வொர்க் அல்லது வட்டு வழியாக கோப்புகளை நகலெடுக்க எடுக்கும் நேரத்தை மட்டுமே எடுக்கும்—இது பெரும்பாலும் RTO-வை நிமிடங்களாகக் குறைக்கிறது.
லாஜிக்கல் மீட்டெடுப்புகளை மேம்படுத்துதல் (நீங்கள் அவற்றைப் பயன்படுத்த வேண்டியிருக்கும் போது)
நீங்கள் ஒரு பெரிய லாஜிக்கல் டம்பை மீட்டெடுக்க வேண்டிய கட்டாயத்தில் இருந்தால் (எ.கா., வெவ்வேறு முக்கிய MySQL பதிப்புகளுக்கு இடையே அல்லது பிசிக்கல் கோப்புகள் பொருந்தாத வெவ்வேறு CPU கட்டமைப்புகளுக்கு இடையே இடம்பெயரும்போது), மிகப்பெரிய எழுதும் செயல்திறனுக்காக உங்கள் MySQL கட்டமைப்பை தற்காலிகமாக மாற்றியமைக்க வேண்டும்.
லாஜிக்கல் மீட்டெடுப்பைத் தொடங்குவதற்கு முன் இந்த அமைப்புகளை உங்கள் my.cnf-ல் பயன்படுத்தவும்:
[mysqld]
# இது ஒரு தனிப்பட்ட மீட்டெடுப்பு என்றால் binlogging-ஐ தற்காலிகமாக முடக்கவும்
disable_log_bin
# எழுதும் வேகத்தை அதிகரிக்க வட்டில் ஃப்ளஷ் செய்வதைத் தாமதப்படுத்தவும்
innodb_flush_log_at_trx_commit = 2
# வேலை செய்யும் தொகுப்பில் முடிந்தவரை அதிகப்படியானவற்றை பொருத்த பஃபர் பூலை அதிகரிக்கவும்
innodb_buffer_pool_size = <மொத்த RAM-ல் 70% என அமைக்கவும்>
# ஆக்ரோஷமான செக்பாயிண்டிங்கைத் தடுக்க லாக் கோப்பு அளவை அதிகரிக்கவும்
innodb_log_file_size = 2G
# டபுள்ரைட் பஃபரை முடக்கவும் (உற்பத்திக்கு ஆபத்தானது, ஆரம்ப சுமைக்கு பாதுகாப்பானது)
innodb_doublewrite = 0
குறிப்பு: இந்த அமைப்புகளை எப்போதும் அவற்றின் ACID-இணக்கமான இயல்புநிலைகளுக்கு (innodb_flush_log_at_trx_commit = 1, innodb_doublewrite = 1) மாற்றவும் மற்றும் உற்பத்தி போக்குவரத்தை அனுமதிக்கும் முன் MySQL சேவையை மறுதொடக்கம் செய்யவும்.
CloudSave மூலம் காப்புப்பிரதிகளை தானியக்கமாக்குதல் மற்றும் பாதுகாத்தல்
Percona XtraBackup போன்ற கருவிகள் தரவை திறமையாக பிரித்தெடுக்கும் இயக்கவியலைத் தீர்த்தாலும், உண்மையான நிறுவன பேரிடர் மீட்பு உத்திக்கு ஆர்கெஸ்ட்ரேஷன், பாதுகாப்பான ஆஃப்சைட் சேமிப்பு மற்றும் வாழ்க்கைச் சுழற்சி மேலாண்மை தேவைப்படுகிறது. பிசிக்கல் பேக்கப்களை நிர்வகிக்க தனிப்பயன் பாஷ் ஸ்கிரிப்ட்கள் மற்றும் கிரான் ஜாப்களை நம்பியிருப்பது அமைதியான தோல்விகள் மற்றும் இணக்க மீறல்களின் அதிக ஆபத்தை ஏற்படுத்துகிறது.
இங்குதான் உங்கள் தரவுத்தள அடுக்கை CloudSave போன்ற ஒரு நிறுவன தளத்துடன் ஒருங்கிணைப்பது முக்கியமானதாகிறது.
CloudSave மூல தரவுத்தள பயன்பாடுகளுக்கும் நிறுவன இணக்கத்திற்கும் இடையிலான இடைவெளியைக் குறைக்கிறது. CloudSave-ன் முன் மற்றும் பின் ஸ்கிரிப்டிங் திறன்களைப் பயன்படுத்துவதன் மூலம், DevOps குழுக்கள் ஒரு சீரான பிசிக்கல் ஸ்னாப்ஷாட்டை உருவாக்க XtraBackup-ஐத் தூண்டலாம். CloudSave பின்னர் காப்புப்பிரதி ஸ்ட்ரீமை தடையின்றி உள்வாங்கி, AES-256 குறியாக்கத்தைப் பயன்படுத்துகிறது மற்றும் தரவை மாற்ற முடியாத கிளவுட் சேமிப்பகத்திற்கு நகலெடுப்பதற்கு முன் அதை நீக்குகிறது (deduplicates).
இந்த கட்டமைப்பு பின்வருவனவற்றை உறுதி செய்கிறது:
1. உற்பத்தி செயல்திறன் பராமரிக்கப்படுகிறது: InnoDB பஃபர் பூலை மாசுபடுத்தாமல் சேமிப்பக வேகத்தில் காப்புப்பிரதிகள் இயங்குகின்றன.
2. ரான்சம்வேர் பாதுகாப்பு: CloudSave-க்குள் உள்ள மாற்ற முடியாத சேமிப்பகக் கொள்கைகள், தீங்கிழைக்கும் நபர்கள் உங்கள் தரவுத்தள காப்பகங்களை நீக்குவதையோ அல்லது குறியாக்கம் செய்வதையோ தடுக்கின்றன.
3. தானியங்கி தக்கவைப்பு: கிராண்ட்பாதர்-ஃபாதர்-சன் (GFS) தக்கவைப்புக் கொள்கைகள் தானாகவே கையாளப்படுகின்றன, இது தரவு இறையாண்மை மற்றும் தணிக்கை தேவைகளுக்கு இணங்குவதை உறுதி செய்கிறது.
4. கணிக்கக்கூடிய RTO: CloudSave பிசிக்கல் கோப்பு காப்பகங்களை நிர்வகிப்பதால், பல டெராபைட் தரவுத்தளத்தை ஒரு புதிய நிகழ்விற்கு மீட்டெடுப்பதை விரைவாக ஆர்கெஸ்ட்ரேட் செய்ய முடியும், இது கடுமையான RTO இலக்குகளை அடைகிறது.
முடிவு
பெரிய அளவிலான தரவுத்தளங்களுக்கு mysqldump-ஐத் தொடர்ந்து பயன்படுத்துவது உங்கள் நிறுவனத்தின் இயக்க நேரம் மற்றும் தரவு ஒருமைப்பாட்டுடன் விளையாடும் ஒரு சூதாட்டமாகும். ஒற்றை-இழை தன்மை, பஃபர் பூல் மாசுபடுதல் மற்றும் பேரழிவு தரும் மீட்டெடுப்பு நேரங்கள் ஆகியவை நவீன, அதிக செயல்திறன் கொண்ட சூழல்களுக்கு இது அடிப்படையில் பொருத்தமற்றதாக ஆக்குகின்றன.
Percona XtraBackup போன்ற கருவிகளைப் பயன்படுத்தி பிசிக்கல் பேக்கப்களுக்கு மாறுவதன் மூலமும், CloudSave போன்ற வலுவான தளம் மூலம் வாழ்க்கைச் சுழற்சி, குறியாக்கம் மற்றும் ஆஃப்சைட் நகலெடுப்பை ஆர்கெஸ்ட்ரேட் செய்வதன் மூலமும், உங்கள் தரவுத்தள காப்புப்பிரதி உத்தியை ஒரு பலவீனமான பொறுப்பிலிருந்து மீளக்கூடிய, நிறுவன அளவிலான சொத்தாக மாற்றுகிறீர்கள். உங்கள் தற்போதைய RTO மற்றும் RPO அளவீடுகளை இன்றே மதிப்பீடு செய்யுங்கள்—ஒரு மீட்டெடுப்பு உங்கள் வணிகம் ஆஃப்லைனில் இருக்கக்கூடிய நேரத்தை விட அதிக நேரம் எடுத்தால், mysqldump-ஐ விட்டுவிட வேண்டிய நேரம் இது.
