MySQL (Percona ਸਰਵਰ) ਨੂੰ 5.7 ਤੋਂ 8.0 ਤੱਕ ਅੱਪਡੇਟ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ

ਤਰੱਕੀ ਅਜੇ ਵੀ ਖੜ੍ਹੀ ਨਹੀਂ ਹੈ, ਇਸ ਲਈ MySQL ਦੇ ਨਵੀਨਤਮ ਸੰਸਕਰਣਾਂ 'ਤੇ ਅਪਗ੍ਰੇਡ ਕਰਨ ਦੇ ਕਾਰਨ ਤੇਜ਼ੀ ਨਾਲ ਮਜਬੂਰ ਹੋ ਰਹੇ ਹਨ। ਕੁਝ ਸਮਾਂ ਪਹਿਲਾਂ, ਸਾਡੇ ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚੋਂ ਇੱਕ ਵਿੱਚ, ਇਹ ਆਰਾਮਦਾਇਕ ਪਰਕੋਨਾ ਸਰਵਰ 5.7 ਕਲੱਸਟਰਾਂ ਨੂੰ ਸੰਸਕਰਣ 8 ਵਿੱਚ ਅੱਪਡੇਟ ਕਰਨ ਦਾ ਸਮਾਂ ਸੀ। ਇਹ ਸਭ ਉਬੰਟੂ ਲੀਨਕਸ 16.04 ਪਲੇਟਫਾਰਮ 'ਤੇ ਹੋਇਆ। ਨਿਊਨਤਮ ਡਾਊਨਟਾਈਮ ਦੇ ਨਾਲ ਅਜਿਹਾ ਓਪਰੇਸ਼ਨ ਕਿਵੇਂ ਕਰਨਾ ਹੈ ਅਤੇ ਅਪਡੇਟ ਦੇ ਦੌਰਾਨ ਸਾਨੂੰ ਕਿਹੜੀਆਂ ਸਮੱਸਿਆਵਾਂ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪਿਆ - ਇਸ ਲੇਖ ਵਿੱਚ ਪੜ੍ਹੋ.

ਸਿਖਲਾਈ

ਡਾਟਾਬੇਸ ਸਰਵਰ ਦਾ ਕੋਈ ਵੀ ਅੱਪਡੇਟ ਸੰਭਾਵਤ ਤੌਰ 'ਤੇ ਡਾਟਾਬੇਸ ਪੁਨਰ-ਸੰਰਚਨਾ ਨਾਲ ਜੁੜਿਆ ਹੋਇਆ ਹੈ: ਸਿਸਟਮ ਸਰੋਤਾਂ ਦੀਆਂ ਸੀਮਾਵਾਂ ਲਈ ਲੋੜਾਂ ਵਿੱਚ ਬਦਲਾਅ ਅਤੇ ਡਾਟਾਬੇਸ ਸੰਰਚਨਾਵਾਂ ਦੇ ਸੁਧਾਰ ਜਿਨ੍ਹਾਂ ਨੂੰ ਪੁਰਾਣੇ ਨਿਰਦੇਸ਼ਾਂ ਤੋਂ ਸਾਫ਼ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।

ਅੱਪਡੇਟ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਅਸੀਂ ਯਕੀਨੀ ਤੌਰ 'ਤੇ ਅਧਿਕਾਰਤ ਦਸਤਾਵੇਜ਼ਾਂ ਦਾ ਹਵਾਲਾ ਦੇਵਾਂਗੇ:

• MySQL 8 ਰੀਲੀਜ਼ ਨੋਟਸ;
• MySQL ਅੱਪਗਰੇਡ ਗਾਈਡ;
• Percona ਅੱਪਡੇਟ ਗਾਈਡ;
• ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਅਤੇ ਮਾਸਟਰਾਂ ਨੂੰ ਅਪਡੇਟ ਕਰਨ ਲਈ MySQL ਗਾਈਡ.

ਅਤੇ ਆਓ ਇੱਕ ਕਾਰਜ ਯੋਜਨਾ ਤਿਆਰ ਕਰੀਏ:

1. ਪੁਰਾਣੀਆਂ ਹਦਾਇਤਾਂ ਨੂੰ ਹਟਾ ਕੇ ਸੰਰਚਨਾ ਫਾਈਲਾਂ ਨੂੰ ਠੀਕ ਕਰੋ।
2. ਉਪਯੋਗਤਾਵਾਂ ਨਾਲ ਅਨੁਕੂਲਤਾ ਦੀ ਜਾਂਚ ਕਰੋ।
3. ਪੈਕੇਜ ਨੂੰ ਸਥਾਪਿਤ ਕਰਕੇ ਸਲੇਵ ਡੇਟਾਬੇਸ ਨੂੰ ਅਪਡੇਟ ਕਰੋ percona-server-server.
4. ਉਸੇ ਪੈਕੇਜ ਨਾਲ ਮਾਸਟਰ ਨੂੰ ਅੱਪਡੇਟ ਕਰੋ।

ਆਉ ਯੋਜਨਾ ਦੇ ਹਰੇਕ ਬਿੰਦੂ ਨੂੰ ਵੇਖੀਏ ਅਤੇ ਦੇਖੀਏ ਕਿ ਕੀ ਗਲਤ ਹੋ ਸਕਦਾ ਹੈ।

ਮਹੱਤਵਪੂਰਣ! ਗੈਲੇਰਾ 'ਤੇ ਅਧਾਰਤ ਇੱਕ MySQL ਕਲੱਸਟਰ ਨੂੰ ਅਪਡੇਟ ਕਰਨ ਦੀ ਪ੍ਰਕਿਰਿਆ ਦੀਆਂ ਆਪਣੀਆਂ ਸੂਖਮਤਾਵਾਂ ਹਨ ਜੋ ਲੇਖ ਵਿੱਚ ਵਰਣਨ ਨਹੀਂ ਕੀਤੀਆਂ ਗਈਆਂ ਹਨ। ਤੁਹਾਨੂੰ ਇਸ ਕੇਸ ਵਿੱਚ ਇਸ ਹਦਾਇਤ ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰਨੀ ਚਾਹੀਦੀ।

ਭਾਗ 1: ਸੰਰਚਨਾ ਦੀ ਜਾਂਚ ਕੀਤੀ ਜਾ ਰਹੀ ਹੈ

MySQL ਨੂੰ ਵਰਜਨ 8 ਵਿੱਚ ਹਟਾ ਦਿੱਤਾ ਗਿਆ ਸੀ query_cache. ਅਸਲ ਵਿੱਚ ਉਹ ਸੀ ਅਪ੍ਰਚਲਿਤ ਘੋਸ਼ਿਤ ਕੀਤਾ ਵਾਪਸ ਸੰਸਕਰਣ 5.7 ਵਿੱਚ, ਪਰ ਹੁਣ ਪੂਰੀ ਤਰ੍ਹਾਂ ਮਿਟਾਇਆ ਗਿਆ. ਇਸ ਅਨੁਸਾਰ, ਸੰਬੰਧਿਤ ਨਿਰਦੇਸ਼ਾਂ ਨੂੰ ਹਟਾਉਣਾ ਜ਼ਰੂਰੀ ਹੈ. ਅਤੇ ਬੇਨਤੀਆਂ ਨੂੰ ਕੈਸ਼ ਕਰਨ ਲਈ ਤੁਸੀਂ ਹੁਣ ਬਾਹਰੀ ਟੂਲਸ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ - ਉਦਾਹਰਨ ਲਈ, ProxySQL.

ਸੰਰਚਨਾ ਵਿੱਚ ਵੀ ਇਸ ਬਾਰੇ ਪੁਰਾਣੇ ਨਿਰਦੇਸ਼ ਸਨ innodb_file_format. ਜੇਕਰ MySQL 5.7 ਵਿੱਚ InnoDB ਫਾਰਮੈਟ ਨੂੰ ਚੁਣਨਾ ਸੰਭਵ ਸੀ, ਤਾਂ 8ਵਾਂ ਸੰਸਕਰਣ ਪਹਿਲਾਂ ਹੀ ਕੰਮ ਕਰਦਾ ਹੈ ਸਿਰਫ਼ ਬੈਰਾਕੁਡਾ ਫਾਰਮੈਟ ਨਾਲ.

ਸਾਡਾ ਨਤੀਜਾ ਹੇਠਾਂ ਦਿੱਤੇ ਨਿਰਦੇਸ਼ਾਂ ਨੂੰ ਹਟਾਉਣਾ ਹੈ:

• query_cache_type, query_cache_limit и query_cache_size;
• innodb_file_format и innodb_file_format_max.

ਜਾਂਚ ਕਰਨ ਲਈ, ਅਸੀਂ ਪਰਕੋਨਾ ਸਰਵਰ ਦੇ ਡੌਕਰ ਚਿੱਤਰ ਦੀ ਵਰਤੋਂ ਕਰਾਂਗੇ। ਅਸੀਂ ਸਰਵਰ ਸੰਰਚਨਾ ਨੂੰ ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ ਰੱਖਾਂਗੇ mysql_config_test, ਅਤੇ ਇਸਦੇ ਅੱਗੇ ਅਸੀਂ ਡੇਟਾ ਅਤੇ ਲੌਗਸ ਲਈ ਡਾਇਰੈਕਟਰੀਆਂ ਬਣਾਵਾਂਗੇ। ਪਰਕੋਨਾ-ਸਰਵਰ ਕੌਂਫਿਗਰੇਸ਼ਨ ਟੈਸਟ ਉਦਾਹਰਨ:

mkdir -p {mysql_config_test,mysql_data,mysql_logs}
cp -r /etc/mysql/conf.d/* mysql_config_test/
docker run  --name some-percona -v $(pwd)/mysql_config_test:/etc/my.cnf.d/  -v $(pwd)/mysql_data/:/var/lib/mysql/ -v $(pwd)/mysql_logs/:/var/log/mysql/ -e MYSQL_ROOT_PASSWORD=${MYSQL_PASSWORD} -d percona:8-centos

ਤਲ ਲਾਈਨ: ਜਾਂ ਤਾਂ ਡੌਕਰ ਲੌਗਸ ਵਿੱਚ ਜਾਂ ਲੌਗਸ ਵਾਲੀ ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ - ਤੁਹਾਡੀਆਂ ਸੰਰਚਨਾਵਾਂ ਦੇ ਅਧਾਰ ਤੇ - ਇੱਕ ਫਾਈਲ ਦਿਖਾਈ ਦੇਵੇਗੀ ਜਿਸ ਵਿੱਚ ਸਮੱਸਿਆ ਵਾਲੇ ਨਿਰਦੇਸ਼ਾਂ ਦਾ ਵਰਣਨ ਕੀਤਾ ਜਾਵੇਗਾ।

ਇੱਥੇ ਸਾਡੇ ਕੋਲ ਕੀ ਸੀ:

2020-04-03T12:44:19.670831Z 0 [Warning] [MY-011068] [Server] The syntax 'expire-logs-days' is deprecated and will be removed in a future release. Please use binlog_expire_logs_seconds instead.
2020-04-03T12:44:19.671678Z 0 [Warning] [MY-013242] [Server] --character-set-server: 'utf8' is currently an alias for the character set UTF8MB3, but will be an alias for UTF8MB4 in a future release. Please consider using UTF8MB4 in order to be unambiguous.
2020-04-03T12:44:19.671682Z 0 [Warning] [MY-013244] [Server] --collation-server: 'utf8_general_ci' is a collation of the deprecated character set UTF8MB3. Please consider using UTF8MB4 with an appropriate collation instead.

ਇਸ ਤਰ੍ਹਾਂ, ਸਾਨੂੰ ਅਜੇ ਵੀ ਏਨਕੋਡਿੰਗਾਂ ਦਾ ਪਤਾ ਲਗਾਉਣ ਅਤੇ ਪੁਰਾਣੇ ਨਿਰਦੇਸ਼ਾਂ ਨੂੰ ਬਦਲਣ ਦੀ ਲੋੜ ਹੈ expire-logs-days.

ਭਾਗ 2: ਕਾਰਜਸ਼ੀਲ ਸਥਾਪਨਾਵਾਂ ਦੀ ਜਾਂਚ ਕਰਨਾ

ਅਪਡੇਟ ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਅਨੁਕੂਲਤਾ ਲਈ ਡੇਟਾਬੇਸ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ 2 ਉਪਯੋਗਤਾਵਾਂ ਸ਼ਾਮਲ ਹਨ। ਉਹਨਾਂ ਦੀ ਵਰਤੋਂ ਪ੍ਰਸ਼ਾਸਕ ਨੂੰ ਮੌਜੂਦਾ ਡੇਟਾ ਢਾਂਚੇ ਦੀ ਅਨੁਕੂਲਤਾ ਦੀ ਜਾਂਚ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦੀ ਹੈ।

ਆਉ ਕਲਾਸਿਕ mysqlcheck ਉਪਯੋਗਤਾ ਨਾਲ ਸ਼ੁਰੂ ਕਰੀਏ। ਬਸ ਚਲਾਓ:

mysqlcheck -u root -p --all-databases --check-upgrade

ਜੇਕਰ ਕੋਈ ਸਮੱਸਿਆ ਨਹੀਂ ਮਿਲਦੀ ਹੈ, ਤਾਂ ਸਹੂਲਤ ਕੋਡ 0 ਨਾਲ ਬਾਹਰ ਆ ਜਾਵੇਗੀ:

ਇਸ ਤੋਂ ਇਲਾਵਾ, MySQL ਦੇ ਆਧੁਨਿਕ ਸੰਸਕਰਣਾਂ ਵਿੱਚ ਇੱਕ ਉਪਯੋਗਤਾ ਉਪਲਬਧ ਹੈ mysql-ਸ਼ੈੱਲ (ਪਰਕੋਨਾ ਦੇ ਮਾਮਲੇ ਵਿੱਚ ਇਹ ਪੈਕੇਜ ਹੈ percona-mysql-shell). ਇਹ ਕਲਾਸਿਕ mysql ਕਲਾਇੰਟ ਲਈ ਇੱਕ ਬਦਲ ਹੈ ਅਤੇ ਇੱਕ ਕਲਾਇੰਟ, ਇੱਕ SQL ਕੋਡ ਸੰਪਾਦਕ ਅਤੇ MySQL ਪ੍ਰਸ਼ਾਸਨ ਸਾਧਨਾਂ ਦੇ ਫੰਕਸ਼ਨਾਂ ਨੂੰ ਜੋੜਦਾ ਹੈ। ਅੱਪਡੇਟ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਸਰਵਰ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ, ਤੁਸੀਂ ਇਸ ਰਾਹੀਂ ਹੇਠ ਲਿਖੀਆਂ ਕਮਾਂਡਾਂ ਚਲਾ ਸਕਦੇ ਹੋ:

mysqlsh -- util check-for-server-upgrade { --user=root --host=1.1.1.1 --port=3306 } --config-path=/etc/mysql/my.cnf

ਇੱਥੇ ਸਾਨੂੰ ਪ੍ਰਾਪਤ ਟਿੱਪਣੀਆਂ ਹਨ:

ਆਮ ਤੌਰ 'ਤੇ, ਕੁਝ ਵੀ ਨਾਜ਼ੁਕ ਨਹੀਂ - ਸਿਰਫ ਏਨਕੋਡਿੰਗਾਂ ਬਾਰੇ ਚੇਤਾਵਨੀਆਂ (ਨੀਚੇ ਦੇਖੋ). ਕੁੱਲ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਨਤੀਜਾ:

ਅਸੀਂ ਫੈਸਲਾ ਕੀਤਾ ਹੈ ਕਿ ਅਪਡੇਟ ਨੂੰ ਬਿਨਾਂ ਕਿਸੇ ਸਮੱਸਿਆ ਦੇ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।

ਉਪਰੋਕਤ ਚੇਤਾਵਨੀਆਂ ਬਾਰੇ ਇੱਕ ਨੋਟ ਜੋ ਏਨਕੋਡਿੰਗ ਨਾਲ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ। ਤੱਥ ਇਹ ਹੈ ਕਿ ਹਾਲ ਹੀ ਵਿੱਚ ਜਦੋਂ ਤੱਕ MySQL ਵਿੱਚ UTF-8 UTF-8 "ਸੱਚਾ" ਨਹੀਂ ਸੀ, ਕਿਉਂਕਿ ਇਸਨੇ 3 ਦੀ ਬਜਾਏ ਸਿਰਫ 4 ਬਾਈਟ ਸਟੋਰ ਕੀਤੇ ਹਨ। MySQL 8 ਵਿੱਚ ਇਹ ਅੰਤ ਵਿੱਚ ਹੈ ਇਸ ਨੂੰ ਠੀਕ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ: ਉਪਨਾਮ utf8 ਜਲਦੀ ਹੀ ਕੋਡਿੰਗ ਵੱਲ ਲੈ ਜਾਵੇਗਾ utf8mb4, ਅਤੇ ਟੇਬਲ ਵਿੱਚ ਪੁਰਾਣੇ ਕਾਲਮ ਬਣ ਜਾਣਗੇ utf8mb3. ਹੋਰ ਇੰਕੋਡਿੰਗ utf8mb3 ਹਟਾ ਦਿੱਤਾ ਜਾਵੇਗਾ, ਪਰ ਇਸ ਰੀਲੀਜ਼ ਵਿੱਚ ਨਹੀਂ। ਇਸ ਲਈ, ਅਸੀਂ ਇਸਨੂੰ ਅੱਪਡੇਟ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਚੱਲ ਰਹੀ DBMS ਇੰਸਟਾਲੇਸ਼ਨ 'ਤੇ ਪਹਿਲਾਂ ਤੋਂ ਹੀ ਏਨਕੋਡਿੰਗਾਂ ਨੂੰ ਠੀਕ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਹੈ।

ਭਾਗ 3: ਸਰਵਰ ਅੱਪਡੇਟ

ਜਦੋਂ ਅਜਿਹੀ ਸਮਾਰਟ ਯੋਜਨਾ ਹੋਵੇ ਤਾਂ ਕੀ ਗਲਤ ਹੋ ਸਕਦਾ ਹੈ?... ਪੂਰੀ ਤਰ੍ਹਾਂ ਨਾਲ ਸਮਝਦੇ ਹੋਏ ਕਿ ਬਾਰੀਕੀਆਂ ਹਮੇਸ਼ਾ ਵਾਪਰਦੀਆਂ ਹਨ, ਅਸੀਂ ਇੱਕ MySQL dev ਕਲੱਸਟਰ 'ਤੇ ਪਹਿਲਾ ਪ੍ਰਯੋਗ ਕੀਤਾ।

ਜਿਵੇਂ ਕਿ ਪਹਿਲਾਂ ਹੀ ਦੱਸਿਆ ਗਿਆ ਹੈ, ਅਧਿਕਾਰਤ ਦਸਤਾਵੇਜ਼ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਦੇ ਨਾਲ MySQL ਸਰਵਰਾਂ ਨੂੰ ਅਪਡੇਟ ਕਰਨ ਦੇ ਮੁੱਦੇ ਨੂੰ ਕਵਰ ਕਰਦਾ ਹੈ। ਤਲ ਲਾਈਨ ਇਹ ਹੈ ਕਿ ਤੁਹਾਨੂੰ ਪਹਿਲਾਂ ਸਾਰੀਆਂ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ (ਗੁਲਾਮਾਂ) ਨੂੰ ਅਪਡੇਟ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਕਿਉਂਕਿ MySQL 8 ਇੱਕ ਮਾਸਟਰ ਸੰਸਕਰਣ 5.7 ਤੋਂ ਨਕਲ ਕਰ ਸਕਦਾ ਹੈ। ਕੁਝ ਮੁਸ਼ਕਲ ਇਸ ਤੱਥ ਵਿੱਚ ਹੈ ਕਿ ਅਸੀਂ ਮੋਡ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ ਮਾਸਟਰ <-> ਮਾਸਟਰ, ਜਦੋਂ ਰਿਮੋਟ ਮਾਸਟਰ ਮੋਡ ਵਿੱਚ ਹੁੰਦਾ ਹੈ ਸਿਰਫ ਪੜ੍ਹਨ ਲਈ. ਇਹ ਹੈ, ਅਸਲ ਵਿੱਚ, ਲੜਾਈ ਟ੍ਰੈਫਿਕ ਇੱਕ ਡੇਟਾ ਸੈਂਟਰ ਵਿੱਚ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਦੂਜਾ ਇੱਕ ਬੈਕਅੱਪ ਇੱਕ ਹੈ.

ਟੌਪੌਲੋਜੀ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ:

ਅੱਪਡੇਟ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਨਾਲ ਸ਼ੁਰੂ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ mysql ਪ੍ਰਤੀਕ੍ਰਿਤੀ dc 2, mysql ਮਾਸਟਰ ਡੀਸੀ 2 и mysql replica dc 1, ਅਤੇ mysql master dc 1 ਸਰਵਰ ਨਾਲ ਸਮਾਪਤ ਕਰੋ। ਵਧੇਰੇ ਭਰੋਸੇਮੰਦ ਹੋਣ ਲਈ, ਅਸੀਂ ਵਰਚੁਅਲ ਮਸ਼ੀਨਾਂ ਨੂੰ ਰੋਕ ਦਿੱਤਾ, ਉਹਨਾਂ ਦੇ ਸਨੈਪਸ਼ਾਟ ਲਏ, ਅਤੇ ਅੱਪਡੇਟ ਤੋਂ ਤੁਰੰਤ ਪਹਿਲਾਂ ਕਮਾਂਡ ਨਾਲ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਬੰਦ ਕਰ ਦਿੱਤੀ। STOP SLAVE. ਬਾਕੀ ਅਪਡੇਟ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਦਾ ਹੈ:

1. ਅਸੀਂ ਸੰਰਚਨਾ ਵਿੱਚ 3 ਵਿਕਲਪ ਜੋੜ ਕੇ ਹਰੇਕ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਨੂੰ ਮੁੜ ਚਾਲੂ ਕਰਦੇ ਹਾਂ: skip-networking, skip-slave-start, skip-log-bin. ਤੱਥ ਇਹ ਹੈ ਕਿ ਡੇਟਾਬੇਸ ਨੂੰ ਅੱਪਡੇਟ ਕਰਨ ਨਾਲ ਸਿਸਟਮ ਟੇਬਲ ਦੇ ਅੱਪਡੇਟ ਦੇ ਨਾਲ ਬਾਈਨਰੀ ਲੌਗ ਤਿਆਰ ਹੁੰਦੇ ਹਨ। ਇਹ ਨਿਰਦੇਸ਼ ਗਾਰੰਟੀ ਦਿੰਦੇ ਹਨ ਕਿ ਡੇਟਾਬੇਸ ਵਿੱਚ ਐਪਲੀਕੇਸ਼ਨ ਡੇਟਾ ਵਿੱਚ ਕੋਈ ਬਦਲਾਅ ਨਹੀਂ ਹੋਣਗੇ, ਅਤੇ ਸਿਸਟਮ ਟੇਬਲ ਨੂੰ ਅਪਡੇਟ ਕਰਨ ਬਾਰੇ ਜਾਣਕਾਰੀ ਬਾਈਨਰੀ ਲੌਗ ਵਿੱਚ ਸ਼ਾਮਲ ਨਹੀਂ ਕੀਤੀ ਜਾਵੇਗੀ। ਇਹ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਨੂੰ ਮੁੜ ਸ਼ੁਰੂ ਕਰਨ ਵੇਲੇ ਸਮੱਸਿਆਵਾਂ ਤੋਂ ਬਚੇਗਾ।
2. ਪੈਕੇਜ ਇੰਸਟਾਲ ਕਰ ਰਿਹਾ ਹੈ percona-server-server. ਇਹ ਨੋਟ ਕਰਨਾ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿ MySQL ਸੰਸਕਰਣ 8 ਵਿੱਚ ਨਾ ਤੁਹਾਨੂੰ ਕਮਾਂਡ ਚਲਾਉਣ ਦੀ ਲੋੜ ਹੈ mysqlupgrade ਸਰਵਰ ਅੱਪਡੇਟ ਦੇ ਬਾਅਦ.
3. ਇੱਕ ਸਫਲ ਸ਼ੁਰੂਆਤ ਤੋਂ ਬਾਅਦ, ਅਸੀਂ ਸਰਵਰ ਨੂੰ ਦੁਬਾਰਾ ਚਾਲੂ ਕਰਦੇ ਹਾਂ - ਉਹਨਾਂ ਮਾਪਦੰਡਾਂ ਦੇ ਬਿਨਾਂ ਜੋ ਪਹਿਲੇ ਪੈਰੇ ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤੇ ਗਏ ਸਨ।
4. ਅਸੀਂ ਯਕੀਨੀ ਬਣਾਉਂਦੇ ਹਾਂ ਕਿ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਸਫਲਤਾਪੂਰਵਕ ਕੰਮ ਕਰਦੀ ਹੈ: ਜਾਂਚ ਕਰੋ SHOW SLAVE STATUS ਅਤੇ ਵੇਖੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਡੇਟਾਬੇਸ ਵਿੱਚ ਕਾਊਂਟਰਾਂ ਵਾਲੇ ਟੇਬਲ ਅੱਪਡੇਟ ਕੀਤੇ ਗਏ ਹਨ।

ਇਹ ਸਭ ਕਾਫ਼ੀ ਸਧਾਰਨ ਜਾਪਦਾ ਹੈ: dev ਅੱਪਡੇਟ ਸਫਲ ਸੀ. ਠੀਕ ਹੈ, ਤੁਸੀਂ ਉਤਪਾਦਨ ਲਈ ਇੱਕ ਰਾਤ ਦੇ ਅਪਡੇਟ ਨੂੰ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਨਿਯਤ ਕਰ ਸਕਦੇ ਹੋ।

ਕੋਈ ਉਦਾਸੀ ਨਹੀਂ ਸੀ - ਅਸੀਂ ਉਤਪਾਦ ਨੂੰ ਅਪਡੇਟ ਕੀਤਾ

ਹਾਲਾਂਕਿ, ਉਤਪਾਦਨ ਵਿੱਚ ਸਫਲ ਦੇਵ ਅਨੁਭਵ ਦਾ ਤਬਾਦਲਾ ਹੈਰਾਨੀ ਤੋਂ ਬਿਨਾਂ ਨਹੀਂ ਸੀ।

ਖੁਸ਼ਕਿਸਮਤੀ ਨਾਲ, ਅੱਪਡੇਟ ਪ੍ਰਕਿਰਿਆ ਖੁਦ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ, ਇਸ ਲਈ ਜਦੋਂ ਸਾਨੂੰ ਮੁਸ਼ਕਲਾਂ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪਿਆ, ਅਸੀਂ ਕੰਮ ਨੂੰ ਰੋਕ ਦਿੱਤਾ ਅਤੇ ਸਨੈਪਸ਼ਾਟ ਤੋਂ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਨੂੰ ਬਹਾਲ ਕੀਤਾ। ਸਮੱਸਿਆਵਾਂ ਦੀ ਜਾਂਚ ਅਗਲੀ ਸਵੇਰ ਤੱਕ ਮੁਲਤਵੀ ਕਰ ਦਿੱਤੀ ਗਈ। ਲੌਗਸ ਵਿੱਚ ਹੇਠ ਲਿਖੀਆਂ ਐਂਟਰੀਆਂ ਸਨ:

2020-01-14T21:43:21.500563Z 2 [ERROR] [MY-012069] [InnoDB] table: t1 has 19 columns but InnoDB dictionary has 20 columns
2020-01-14T21:43:21.500722Z 2 [ERROR] [MY-010767] [Server] Error in fixing SE data for db1.t1
2020-01-14T21:43:24.208365Z 0 [ERROR] [MY-010022] [Server] Failed to Populate DD tables.
2020-01-14T21:43:24.208658Z 0 [ERROR] [MY-010119] [Server] Aborting

ਗੂਗਲ 'ਤੇ ਵੱਖ-ਵੱਖ ਮੇਲਿੰਗ ਸੂਚੀਆਂ ਦੇ ਪੁਰਾਲੇਖਾਂ ਦੀ ਖੋਜ ਕਰਨ ਨਾਲ ਇਹ ਸਮਝ ਆਈ ਕਿ ਇਹ ਸਮੱਸਿਆ ਕਾਰਨ ਹੁੰਦੀ ਹੈ MySQL ਬੱਗ. ਹਾਲਾਂਕਿ ਇਹ ਇੱਕ ਉਪਯੋਗਤਾ ਬੱਗ ਦੀ ਜ਼ਿਆਦਾ ਸੰਭਾਵਨਾ ਹੈ mysqlcheck и mysqlsh.

ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ ਕਿ MySQL ਨੇ ਦਸ਼ਮਲਵ ਖੇਤਰਾਂ (int, tinyint, ਆਦਿ) ਲਈ ਡੇਟਾ ਨੂੰ ਦਰਸਾਉਣ ਦੇ ਤਰੀਕੇ ਨੂੰ ਬਦਲ ਦਿੱਤਾ ਹੈ, ਇਸਲਈ mysql-ਸਰਵਰ ਉਹਨਾਂ ਨੂੰ ਸਟੋਰ ਕਰਨ ਲਈ ਇੱਕ ਵੱਖਰਾ ਤਰੀਕਾ ਵਰਤਦਾ ਹੈ। ਜੇ ਤੁਹਾਡਾ ਡੇਟਾਬੇਸ ਸ਼ੁਰੂ ਵਿੱਚ ਸੰਸਕਰਣ 5.5 ਜਾਂ 5.1 ਵਿੱਚ ਸੀ, ਅਤੇ ਫਿਰ ਤੁਸੀਂ 5.7 ਵਿੱਚ ਅਪਡੇਟ ਕੀਤਾ, ਫਿਰ ਤੁਹਾਨੂੰ ਇਹ ਕਰਨ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ OPTIMIZE ਕੁਝ ਟੇਬਲ ਲਈ. ਫਿਰ MySQL ਡੇਟਾ ਫਾਈਲਾਂ ਨੂੰ ਅਪਡੇਟ ਕਰੇਗਾ, ਉਹਨਾਂ ਨੂੰ ਮੌਜੂਦਾ ਸਟੋਰੇਜ ਫਾਰਮੈਟ ਵਿੱਚ ਟ੍ਰਾਂਸਫਰ ਕਰੇਗਾ।

ਤੁਸੀਂ ਇਸ ਨੂੰ ਉਪਯੋਗਤਾ ਨਾਲ ਵੀ ਚੈੱਕ ਕਰ ਸਕਦੇ ਹੋ mysqlfrm:

mysqlfrm --diagnostic -vv /var/lib/mysql/db/table.frm
...
 'field_length': 8,
  'field_type': 246, # формат поля
  'field_type_name': 'decimal',
  'flags': 3,
  'flags_extra': 67,
  'interval_nr': 0,
 'name': 'you_deciaml_column',
...

ਜੇ field_type ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਇਹ 0 ਦੇ ਬਰਾਬਰ ਹੈ, ਤਾਂ ਸਾਰਣੀ ਵਿੱਚ ਪੁਰਾਣੀ ਕਿਸਮ ਵਰਤੀ ਜਾਂਦੀ ਹੈ - ਤੁਹਾਨੂੰ ਪੂਰਾ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ OPTIMIZE. ਹਾਲਾਂਕਿ, ਜੇਕਰ ਮੁੱਲ 246 ਹੈ, ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਇੱਕ ਨਵੀਂ ਕਿਸਮ ਹੈ। ਕਿਸਮਾਂ ਬਾਰੇ ਵਧੇਰੇ ਜਾਣਕਾਰੀ ਵਿੱਚ ਲੱਭੀ ਜਾ ਸਕਦੀ ਹੈ ਕੋਡ.

ਇਸ ਤੋਂ ਇਲਾਵਾ, ਵਿੱਚ ਇਹ ਬੱਗ ਅਸੀਂ ਦੂਜੇ ਸੰਭਾਵਿਤ ਕਾਰਨ 'ਤੇ ਵਿਚਾਰ ਕਰ ਰਹੇ ਹਾਂ, ਜਿਸ ਨੇ ਸਾਨੂੰ ਬਾਈਪਾਸ ਕੀਤਾ: ਸਿਸਟਮ ਟੇਬਲ ਵਿੱਚ InnoDB ਟੇਬਲ ਦੀ ਅਣਹੋਂਦ INNODB_SYS_TABLESPACES, ਜੇਕਰ ਉਹ, ਟੇਬਲ, ਵਰਜਨ 5.1 ਵਿੱਚ ਬਣਾਏ ਗਏ ਸਨ। ਅੱਪਡੇਟ ਕਰਨ ਵੇਲੇ ਸਮੱਸਿਆਵਾਂ ਤੋਂ ਬਚਣ ਲਈ, ਤੁਸੀਂ ਵਰਤ ਸਕਦੇ ਹੋ ਨੱਥੀ SQL ਸਕ੍ਰਿਪਟ.

ਸਾਨੂੰ ਦੇਵ 'ਤੇ ਅਜਿਹੀਆਂ ਸਮੱਸਿਆਵਾਂ ਕਿਉਂ ਨਹੀਂ ਆਈਆਂ? ਡਾਟਾਬੇਸ ਨੂੰ ਸਮੇਂ-ਸਮੇਂ 'ਤੇ ਉਤਪਾਦਨ ਤੋਂ ਕਾਪੀ ਕੀਤਾ ਜਾਂਦਾ ਹੈ - ਇਸ ਤਰ੍ਹਾਂ, ਟੇਬਲ ਦੁਬਾਰਾ ਬਣਾਏ ਗਏ ਹਨ.

ਬਦਕਿਸਮਤੀ ਨਾਲ, ਅਸਲ ਵਿੱਚ ਕੰਮ ਕਰਨ ਵਾਲੇ ਵੱਡੇ ਡੇਟਾਬੇਸ 'ਤੇ, ਤੁਸੀਂ ਸਿਰਫ਼ ਇੱਕ ਯੂਨੀਵਰਸਲ ਲੈਣ ਅਤੇ ਚਲਾਉਣ ਦੇ ਯੋਗ ਨਹੀਂ ਹੋਵੋਗੇ OPTIMIZE. percona-ਟੂਲਕਿੱਟ ਇੱਥੇ ਮਦਦ ਕਰੇਗੀ: ਔਨਲਾਈਨ ਓਪਟੀਮਾਈਜ਼ ਓਪਰੇਸ਼ਨ ਲਈ pt-ਆਨਲਾਈਨ-ਸਕੀਮਾ-ਚੇਂਜ ਸਹੂਲਤ ਬਹੁਤ ਵਧੀਆ ਹੈ।

ਅੱਪਡੇਟ ਕੀਤੀ ਯੋਜਨਾ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦੀ ਸੀ:

1. ਸਾਰੀਆਂ ਸਾਰਣੀਆਂ ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਓ।
2. ਡੇਟਾਬੇਸ ਨੂੰ ਅਪਡੇਟ ਕਰੋ.

ਇਸਦੀ ਜਾਂਚ ਕਰਨ ਲਈ ਅਤੇ ਉਸੇ ਸਮੇਂ ਅਪਡੇਟ ਦਾ ਸਮਾਂ ਪਤਾ ਕਰਨ ਲਈ, ਅਸੀਂ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਵਿੱਚੋਂ ਇੱਕ ਨੂੰ ਅਯੋਗ ਕਰ ਦਿੱਤਾ ਹੈ ਅਤੇ ਸਾਰੀਆਂ ਟੇਬਲਾਂ ਲਈ ਹੇਠ ਲਿਖੀ ਕਮਾਂਡ ਚਲਾਈ ਹੈ:

pt-online-schema-change --critical-load Threads_running=150 --alter "ENGINE=InnoDB" --execute --chunk-size 100 --quiet --alter-foreign-keys-method auto h=127.0.0.1,u=root,p=${MYSQL_PASSWORD},D=db1,t=t1

ਟੇਬਲਾਂ ਨੂੰ ਇਸ ਤੱਥ ਦੇ ਕਾਰਨ ਲੰਬੇ ਤਾਲੇ ਦੇ ਬਿਨਾਂ ਅਪਡੇਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਕਿ ਉਪਯੋਗਤਾ ਇੱਕ ਨਵੀਂ ਅਸਥਾਈ ਸਾਰਣੀ ਬਣਾਉਂਦੀ ਹੈ ਜਿਸ ਵਿੱਚ ਇਹ ਮੁੱਖ ਸਾਰਣੀ ਤੋਂ ਡੇਟਾ ਦੀ ਨਕਲ ਕਰਦੀ ਹੈ। ਇਸ ਸਮੇਂ ਜਦੋਂ ਦੋਵੇਂ ਟੇਬਲ ਇੱਕੋ ਜਿਹੇ ਹਨ, ਅਸਲ ਟੇਬਲ ਨੂੰ ਤਾਲਾਬੰਦ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਨਵੀਂ ਨਾਲ ਬਦਲ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ। ਸਾਡੇ ਕੇਸ ਵਿੱਚ, ਇੱਕ ਟੈਸਟ ਰਨ ਨੇ ਦਿਖਾਇਆ ਕਿ ਸਾਰੀਆਂ ਟੇਬਲਾਂ ਨੂੰ ਅੱਪਡੇਟ ਕਰਨ ਵਿੱਚ ਲਗਭਗ ਇੱਕ ਦਿਨ ਲੱਗੇਗਾ, ਪਰ ਡਾਟਾ ਕਾਪੀ ਕਰਨ ਨਾਲ ਡਿਸਕਾਂ ਉੱਤੇ ਬਹੁਤ ਜ਼ਿਆਦਾ ਲੋਡ ਹੋ ਗਿਆ ਹੈ।

ਇਸ ਤੋਂ ਬਚਣ ਲਈ, ਉਤਪਾਦਨ ਵਿੱਚ ਅਸੀਂ ਆਰਗੂਮੈਂਟ ਨੂੰ ਕਮਾਂਡ ਵਿੱਚ ਜੋੜਿਆ ਹੈ --sleep 10 ਦੇ ਮੁੱਲ ਦੇ ਨਾਲ - ਇਹ ਪੈਰਾਮੀਟਰ ਇੱਕ ਨਵੀਂ ਸਾਰਣੀ ਵਿੱਚ ਡੇਟਾ ਦੇ ਬੈਚ ਨੂੰ ਟ੍ਰਾਂਸਫਰ ਕਰਨ ਤੋਂ ਬਾਅਦ ਉਡੀਕ ਦੀ ਲੰਬਾਈ ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਉਂਦਾ ਹੈ। ਇਸ ਤਰ੍ਹਾਂ ਤੁਸੀਂ ਲੋਡ ਨੂੰ ਘਟਾ ਸਕਦੇ ਹੋ ਜੇਕਰ ਅਸਲ ਚੱਲ ਰਹੀ ਐਪਲੀਕੇਸ਼ਨ ਜਵਾਬ ਸਮੇਂ ਦੀ ਮੰਗ ਕਰ ਰਹੀ ਹੈ।

ਓਪਟੀਮਾਈਜੇਸ਼ਨ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਅੱਪਡੇਟ ਸਫਲ ਰਿਹਾ।

... ਪਰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਨਹੀਂ!

ਅੱਪਡੇਟ ਤੋਂ ਅੱਧੇ ਘੰਟੇ ਦੇ ਅੰਦਰ, ਕਲਾਇੰਟ ਇੱਕ ਸਮੱਸਿਆ ਨਾਲ ਆਇਆ। ਡੇਟਾਬੇਸ ਨੇ ਬਹੁਤ ਅਜੀਬ ਢੰਗ ਨਾਲ ਕੰਮ ਕੀਤਾ: ਸਮੇਂ-ਸਮੇਂ ਤੇ ਉਹਨਾਂ ਨੇ ਸ਼ੁਰੂ ਕੀਤਾ ਕੁਨੈਕਸ਼ਨ ਰੀਸੈੱਟ. ਇਹ ਉਹ ਹੈ ਜੋ ਨਿਗਰਾਨੀ ਵਿੱਚ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ:

ਸਕ੍ਰੀਨਸ਼ੌਟ ਇਸ ਤੱਥ ਦੇ ਕਾਰਨ ਇੱਕ ਆਰਾ-ਟੂਥ ਗ੍ਰਾਫ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਕੁਝ MySQL ਸਰਵਰ ਥ੍ਰੈੱਡ ਸਮੇਂ-ਸਮੇਂ 'ਤੇ ਇੱਕ ਗਲਤੀ ਨਾਲ ਕਰੈਸ਼ ਹੋ ਜਾਂਦੇ ਹਨ। ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ ਗਲਤੀਆਂ ਦਿਖਾਈ ਦਿੱਤੀਆਂ:

[PDOException] SQLSTATE[HY000] [2002] Connection refused

ਲਾਗਾਂ ਦੀ ਇੱਕ ਤੇਜ਼ ਜਾਂਚ ਤੋਂ ਪਤਾ ਚੱਲਦਾ ਹੈ ਕਿ mysqld ਡੈਮਨ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਤੋਂ ਲੋੜੀਂਦੇ ਸਰੋਤ ਪ੍ਰਾਪਤ ਨਹੀਂ ਕਰ ਸਕਿਆ ਹੈ। ਤਰੁੱਟੀਆਂ ਨੂੰ ਛਾਂਟਦੇ ਹੋਏ, ਅਸੀਂ ਸਿਸਟਮ ਵਿੱਚ ਖੋਜਿਆ "ਅਨਾਥ" ਐਪਰਮਰ ਪਾਲਿਸੀ ਫਾਈਲਾਂ:

# dpkg -S /etc/apparmor.d/cache/usr.sbin.mysqld
dpkg-query: no path found matching pattern /etc/apparmor.d/cache/usr.sbin.mysqld
# dpkg -S /etc/apparmor.d/local/usr.sbin.mysqld
dpkg-query: no path found matching pattern /etc/apparmor.d/local/usr.sbin.mysqld
# dpkg -S /etc/apparmor.d/usr.sbin.mysqld
mysql-server-5.7: /etc/apparmor.d/usr.sbin.mysqld
# dpkg -l mysql-server-5.7
rc  mysql-server-5.7 5.7.23-0ubuntu0.16.04.1      amd64

ਇਹ ਫਾਈਲਾਂ ਕੁਝ ਸਾਲ ਪਹਿਲਾਂ MySQL 5.7 ਵਿੱਚ ਅੱਪਗਰੇਡ ਕਰਨ ਵੇਲੇ ਬਣਾਈਆਂ ਗਈਆਂ ਸਨ ਅਤੇ ਇੱਕ ਹਟਾਏ ਗਏ ਪੈਕੇਜ ਨਾਲ ਸਬੰਧਤ ਹਨ। ਫਾਈਲਾਂ ਨੂੰ ਮਿਟਾਉਣ ਅਤੇ ਐਪਰਮਰ ਸੇਵਾ ਨੂੰ ਮੁੜ ਚਾਲੂ ਕਰਨ ਨਾਲ ਸਮੱਸਿਆ ਹੱਲ ਹੋ ਗਈ:

systemctl stop apparmor
rm /etc/apparmor.d/cache/usr.sbin.mysqld
rm /etc/apparmor.d/local/usr.sbin.mysqld
rm /etc/apparmor.d/usr.sbin.mysqld
systemctl start apparmor

ਅੰਤ ਵਿੱਚ

ਕੋਈ ਵੀ, ਇੱਥੋਂ ਤੱਕ ਕਿ ਸਭ ਤੋਂ ਸਧਾਰਨ ਓਪਰੇਸ਼ਨ, ਅਚਾਨਕ ਸਮੱਸਿਆਵਾਂ ਦਾ ਕਾਰਨ ਬਣ ਸਕਦਾ ਹੈ. ਅਤੇ ਇੱਥੋਂ ਤੱਕ ਕਿ ਇੱਕ ਚੰਗੀ ਤਰ੍ਹਾਂ ਸੋਚੀ-ਸਮਝੀ ਯੋਜਨਾ ਹੋਣ ਨਾਲ ਹਮੇਸ਼ਾ ਉਮੀਦ ਕੀਤੇ ਨਤੀਜੇ ਦੀ ਗਰੰਟੀ ਨਹੀਂ ਹੁੰਦੀ। ਹੁਣ, ਸਾਡੀ ਟੀਮ ਦੀ ਕੋਈ ਵੀ ਅੱਪਡੇਟ ਯੋਜਨਾਵਾਂ ਵਿੱਚ ਬੇਲੋੜੀਆਂ ਫਾਈਲਾਂ ਦੀ ਲਾਜ਼ਮੀ ਸਫਾਈ ਵੀ ਸ਼ਾਮਲ ਹੈ ਜੋ ਹਾਲੀਆ ਕਾਰਵਾਈਆਂ ਦੇ ਨਤੀਜੇ ਵਜੋਂ ਪ੍ਰਗਟ ਹੋ ਸਕਦੀਆਂ ਹਨ।

ਅਤੇ ਇਸ ਬਹੁਤ ਪੇਸ਼ੇਵਰ ਗ੍ਰਾਫਿਕ ਰਚਨਾਤਮਕਤਾ ਦੇ ਨਾਲ, ਮੈਂ ਪਰਕੋਨਾ ਨੂੰ ਉਹਨਾਂ ਦੇ ਸ਼ਾਨਦਾਰ ਉਤਪਾਦਾਂ ਲਈ ਬਹੁਤ ਧੰਨਵਾਦ ਕਹਿਣਾ ਚਾਹਾਂਗਾ!

PS

ਸਾਡੇ ਬਲੌਗ 'ਤੇ ਵੀ ਪੜ੍ਹੋ:

• «ਡਾਟਾਬੇਸ ਅਤੇ ਕੁਬਰਨੇਟਸ (ਸਮੀਖਿਆ ਅਤੇ ਵੀਡੀਓ ਰਿਪੋਰਟ)";
• «ਕੁਬਰਨੇਟਸ ਟਿਪਸ ਅਤੇ ਟ੍ਰਿਕਸ: ਵੱਡੇ ਡੇਟਾਬੇਸ ਲਈ ਬੂਟਸਟਰੈਪ ਨੂੰ ਤੇਜ਼ ਕਰਨਾ";
• «ਸਾਡੇ SRE ਰੋਜ਼ਾਨਾ ਜੀਵਨ ਤੋਂ 6 ਵਿਹਾਰਕ ਕਹਾਣੀਆਂ";
• «K8s ਵਿੱਚ Redis ਆਪਰੇਟਰ ਦੇ ਨਾਲ ਇੱਕ ਕਹਾਣੀ ਅਤੇ ਇਸ ਡੇਟਾਬੇਸ ਤੋਂ ਡੇਟਾ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਨ ਲਈ ਉਪਯੋਗਤਾਵਾਂ ਦੀ ਇੱਕ ਛੋਟੀ-ਸਮੀਖਿਆ";
• «ਮੋਂਗੋਡੀਬੀ ਦਾ ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਸਹਿਜ ਪ੍ਰਵਾਸ".

ਸਰੋਤ: www.habr.com