VPN ਕੱਟਣ ਤੋਂ ਬਾਅਦ MySQL ਨਕਲ: ਪਹਿਲਾਂ ਦੋਵੇਂ ਪੜਾਅ ਪੜ੍ਹੋ

VPN ਡਿੱਗਣ 'ਤੇ ਨਕਲ ਦੀ ਨਿਗਰਾਨੀ ਲਾਲ ਹੋ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਪਹਿਲੀ ਪ੍ਰਵਿਰਤੀ ਸਥਿਤੀ ਰੀਸੈਟ ਕਰਨ ਦੀ ਹੁੰਦੀ ਹੈ। ਇਹੀ ਪ੍ਰਵਿਰਤੀ ਨੈੱਟਵਰਕ ਰੁਕਾਵਟ ਨੂੰ ਡੇਟਾ ਸਮੱਸਿਆ ਵਿੱਚ ਬਦਲਦੀ ਹੈ। ਡਿੱਗਿਆ ਰਾਹ ਇਸ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ ਕਿ ਨਕਲ ਨੇ ਕੀ ਪ੍ਰਾਪਤ ਕੀਤਾ ਜਾਂ ਕੀ ਲਾਗੂ ਕੀਤਾ, ਅਤੇ ਇਹ ਦੋ ਅਵਸਥਾਵਾਂ ਵਾਲੇ ਦੋ ਪੜਾਅ ਹਨ। ਕੁਝ ਵੀ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਇਨ੍ਹਾਂ ਨੂੰ ਵੱਖਰੇ ਪੜ੍ਹੋ।

ਦੋ ਪੜਾਅ, ਦੋ ਵੱਖਰੇ ਜਵਾਬ

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

ਪ੍ਰਾਪਤਕਰਤਾ ਦਾ ਠੀਕ ਹੋਣਾ ਦੱਸਦਾ ਹੈ ਕਿ ਰਾਹ ਚਾਲੂ ਹੈ। ਇਹ ਨਹੀਂ ਦੱਸਦਾ ਕਿ ਲਾਗੂਕਰਤਾ ਕਿੰਨਾ ਪਿੱਛੇ ਹੈ, ਜਾਂ ਡਿਸਕਨੈਕਟ ਰਹਿੰਦਿਆਂ ਉਸ ਨੂੰ ਕੋਈ ਗਲਤੀ ਮਿਲੀ ਜਾਂ ਨਹੀਂ।

ਸਹੀ ਬਿਆਨ ਨਾਲ ਚੈਨਲ ਪੜ੍ਹੋ

MySQL 8.4 ਵਿੱਚ, SHOW REPLICA STATUS ਹਰ ਸੰਰਚਿਤ ਚੈਨਲ ਲਈ ਇੱਕ ਕਤਾਰ ਵਾਪਸ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਸੂਚੀ ਦੀ ਪਹਿਲੀ ਕਤਾਰ ਦੀ ਬਜਾਏ ਤੁਹਾਡੇ ਭਾਵਿਤ ਚੈਨਲ ਦੀ ਕਤਾਰ ਪੜ੍ਹੋ। Replica_IO_Running ਜੁੜੇ ਪ੍ਰਾਪਤਕਰਤਾ ਨੂੰ ਜੁੜ ਰਹੇ ਜਾਂ ਰੁਕੇ ਪ੍ਰਾਪਤਕਰਤਾ ਤੋਂ ਵੱਖ ਕਰਦਾ ਹੈ, ਅਤੇ Replica_SQL_Running ਲਾਗੂਕਰਤਾ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ। ਉਨ੍ਹਾਂ ਦੇ ਨਾਲ ਵਾਲੇ ਗਲਤੀ ਕਾਲਮ ਵੀ ਪੜ੍ਹੋ, ਕਿਉਂਕਿ ਦੁਬਾਰਾ ਜੁੜ ਕੇ ਤੁਰੰਤ ਅਸਫਲ ਹੋਣ ਵਾਲਾ ਪ੍ਰਾਪਤਕਰਤਾ ਅਜਿਹਾ ਸੁਨੇਹਾ ਛੱਡਦਾ ਹੈ ਜੋ ਕੋਈ ਸਥਿਤੀ ਝੰਡਾ ਨਹੀਂ ਦਿਖਾਏਗਾ। ਪੁਰਾਣੇ ਸੰਸਕਰਣ ਵੱਖਰੇ ਕਾਲਮ ਨਾਮ ਵਰਤਦੇ ਹਨ, ਇਸ ਲਈ ਸਿਰਫ਼ ਹੁਕਮਾਂ ਦੇ ਨਾਮ ਬਦਲ ਕੇ ਪੁਰਾਣੀ ਵਿਧੀ ਦਾ ਅਨੁਵਾਦ ਨਾ ਕਰੋ।

ਸਰੋਤ ਦੀ ਪਛਾਣ ਅਤੇ ਸੰਰਚਿਤ ਫਿਲਟਰ ਵੀ ਜਾਂਚੋ। ਗਲਤ ਸਰੋਤ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੀ, ਜਾਂ ਤੁਹਾਡੀ ਸੋਚ ਨਾਲੋਂ ਤੰਗ ਫਿਲਟਰ ਕੀਤੀ ਨਕਲ ਸਿਹਤਮੰਦ ਹੋਣ ਦੀ ਰਿਪੋਰਟ ਦਿੰਦੀ ਹੈ, ਜਦੋਂ ਕਿ ਉਹ ਤੁਹਾਡੀ ਉਮੀਦ ਨਾਲੋਂ ਵੱਖਰਾ ਕੁਝ ਨਕਲ ਕਰ ਰਹੀ ਹੁੰਦੀ ਹੈ।

ਸਿਫ਼ਰ ਦੇਰੀ ਦਾ ਅੰਕ ਝੂਠ ਕਿਉਂ ਬੋਲ ਸਕਦਾ ਹੈ

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

ਇਸ ਦੀ ਬਜਾਏ ਚਲਾਏ ਗਏ ਲੈਣ-ਦੇਣ ਦੀ ਸਰੋਤ ਕੋਲ ਉਪਲਬਧ ਨਾਲ ਤੁਲਨਾ ਕਰੋ। ਉਹ ਤੁਲਨਾ ਰੁਕੇ ਪ੍ਰਾਪਤਕਰਤਾ ਵਿੱਚ ਵੀ ਟਿਕੀ ਰਹਿੰਦੀ ਹੈ।

ਅਸਲ ਬਹਾਲੀ ਦੀ ਖਿੜਕੀ ਧਾਰਨਾ ਤੈਅ ਕਰਦੀ ਹੈ

ਪਕੜਨ ਲਈ ਜ਼ਰੂਰੀ ਹੈ ਕਿ ਸਰੋਤ ਨਕਲ ਨੂੰ ਲੋੜੀਂਦੇ ਲੈਣ-ਦੇਣ ਅਜੇ ਵੀ ਰੱਖੇ। ਉਹ ਸਾਫ਼ ਹੋਣ ਤੋਂ ਬਾਅਦ ਨਕਲ ਉਨ੍ਹਾਂ ਨੂੰ ਲਿਆ ਨਹੀਂ ਸਕਦੀ, ਅਤੇ ਕਿੰਨੀ ਵੀ ਦੁਬਾਰਾ ਜੁੜਨਾ ਇਸ ਨੂੰ ਨਹੀਂ ਬਦਲਦਾ।

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

ਸੂਚਕ ਦਾ ਰੰਗ ਨਹੀਂ, ਪਕੜਿਆ ਹੋਣਾ ਪ੍ਰਮਾਣਿਤ ਕਰੋ

ਰਾਹ ਬਹਾਲ ਕਰੋ, ਜਿਸ ਵਿੱਚ ਨਾਮ ਹੱਲ ਅਤੇ ਆਵਾਜਾਈ ਸੁਰੱਖਿਆ ਸ਼ਾਮਲ ਹੈ, ਫਿਰ ਦੇਖੋ ਕਿ ਮੌਜੂਦਾ ਚੈਨਲ ਆਪਣੀ ਨੀਤੀ ਅਨੁਸਾਰ ਦੁਬਾਰਾ ਜੁੜਦਾ ਹੈ ਜਾਂ ਨਹੀਂ। ਦਖਲ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ ਇਸ ਨੂੰ ਨਿਸ਼ਚਿਤ ਅੰਤਰਾਲ ਦਿਓ, ਅਤੇ ਉਸ ਅੰਤਰਾਲ ਦੇ ਦੋਵੇਂ ਸਿਰਿਆਂ 'ਤੇ ਪ੍ਰਾਪਤੀ ਅਤੇ ਲਾਗੂ ਦੀ ਤਰੱਕੀ ਦਰਜ ਕਰੋ। ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਹੋਣ ਵਾਲਾ ਚੈਨਲ ਅਤੇ ਅਦਿਆਤਨ ਚੈਨਲ ਵੱਖਰੇ ਨਤੀਜੇ ਹਨ।

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