ਦਹਾਕਿਆਂ ਤੋਂ, mysqldump MySQL ਡੇਟਾਬੇਸ ਬੈਕਅੱਪ ਲਈ ਬਿਨਾਂ ਕਿਸੇ ਸ਼ੱਕ ਦੇ ਸਵਿਸ ਆਰਮੀ ਚਾਕੂ ਵਾਂਗ ਕੰਮ ਕਰਦਾ ਆਇਆ ਹੈ। ਇਹ ਹਰ ਜਗ੍ਹਾ ਮੌਜੂਦ ਹੈ, ਸਿੱਧਾ ਹੈ, ਅਤੇ ਹਰ MySQL ਅਤੇ MariaDB ਡਿਸਟ੍ਰੀਬਿਊਸ਼ਨ ਦੇ ਨਾਲ ਪਹਿਲਾਂ ਤੋਂ ਸਥਾਪਿਤ ਆਉਂਦਾ ਹੈ। ਛੋਟੇ ਤੋਂ ਦਰਮਿਆਨੇ ਆਕਾਰ ਦੇ ਡੇਟਾਬੇਸ ਲਈ, ਇਹ ਬਹੁਤ ਵਧੀਆ ਪ੍ਰਦਰਸ਼ਨ ਕਰਦਾ ਹੈ।
ਹਾਲਾਂਕਿ, ਜਿਵੇਂ-ਜਿਵੇਂ ਸੰਸਥਾਵਾਂ ਦਾ ਵਿਸਤਾਰ ਹੁੰਦਾ ਹੈ ਅਤੇ ਡੇਟਾਸੈਟ 100GB, 500GB, ਜਾਂ ਮਲਟੀ-ਟੈਰਾਬਾਈਟ ਦੀਆਂ ਸੀਮਾਵਾਂ ਨੂੰ ਪਾਰ ਕਰਦੇ ਹਨ, mysqldump ‘ਤੇ ਨਿਰਭਰ ਰਹਿਣਾ ਇੱਕ ਵਧੀਆ ਅਭਿਆਸ ਤੋਂ ਬਦਲ ਕੇ ਇੱਕ ਗੰਭੀਰ ਆਰਕੀਟੈਕਚਰਲ ਕਮਜ਼ੋਰੀ ਬਣ ਜਾਂਦਾ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ ਇੱਕ DBA ਜਾਂ DevOps ਇੰਜੀਨੀਅਰ ਹੋ ਜੋ ਵੱਡੇ ਪੱਧਰ ਦੇ ਪ੍ਰੋਡਕਸ਼ਨ ਡੇਟਾਬੇਸ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਸ਼ਾਇਦ ਲਾਜ਼ੀਕਲ ਡੰਪ ਨਾਲ ਜੁੜੀਆਂ ਚੁੱਪ-ਚਾਪ ਅਸਫਲਤਾਵਾਂ, ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਗਿਰਾਵਟ, ਅਤੇ ਅਸਵੀਕਾਰਨਯੋਗ ਰਿਕਵਰੀ ਟਾਈਮ ਓਬਜੈਕਟਿਵਜ਼ (RTO) ਦਾ ਅਨੁਭਵ ਕੀਤਾ ਹੋਵੇਗਾ।
ਇਸ ਲੇਖ ਵਿੱਚ, ਅਸੀਂ mysqldump ਦੀਆਂ ਆਰਕੀਟੈਕਚਰਲ ਸੀਮਾਵਾਂ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਾਂਗੇ, ਇਹ ਪਤਾ ਲਗਾਵਾਂਗੇ ਕਿ ਇਹ ਵੱਡੇ ਪੱਧਰ ‘ਤੇ ਕਿਉਂ ਅਸਫਲ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਤੁਹਾਡੇ ਮਿਸ਼ਨ-ਕ੍ਰਿਟੀਕਲ ਡੇਟਾ ਦੀ ਸੁਰੱਖਿਆ ਲਈ ਐਂਟਰਪ੍ਰਾਈਜ਼-ਗ੍ਰੇਡ ਫਿਜ਼ੀਕਲ ਬੈਕਅੱਪ ਰਣਨੀਤੀਆਂ ਨੂੰ ਕਿਵੇਂ ਲਾਗੂ ਕਰਨਾ ਹੈ, ਇਸ ਬਾਰੇ ਵਿਸਥਾਰ ਨਾਲ ਦੱਸਾਂਗੇ।
mysqldump ਦੀਆਂ ਆਰਕੀਟੈਕਚਰਲ ਸੀਮਾਵਾਂ
ਇਹ ਸਮਝਣ ਲਈ ਕਿ mysqldump ਵੱਡੇ ਪੱਧਰ ‘ਤੇ ਕਿਉਂ ਅਸਫਲ ਹੁੰਦਾ ਹੈ, ਸਾਨੂੰ ਇਹ ਦੇਖਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਇਹ ਅੰਦਰੂਨੀ ਤੌਰ ‘ਤੇ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ। mysqldump ਲਾਜ਼ੀਕਲ ਬੈਕਅੱਪ ਕਰਦਾ ਹੈ। ਇਹ ਡੇਟਾਬੇਸ ਇੰਜਣ ਨੂੰ ਪੁੱਛਗਿੱਛ ਕਰਦਾ ਹੈ, ਡੇਟਾ ਨੂੰ ਪੜ੍ਹਦਾ ਹੈ, ਅਤੇ ਇਸਨੂੰ SQL ਸਟੇਟਮੈਂਟਾਂ (ਮੁੱਖ ਤੌਰ ‘ਤੇ CREATE TABLE ਅਤੇ INSERT INTO) ਦੀ ਇੱਕ ਲੜੀ ਵਿੱਚ ਅਨੁਵਾਦ ਕਰਦਾ ਹੈ।
ਹਾਲਾਂਕਿ ਇਹ ਇੱਕ ਬਹੁਤ ਹੀ ਪੋਰਟੇਬਲ, ਪੜ੍ਹਨਯੋਗ ਫਾਈਲ ਬਣਾਉਂਦਾ ਹੈ, ਪਰ ਇਹ ਉੱਚ-ਥ੍ਰੂਪੁੱਟ ਵਾਤਾਵਰਣ ਵਿੱਚ ਗੰਭੀਰ ਰੁਕਾਵਟਾਂ ਪੈਦਾ ਕਰਦਾ ਹੈ।
1. ਸਿੰਗਲ-ਥ੍ਰੈਡਡ ਰੁਕਾਵਟ
ਡਿਜ਼ਾਈਨ ਦੁਆਰਾ, 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 ਹਰ ਟੇਬਲ ਦੀ ਹਰ ਕਤਾਰ ਨੂੰ ਪੜ੍ਹਦਾ ਹੈ, ਤਾਂ ਇਹ MySQL ਇੰਜਣ ਨੂੰ ਉਸ ਡੇਟਾ ਨੂੰ ਡਿਸਕ ਤੋਂ InnoDB ਬਫਰ ਪੂਲ ਵਿੱਚ ਲੋਡ ਕਰਨ ਲਈ ਮਜਬੂਰ ਕਰਦਾ ਹੈ। ਇੱਕ ਪ੍ਰੋਡਕਸ਼ਨ ਵਾਤਾਵਰਣ ਵਿੱਚ, ਤੁਹਾਡਾ ਬਫਰ ਪੂਲ ਤੁਹਾਡੇ “ਹੌਟ” ਵਰਕਿੰਗ ਡੇਟਾਸੈਟ ਨਾਲ ਸਾਵਧਾਨੀ ਨਾਲ ਭਰਿਆ ਹੁੰਦਾ ਹੈ।
ਇੱਕ ਵਿਸ਼ਾਲ ਲਾਜ਼ੀਕਲ ਡੰਪ ਬਫਰ ਪੂਲ ਨੂੰ ਸਾਫ਼ ਕਰ ਦੇਵੇਗਾ, ਜਿਸ ਨਾਲ ਅਕਸਰ ਐਕਸੈਸ ਕੀਤੇ ਜਾਣ ਵਾਲੇ ਇੰਡੈਕਸ ਅਤੇ ਡੇਟਾ ਪੰਨਿਆਂ ਨੂੰ ਹਟਾ ਦਿੱਤਾ ਜਾਵੇਗਾ ਤਾਂ ਜੋ ਬੈਕਅੱਪ ਕੀਤੇ ਜਾ ਰਹੇ ਕੋਲਡ ਡੇਟਾ ਲਈ ਜਗ੍ਹਾ ਬਣਾਈ ਜਾ ਸਕੇ। ਇਸ ਦੇ ਨਤੀਜੇ ਵਜੋਂ ਡਿਸਕ I/O ਵਿੱਚ ਅਚਾਨਕ, ਭਾਰੀ ਵਾਧਾ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਪ੍ਰੋਡਕਸ਼ਨ ਪੁੱਛਗਿੱਛਾਂ ਨੂੰ ਡਿਸਕ ਤੋਂ ਪੜ੍ਹਨ ਲਈ ਮਜਬੂਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ ਗੰਭੀਰ ਦੇਰੀ ਹੁੰਦੀ ਹੈ।
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 ਨੂੰ ਇਹ ਕਰਨਾ ਪੈਂਦਾ ਹੈ:
* ਕੰਸਟ੍ਰੇਂਟਸ (ਫੌਰਨ ਕੀਜ਼, ਯੂਨੀਕ ਕੀਜ਼) ਦੀ ਜਾਂਚ ਕਰਨਾ।
* ਸੈਕੰਡਰੀ ਇੰਡੈਕਸਾਂ ਨੂੰ ਦੁਬਾਰਾ ਬਣਾਉਣਾ।
* InnoDB ਰੀਡੋ ਲੌਗ ਵਿੱਚ ਲਿਖਣਾ।
* ਬਿਨਲੌਗ ਵਿੱਚ ਫਲੱਸ਼ ਕਰਨਾ (ਜੇ ਸਮਰੱਥ ਹੈ)।
ਇੱਕ 1TB ਡੇਟਾਬੇਸ ਨੂੰ ਲਾਜ਼ੀਕਲ ਡੰਪ ਤੋਂ ਰੀਸਟੋਰ ਕਰਨ ਵਿੱਚ ਕਈ ਦਿਨ ਲੱਗ ਸਕਦੇ ਹਨ। ਜੇਕਰ ਤੁਹਾਡੇ ਕਾਰੋਬਾਰ ਦਾ RTO 4 ਘੰਟੇ ਹੈ, ਤਾਂ mysqldump ਗਾਰੰਟੀ ਦਿੰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਆਪਣੇ ਸਰਵਿਸ ਲੈਵਲ ਐਗਰੀਮੈਂਟ (SLA) ਨੂੰ ਪੂਰਾ ਕਰਨ ਵਿੱਚ ਅਸਫਲ ਰਹੋਗੇ।
ਐਂਟਰਪ੍ਰਾਈਜ਼-ਗ੍ਰੇਡ ਵਿਕਲਪ: ਫਿਜ਼ੀਕਲ ਬੈਕਅੱਪ ਵੱਲ ਵਧਣਾ
ਵੱਡੇ ਡੇਟਾਸੈਟਾਂ ਲਈ ਤੇਜ਼ ਬੈਕਅੱਪ ਅਤੇ ਰੀਸਟੋਰ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ, ਤੁਹਾਨੂੰ ਲਾਜ਼ੀਕਲ ਬੈਕਅੱਪ ਨੂੰ ਛੱਡ ਕੇ ਫਿਜ਼ੀਕਲ ਬੈਕਅੱਪ ਨੂੰ ਅਪਣਾਉਣਾ ਚਾਹੀਦਾ ਹੈ।
ਫਿਜ਼ੀਕਲ ਬੈਕਅੱਪ MySQL SQL ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਇੰਜਣ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬਾਈਪਾਸ ਕਰਦੇ ਹਨ। ਇਸ ਦੀ ਬਜਾਏ, ਉਹ ਅੰਡਰਲਾਈੰਗ ਬਾਈਨਰੀ ਡੇਟਾ ਫਾਈਲਾਂ (.ibd ਫਾਈਲਾਂ, ਰੀਡੋ ਲੌਗਸ, ਅਤੇ ਅਨਡੂ ਲੌਗਸ) ਨੂੰ ਸਿੱਧੇ ਫਾਈਲਸਿਸਟਮ ਤੋਂ ਕਾਪੀ ਕਰਦੇ ਹਨ। ਕਿਉਂਕਿ ਉਹ ਸਿਰਫ਼ ਫਾਈਲਾਂ ਦੀ ਕਾਪੀ ਕਰ ਰਹੇ ਹੁੰਦੇ ਹਨ, ਉਹ ਤੁਹਾਡੇ ਸਟੋਰੇਜ ਹਾਰਡਵੇਅਰ ਦੀ ਅਧਿਕਤਮ ਸੀਕਵੈਂਸ਼ੀਅਲ ਰੀਡ/ਰਾਈਟ ਸਪੀਡ ‘ਤੇ ਕੰਮ ਕਰ ਸਕਦੇ ਹਨ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਬਹੁਤ ਜ਼ਿਆਦਾ ਪੈਰਲਲਾਈਜ਼ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।
Percona XtraBackup: ਇੰਡਸਟਰੀ ਸਟੈਂਡਰਡ
InnoDB ਅਤੇ XtraDB ਇੰਜਣਾਂ ਲਈ, Percona XtraBackup ਪ੍ਰਮੁੱਖ ਓਪਨ-ਸੋਰਸ ਫਿਜ਼ੀਕਲ ਬੈਕਅੱਪ ਟੂਲ ਹੈ। ਇਹ MySQL ਡੇਟਾਬੇਸ ਦੇ ਹੌਟ, ਨਾਨ-ਬਲੌਕਿੰਗ ਬੈਕਅੱਪ ਕਰਦਾ ਹੈ।
XtraBackup ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ
- ਡੇਟਾ ਕਾਪੀ ਕਰਨਾ: XtraBackup InnoDB ਡੇਟਾ ਫਾਈਲਾਂ (
.ibd) ਨੂੰ ਕਾਪੀ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ। - ਲੌਗ ਟ੍ਰੈਕਿੰਗ: ਕਿਉਂਕਿ ਡੇਟਾਬੇਸ ਲਾਈਵ ਹੈ, ਫਾਈਲਾਂ ਕਾਪੀ ਹੋਣ ਦੌਰਾਨ ਡੇਟਾ ਬਦਲ ਜਾਵੇਗਾ। XtraBackup ਇੱਕ ਬੈਕਗ੍ਰਾਉਂਡ ਥ੍ਰੈਡ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ ਜੋ ਬੈਕਅੱਪ ਵਿੰਡੋ ਦੌਰਾਨ ਹੋਣ ਵਾਲੇ ਕਿਸੇ ਵੀ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਲਈ InnoDB ਰੀਡੋ ਲੌਗ (
ib_logfile0, ਆਦਿ) ਦੀ ਨਿਗਰਾਨੀ ਅਤੇ ਕਾਪੀ ਕਰਦਾ ਹੈ। - ਤਿਆਰੀ (ਕ੍ਰੈਸ਼ ਰਿਕਵਰੀ): ਬੈਕਅੱਪ ਤੋਂ ਬਾਅਦ, ਕਾਪੀ ਕੀਤੀਆਂ ਡੇਟਾ ਫਾਈਲਾਂ ਅਸੰਗਤ ਸਥਿਤੀ ਵਿੱਚ ਹੁੰਦੀਆਂ ਹਨ। XtraBackup ਕਾਪੀ ਕੀਤੇ ਰੀਡੋ ਲੌਗਸ ਨੂੰ ਡੇਟਾ ਫਾਈਲਾਂ ‘ਤੇ ਲਾਗੂ ਕਰਦਾ ਹੈ (ਜਿਵੇਂ ਕਿ 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: ਰੀਸਟੋਰ ਲਈ ਬੈਕਅੱਪ ਤਿਆਰ ਕਰਨਾ
ਫਿਜ਼ੀਕਲ ਬੈਕਅੱਪ ਨੂੰ ਰੀਸਟੋਰ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਇਸਨੂੰ “ਤਿਆਰ” (ਰੀਡੋ ਲੌਗਸ ਲਾਗੂ ਕਰਨਾ) ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਪਹਿਲਾਂ, ਸਟ੍ਰੀਮ ਨੂੰ ਐਕਸਟਰੈਕਟ ਅਤੇ ਡੀਕੰਪ੍ਰੈਸ ਕਰੋ:
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]
# ਜੇਕਰ ਇਹ ਇੱਕ ਸਟੈਂਡਅਲੋਨ ਰੀਸਟੋਰ ਹੈ ਤਾਂ ਬਿਨਲੌਗਿੰਗ ਨੂੰ ਅਸਥਾਈ ਤੌਰ 'ਤੇ ਅਯੋਗ ਕਰੋ
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 ਐਨਕ੍ਰਿਪਸ਼ਨ ਲਾਗੂ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਸਨੂੰ ਇਮਿਊਟੇਬਲ ਕਲਾਉਡ ਸਟੋਰੇਜ ਵਿੱਚ ਰੀਪਲੀਕੇਟ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਡੇਟਾ ਨੂੰ ਡੀਡੁਪਲੀਕੇਟ ਕਰਦਾ ਹੈ।
ਇਹ ਆਰਕੀਟੈਕਚਰ ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ:
1. ਪ੍ਰੋਡਕਸ਼ਨ ਪ੍ਰਦਰਸ਼ਨ ਬਣਾਈ ਰੱਖਿਆ ਜਾਂਦਾ ਹੈ: ਬੈਕਅੱਪ InnoDB ਬਫਰ ਪੂਲ ਨੂੰ ਪ੍ਰਦੂਸ਼ਿਤ ਕੀਤੇ ਬਿਨਾਂ ਸਟੋਰੇਜ ਦੀ ਗਤੀ ‘ਤੇ ਚੱਲਦੇ ਹਨ।
2. ਰੈਨਸਮਵੇਅਰ ਸੁਰੱਖਿਆ: CloudSave ਦੇ ਅੰਦਰ ਇਮਿਊਟੇਬਲ ਸਟੋਰੇਜ ਨੀਤੀਆਂ ਖਤਰਨਾਕ ਅਦਾਕਾਰਾਂ ਨੂੰ ਤੁਹਾਡੇ ਡੇਟਾਬੇਸ ਆਰਕਾਈਵ ਨੂੰ ਮਿਟਾਉਣ ਜਾਂ ਐਨਕ੍ਰਿਪਟ ਕਰਨ ਤੋਂ ਰੋਕਦੀਆਂ ਹਨ।
3. ਸਵੈਚਲਿਤ ਰਿਟੈਨਸ਼ਨ: ਗ੍ਰੈਂਡਫਾਦਰ-ਫਾਦਰ-ਸਨ (GFS) ਰਿਟੈਨਸ਼ਨ ਨੀਤੀਆਂ ਨੂੰ ਸਵੈਚਲਿਤ ਤੌਰ ‘ਤੇ ਸੰਭਾਲਿਆ ਜਾਂਦਾ ਹੈ, ਜੋ ਡੇਟਾ ਪ੍ਰਭੂਸੱਤਾ ਅਤੇ ਆਡਿਟਿੰਗ ਲੋੜਾਂ ਦੀ ਪਾਲਣਾ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ।
4. ਅਨੁਮਾਨਿਤ RTO: ਕਿਉਂਕਿ CloudSave ਫਿਜ਼ੀਕਲ ਫਾਈਲ ਆਰਕਾਈਵ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਦਾ ਹੈ, ਇੱਕ ਮਲਟੀ-ਟੈਰਾਬਾਈਟ ਡੇਟਾਬੇਸ ਨੂੰ ਇੱਕ ਨਵੀਂ ਇੰਸਟੈਂਸ ਵਿੱਚ ਰੀਸਟੋਰ ਕਰਨਾ ਤੇਜ਼ੀ ਨਾਲ ਆਰਕੈਸਟ੍ਰੇਟ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਜੋ ਸਖਤ RTO ਟੀਚਿਆਂ ਨੂੰ ਪੂਰਾ ਕਰਦਾ ਹੈ।
ਸਿੱਟਾ
ਵੱਡੇ ਪੱਧਰ ਦੇ ਡੇਟਾਬੇਸ ਲਈ mysqldump ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਤੁਹਾਡੀ ਸੰਸਥਾ ਦੇ ਅਪਟਾਈਮ ਅਤੇ ਡੇਟਾ ਦੀ ਇਕਸਾਰਤਾ ਨਾਲ ਜੂਆ ਖੇਡਣਾ ਹੈ। ਸਿੰਗਲ-ਥ੍ਰੈਡਡ ਪ੍ਰਕਿਰਤੀ, ਬਫਰ ਪੂਲ ਪ੍ਰਦੂਸ਼ਣ, ਅਤੇ ਰੀਸਟੋਰ ਕਰਨ ਵਿੱਚ ਲੱਗਣ ਵਾਲਾ ਬਹੁਤ ਜ਼ਿਆਦਾ ਸਮਾਂ ਇਸਨੂੰ ਆਧੁਨਿਕ, ਉੱਚ-ਥ੍ਰੂਪੁੱਟ ਵਾਤਾਵਰਣ ਲਈ ਬੁਨਿਆਦੀ ਤੌਰ ‘ਤੇ ਅਯੋਗ ਬਣਾਉਂਦਾ ਹੈ।
Percona XtraBackup ਵਰਗੇ ਟੂਲਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਫਿਜ਼ੀਕਲ ਬੈਕਅੱਪ ਵੱਲ ਵਧ ਕੇ, ਅਤੇ CloudSave ਵਰਗੇ ਮਜ਼ਬੂਤ ਪਲੇਟਫਾਰਮ ਰਾਹੀਂ ਲਾਈਫਸਾਈਕਲ, ਐਨਕ੍ਰਿਪਸ਼ਨ, ਅਤੇ ਆਫਸਾਈਟ ਰੀਪਲੀਕੇਸ਼ਨ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਕੇ, ਤੁਸੀਂ ਆਪਣੀ ਡੇਟਾਬੇਸ ਬੈਕਅੱਪ ਰਣਨੀਤੀ ਨੂੰ ਇੱਕ ਕਮਜ਼ੋਰ ਦੇਣਦਾਰੀ ਤੋਂ ਇੱਕ ਲਚਕੀਲੇ, ਐਂਟਰਪ੍ਰਾਈਜ਼-ਗ੍ਰੇਡ ਸੰਪਤੀ ਵਿੱਚ ਬਦਲਦੇ ਹੋ। ਅੱਜ ਹੀ ਆਪਣੇ ਮੌਜੂਦਾ RTO ਅਤੇ RPO ਮੈਟ੍ਰਿਕਸ ਦਾ ਮੁਲਾਂਕਣ ਕਰੋ—ਜੇਕਰ ਰੀਸਟੋਰ ਕਰਨ ਵਿੱਚ ਤੁਹਾਡੇ ਕਾਰੋਬਾਰ ਦੇ ਬਰਦਾਸ਼ਤ ਕਰਨ ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਸਮਾਂ ਲੱਗਦਾ ਹੈ, ਤਾਂ mysqldump ਨੂੰ ਪਿੱਛੇ ਛੱਡਣ ਦਾ ਸਮਾਂ ਆ ਗਿਆ ਹੈ।
