ਅਲਰਟ ਜੋ ਹਰ ਸਰਵਰ ਲਈ ਨਹੀਂ, ਸਿਰਫ਼ ਇੱਕ ਵਾਰ ਚੱਲਣ

ਸਾਡਾ ਇੱਕ ਓਪਰੇਸ਼ਨਲ ਅਲਰਟ, ਇੱਕ ਬਿਲਡਰ ਦੀ ਪਬਲਿਸ਼ ਕੀਤੀ ਐਪ ਲਈ "low credits", ਸਾਡੇ ਤੱਕ ਵੱਧ ਤੋਂ ਵੱਧ ਇੱਕ ਵਾਰ ਰੋਜ਼ ਪਹੁੰਚਣਾ ਚਾਹੀਦਾ ਹੈ। ਇੱਕ ਦੁਪਹਿਰ ਇਹ ਪੰਜ ਵਾਰ ਆਇਆ। ਕਾਰਨ ਇਹ ਸੀ: ਸਾਡੇ API ਦੀ ਹਰ ਕਾਪੀ ਆਪਣੀ ਮੈਮੋਰੀ ਵਿੱਚ ਯਾਦ ਰੱਖਦੀ ਸੀ ਕਿ ਉਸਨੇ ਕਿਹੜੇ ਅਲਰਟ ਭੇਜੇ ਹਨ, ਇਸ ਲਈ ਦੋ ਸਰਵਰਾਂ ਨੇ ਇਹ ਦੋ ਵਾਰ ਭੇਜਿਆ, ਅਤੇ ਹਰ ਡਿਪਲੌਏ ਉਸ ਮੈਮੋਰੀ ਨੂੰ ਮਿਟਾ ਕੇ ਦੁਬਾਰਾ ਭੇਜਣ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਸੀ। ਇਹੀ ਪੈਟਰਨ ਇੱਕ ਪਿਛੋਕੜ ਜੌਬ ਵਿੱਚ ਵੀ ਸੀ ਜੋ ਆਪਣਾ ਕੰਮ ਦੋ ਵਾਰ ਕਰ ਰਿਹਾ ਸੀ। ਹੁਣ ਦੋਵੇਂ ਇੱਕ ਸਾਂਝੇ ਸਟੋਰ ਰਾਹੀਂ ਤਾਲਮੇਲ ਕਰਦੇ ਹਨ, ਅਤੇ ਜੇ ਉਹ ਸਟੋਰ ਉਪਲਬਧ ਨਾ ਹੋਵੇ ਤਾਂ ਦੋਵੇਂ ਸੁਰੱਖਿਅਤ ਪਾਸੇ ਵੱਲ ਫ਼ੇਲ੍ਹ ਹੁੰਦੇ ਹਨ।

ਲੱਛਣ

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

ਇੱਕ ਦੁਪਹਿਰ ਵਿੱਚ ਇੱਕੋ ਅਲਰਟ ਦੀਆਂ ਪੰਜ ਕਾਪੀਆਂ ਦਾ ਮਤਲਬ ਸੀ ਕਿ ਇਹ ਵਿੰਡੋ ਕੰਮ ਨਹੀਂ ਕਰ ਰਹੀ ਸੀ। ਹੋਰ ਵੀ ਮਾੜਾ, ਇਹ ਜੋੜਿਆਂ ਵਿੱਚ ਆਏ, ਲਗਭਗ 11 ਮਿੰਟ ਦੇ ਫ਼ਰਕ ਨਾਲ।

ਇਹ ਕਿਉਂ ਹੋਇਆ

ਸਾਡੇ ਅਲਰਟ ਪੈਕੇਜ ਨੇ ਆਪਣੀ ਡੀਡੁਪ ਮੈਮੋਰੀ ਵਿੱਚ ਰੱਖੀ ਸੀ: "ਅਲਰਟ ਕੀ → ਆਖਰੀ ਵਾਰ ਕਦੋਂ ਭੇਜਿਆ" ਦੀ ਇੱਕ ਟੇਬਲ, ਚੱਲ ਰਹੀ ਪ੍ਰਕਿਰਿਆ ਦੇ ਅੰਦਰ। ਇਹ ਉਸ ਸਮੇਂ ਠੀਕ ਚੱਲਦਾ ਹੈ ਜਦੋਂ ਇੱਕ ਹੀ ਪ੍ਰਕਿਰਿਆ ਹੋਵੇ ਜੋ ਕਦੇ ਰੀਸਟਾਰਟ ਨਾ ਹੋਵੇ। ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਨਾ ਇੱਕ ਪ੍ਰਕਿਰਿਆ ਹੈ ਨਾ ਹੀ ਇਹ ਰੀਸਟਾਰਟ ਨਹੀਂ ਹੁੰਦੀ:

• ਦੋ API ਰਿਪਲੀਕਾ। ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ API ਦੀਆਂ ਦੋ ਕਾਪੀਆਂ ਚੱਲਦੀਆਂ ਹਨ। ਹਰੇਕ ਦੀ ਆਪਣੀ ਟੇਬਲ ਸੀ, ਇਸ ਲਈ ਹਰੇਕ ਨੇ ਅਲਰਟ ਇੱਕ ਵਾਰ ਭੇਜਿਆ। ਇਹੀ ਜੋੜੇ ਸਨ।
• ਡਿਪਲੌਏ। ਹਰ ਡਿਪਲੌਏ ਦੋਵੇਂ ਰਿਪਲੀਕਾ ਨੂੰ ਨਵੀਆਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਅਤੇ ਖਾਲੀ ਟੇਬਲਾਂ ਨਾਲ ਬਦਲਦਾ ਹੈ। ਡਿਪਲੌਏ ਤੋਂ ਬਾਅਦ ਅਲਰਟ ਫਿਰ ਜਾਂਦਾ ਸੀ, ਜਿਵੇਂ ਇਹ ਕਦੇ ਭੇਜਿਆ ਹੀ ਨਾ ਗਿਆ ਹੋਵੇ।

ਹਰ ਜੋੜੇ ਦੇ ਦੋ ਅਲਰਟਾਂ ਵਿਚਕਾਰ ਲਗਭਗ 11 ਮਿੰਟ ਦਾ ਫ਼ਰਕ ਉਸ ਜੌਬ ਤੋਂ ਆਇਆ ਜੋ ਇਹ ਅਲਰਟ ਉਠਾਉਂਦੀ ਹੈ। ਇਹ ਦੋਵੇਂ ਰਿਪਲੀਕਾ 'ਤੇ ਚੱਲਦੀ ਹੈ ਅਤੇ ਇੱਕ ਲਾਕ ਲੈਂਦੀ ਹੈ, ਇਸ ਲਈ ਰਿਪਲੀਕਾ ਵਾਰੀ-ਵਾਰੀ ਜਿੱਤਦੇ ਹਨ, ਅਤੇ ਹਰ ਇੱਕ ਆਪਣੀ ਵਾਰੀ ਆਉਣ 'ਤੇ ਅਲਰਟ ਉਠਾਉਂਦਾ ਸੀ।

ਇਸੇ ਕੋਡ ਵਿੱਚ ਇੱਕ ਦੂਜਾ, ਚੁੱਪ ਬੱਗ ਵੀ ਸੀ। ਟੇਬਲ ਨੂੰ ਅਨੰਤ ਵਧਣ ਤੋਂ ਰੋਕਣ ਲਈ, ਇਹ ਆਪਣੇ ਆਪ ਨੂੰ ਉਦੋਂ ਸਾਫ਼ ਕਰਦੀ ਸੀ ਜਦੋਂ ਇਸ ਵਿੱਚ 500 ਕੁੰਜੀਆਂ ਹੋ ਜਾਂਦੀਆਂ ਸਨ: ਹਰ ਉਹ ਐਂਟਰੀ ਮਿਟਾ ਦਿੰਦੀ ਸੀ ਜੋ 15 ਮਿੰਟ ਤੋਂ ਪੁਰਾਣੀ ਸੀ, ਉਸਦੀ ਵਿੰਡੋ ਜੋ ਵੀ ਹੋਵੇ। ਭਾਰ ਹੇਠ, 24 ਘੰਟਿਆਂ ਦੀ ਡੀਡੁਪ ਸਿਰਫ਼ ਇੱਕ ਚੌਥਾਈ ਘੰਟਾ ਟਿਕ ਸਕਦੀ ਸੀ।

ਹੱਲ

ਹਰ ਅਲਰਟ ਲਈ ਇੱਕ ਸਾਂਝਾ ਰਿਕਾਰਡ

ਹੁਣ API ਅਲਰਟ ਭੇਜਣ ਤੋਂ ਪਹਿਲਾਂ ਉਸਦੀ ਡੀਡੁਪ ਕੁੰਜੀ Redis ਵਿੱਚ ਦਾਅਵਾ ਕਰਦੀ ਹੈ। Redis ਇੱਕ ਸਾਂਝਾ ਇਨ-ਮੈਮੋਰੀ ਸਟੋਰ ਹੈ ਜਿਸ ਨਾਲ ਦੋਵੇਂ ਰਿਪਲੀਕਾ ਗੱਲ ਕਰਦੇ ਹਨ ਅਤੇ ਜੋ API ਦੇ ਰੀਸਟਾਰਟ ਨਾਲ ਨਹੀਂ ਮਿਟਦਾ। ਦਾਅਵਾ ਇੱਕ ਹੀ ਓਪਰੇਸ਼ਨ ਹੈ: "ਇਹ ਕੁੰਜੀ ਸਿਰਫ਼ ਉਦੋਂ ਸੈੱਟ ਕਰੋ ਜਦੋਂ ਇਹ ਮੌਜੂਦ ਨਾ ਹੋਵੇ, ਅਤੇ ਵਿੰਡੋ ਤੋਂ ਬਾਅਦ ਇਸਨੂੰ ਮਿਆਦ ਪੁੱਗਣ ਦਿਓ।" ਜੋ ਰਿਪਲੀਕਾ ਪਹਿਲਾਂ ਦਾਅਵਾ ਕਰਦਾ ਹੈ, ਉਹ ਅਲਰਟ ਭੇਜਦਾ ਹੈ; ਦੂਜਾ ਕੁੰਜੀ ਲਈ ਹੋਈ ਵੇਖਦਾ ਹੈ ਅਤੇ ਚੁੱਪ ਰਹਿੰਦਾ ਹੈ। ਡਿਪਲੌਏ ਤੋਂ ਬਾਅਦ ਦੀ ਨਵੀਂ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਕੁੰਜੀ ਅਜੇ ਵੀ ਮਿਲਦੀ ਹੈ।

ਕੁੰਜੀ ਅਤੇ ਵਿੰਡੋ ਉਸੇ ਨਿਯਮ ਤੋਂ ਆਉਂਦੇ ਹਨ ਜੋ ਅਲਰਟ ਪੈਕੇਜ ਵਰਤਦਾ ਹੈ, ਹੁਣ ਦੋਵਾਂ ਪਰਤਾਂ ਵਿਚਕਾਰ ਸਾਂਝਾ, ਤਾਂ ਜੋ ਉਹ ਇਸ ਬਾਰੇ ਅਸਹਿਮਤ ਨਾ ਹੋਣ ਕਿ "ਉਹੀ ਅਲਰਟ" ਕੀ ਹੈ।

ਖੁੱਲ੍ਹਾ ਫ਼ੇਲ੍ਹ ਹੋਣਾ, ਬੰਦ ਨਹੀਂ

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

ਸਭ ਤੋਂ ਗੰਭੀਰ ਅਲਰਟ, P0, ਡੀਡੁਪ ਨਾਲ ਕਦੇ ਰੋਕੇ ਹੀ ਨਹੀਂ ਜਾਂਦੇ।

ਹਰ ਐਂਟਰੀ ਆਪਣੀ ਵਿੰਡੋ ਰੱਖਦੀ ਹੈ

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

ਉਹੀ ਬੱਗ, ਕਿਤੇ ਹੋਰ

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

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

ਅਸੀਂ ਇਸਨੂੰ ਕਿਵੇਂ ਟੈਸਟ ਕੀਤਾ

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

ਰੀਕਨਸਿਲੀਏਸ਼ਨ ਜੌਬ ਲਈ, ਦੋ ਰਿਪਲੀਕਾ ਇੱਕੋ ਸਮੇਂ ਟਿਕ ਕਰਦੇ ਹਨ, ਨਾਲ ਉਸੇ ਵਿੰਡੋ ਵਿੱਚ ਤੀਜਾ ਟਿਕ, ਅਤੇ ਨਤੀਜਾ ਇੱਕ ਹੀ ਲਿਸਟਿੰਗ ਹੈ।

ਅਸੀਂ ਇਸ ਤੋਂ ਕੀ ਸਿੱਖਿਆ

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

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