Elasticsearch ਕਲੱਸਟਰ 200 TB+

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

ਅਸੀਂ Odnoklassniki ਵਿਖੇ ਲੌਗ ਪ੍ਰਬੰਧਨ ਦੇ ਮੁੱਦੇ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ elasticsearch ਦੀ ਵਰਤੋਂ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਹੈ, ਅਤੇ ਹੁਣ ਅਸੀਂ Habr ਨਾਲ ਆਪਣਾ ਅਨੁਭਵ ਸਾਂਝਾ ਕਰਦੇ ਹਾਂ: ਆਰਕੀਟੈਕਚਰ ਅਤੇ ਖਰਾਬੀਆਂ ਬਾਰੇ।

ਮੈਂ ਪਯੋਟਰ ਜ਼ੈਤਸੇਵ ਹਾਂ, ਮੈਂ ਓਡਨੋਕਲਾਸਨੀਕੀ ਵਿੱਚ ਇੱਕ ਸਿਸਟਮ ਪ੍ਰਸ਼ਾਸਕ ਵਜੋਂ ਕੰਮ ਕਰਦਾ ਹਾਂ। ਇਸ ਤੋਂ ਪਹਿਲਾਂ, ਮੈਂ ਇੱਕ ਐਡਮਿਨ ਵੀ ਸੀ, ਮੈਂਟੀਕੋਰ ਖੋਜ, ਸਪਿੰਕਸ ਖੋਜ, ਇਲਾਸਟਿਕ ਖੋਜ ਨਾਲ ਕੰਮ ਕੀਤਾ. ਸ਼ਾਇਦ, ਜੇਕਰ ਕੋਈ ਹੋਰ ... ਖੋਜ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ, ਤਾਂ ਮੈਂ ਸ਼ਾਇਦ ਇਸਦੇ ਨਾਲ ਵੀ ਕੰਮ ਕਰਾਂਗਾ। ਮੈਂ ਸਵੈਇੱਛਤ ਆਧਾਰ 'ਤੇ ਕਈ ਓਪਨ ਸੋਰਸ ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚ ਵੀ ਹਿੱਸਾ ਲੈਂਦਾ ਹਾਂ।

ਜਦੋਂ ਮੈਂ ਓਡਨੋਕਲਾਸਨੀਕੀ ਆਇਆ, ਤਾਂ ਮੈਂ ਇੰਟਰਵਿਊ 'ਤੇ ਲਾਪਰਵਾਹੀ ਨਾਲ ਕਿਹਾ ਕਿ ਮੈਂ Elasticsearch ਨਾਲ ਕੰਮ ਕਰ ਸਕਦਾ ਹਾਂ. ਜਦੋਂ ਮੈਂ ਇਸਨੂੰ ਲਟਕ ਗਿਆ ਅਤੇ ਕੁਝ ਸਧਾਰਨ ਕਾਰਜਾਂ ਨੂੰ ਪੂਰਾ ਕੀਤਾ, ਮੈਨੂੰ ਉਸ ਸਮੇਂ ਮੌਜੂਦ ਲੌਗ ਪ੍ਰਬੰਧਨ ਪ੍ਰਣਾਲੀ ਨੂੰ ਸੁਧਾਰਨ ਦਾ ਵੱਡਾ ਕੰਮ ਸੌਂਪਿਆ ਗਿਆ।

ਲੋੜ

ਸਿਸਟਮ ਲੋੜਾਂ ਨੂੰ ਹੇਠ ਲਿਖੇ ਅਨੁਸਾਰ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਸੀ:

• ਗ੍ਰੇਲੌਗ ਨੂੰ ਫਰੰਟਐਂਡ ਵਜੋਂ ਵਰਤਿਆ ਜਾਣਾ ਸੀ। ਕਿਉਂਕਿ ਕੰਪਨੀ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਇਸ ਉਤਪਾਦ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦਾ ਤਜਰਬਾ ਸੀ, ਪ੍ਰੋਗਰਾਮਰ ਅਤੇ ਟੈਸਟਰ ਇਸ ਨੂੰ ਜਾਣਦੇ ਸਨ, ਇਹ ਉਹਨਾਂ ਲਈ ਜਾਣੂ ਅਤੇ ਸੁਵਿਧਾਜਨਕ ਸੀ।
• ਡਾਟਾ ਵਾਲੀਅਮ: ਔਸਤਨ 50-80 ਹਜ਼ਾਰ ਸੁਨੇਹੇ ਪ੍ਰਤੀ ਸਕਿੰਟ, ਪਰ ਜੇ ਕੋਈ ਚੀਜ਼ ਟੁੱਟ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਆਵਾਜਾਈ ਕਿਸੇ ਵੀ ਚੀਜ਼ ਦੁਆਰਾ ਸੀਮਿਤ ਨਹੀਂ ਹੁੰਦੀ, ਇਹ ਪ੍ਰਤੀ ਸਕਿੰਟ 2-3 ਮਿਲੀਅਨ ਲਾਈਨਾਂ ਹੋ ਸਕਦੀ ਹੈ
• ਗਾਹਕਾਂ ਨਾਲ ਖੋਜ ਪ੍ਰਸ਼ਨਾਂ ਦੀ ਪ੍ਰਕਿਰਿਆ ਦੀ ਗਤੀ ਲਈ ਲੋੜਾਂ ਬਾਰੇ ਚਰਚਾ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਅਸੀਂ ਮਹਿਸੂਸ ਕੀਤਾ ਕਿ ਅਜਿਹੀ ਪ੍ਰਣਾਲੀ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦਾ ਖਾਸ ਨਮੂਨਾ ਇਹ ਹੈ: ਲੋਕ ਪਿਛਲੇ ਦੋ ਦਿਨਾਂ ਤੋਂ ਆਪਣੀ ਅਰਜ਼ੀ ਦੇ ਲੌਗਸ ਦੀ ਭਾਲ ਕਰ ਰਹੇ ਹਨ ਅਤੇ ਇੱਕ ਤੋਂ ਵੱਧ ਉਡੀਕ ਨਹੀਂ ਕਰਨਾ ਚਾਹੁੰਦੇ। ਇੱਕ ਸੂਤਰਬੱਧ ਪੁੱਛਗਿੱਛ ਦੇ ਨਤੀਜੇ ਲਈ ਦੂਜਾ।
• ਪ੍ਰਸ਼ਾਸਕਾਂ ਨੇ ਜ਼ੋਰ ਦੇ ਕੇ ਕਿਹਾ ਕਿ ਜੇ ਲੋੜ ਹੋਵੇ ਤਾਂ ਸਿਸਟਮ ਨੂੰ ਆਸਾਨੀ ਨਾਲ ਸਕੇਲੇਬਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਉਹਨਾਂ ਨੂੰ ਇਹ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ ਇਸ ਬਾਰੇ ਡੂੰਘਾਈ ਨਾਲ ਖੋਜ ਕਰਨ ਦੀ ਲੋੜ ਤੋਂ ਬਿਨਾਂ।
• ਤਾਂ ਜੋ ਇਹਨਾਂ ਸਿਸਟਮਾਂ ਨੂੰ ਸਮੇਂ-ਸਮੇਂ 'ਤੇ ਸਿਰਫ ਰੱਖ-ਰਖਾਅ ਦਾ ਕੰਮ ਕੁਝ ਹਾਰਡਵੇਅਰ ਨੂੰ ਬਦਲਣਾ ਚਾਹੀਦਾ ਹੈ।
• ਇਸ ਤੋਂ ਇਲਾਵਾ, ਓਡਨੋਕਲਾਸਨੀਕੀ ਦੀ ਇੱਕ ਸ਼ਾਨਦਾਰ ਤਕਨੀਕੀ ਪਰੰਪਰਾ ਹੈ: ਕੋਈ ਵੀ ਸੇਵਾ ਜੋ ਅਸੀਂ ਲਾਂਚ ਕਰਦੇ ਹਾਂ, ਇੱਕ ਡਾਟਾ ਸੈਂਟਰ ਅਸਫਲਤਾ (ਅਚਾਨਕ, ਗੈਰ-ਯੋਜਨਾਬੱਧ ਅਤੇ ਬਿਲਕੁਲ ਕਿਸੇ ਵੀ ਸਮੇਂ) ਤੋਂ ਬਚਣਾ ਚਾਹੀਦਾ ਹੈ।

ਇਸ ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਲਾਗੂ ਕਰਨ ਵਿੱਚ ਆਖਰੀ ਲੋੜ ਸਾਨੂੰ ਸਭ ਤੋਂ ਵੱਧ ਖਰਚ ਕਰਦੀ ਹੈ, ਜਿਸ ਬਾਰੇ ਮੈਂ ਹੋਰ ਵਿਸਥਾਰ ਵਿੱਚ ਗੱਲ ਕਰਾਂਗਾ।

ਬੁੱਧਵਾਰ

ਅਸੀਂ ਚਾਰ ਡਾਟਾ ਸੈਂਟਰਾਂ ਵਿੱਚ ਕੰਮ ਕਰਦੇ ਹਾਂ, ਜਦੋਂ ਕਿ Elasticsearch ਡੇਟਾ ਨੋਡ ਸਿਰਫ਼ ਤਿੰਨ ਵਿੱਚ ਸਥਿਤ ਹੋ ਸਕਦੇ ਹਨ (ਕਈ ​​ਗੈਰ-ਤਕਨੀਕੀ ਕਾਰਨਾਂ ਕਰਕੇ)।

ਇਹਨਾਂ ਚਾਰ ਡਾਟਾ ਸੈਂਟਰਾਂ ਵਿੱਚ ਲਗਭਗ 18 ਹਜ਼ਾਰ ਵੱਖ-ਵੱਖ ਲਾਗ ਸਰੋਤ ਹਨ - ਹਾਰਡਵੇਅਰ, ਕੰਟੇਨਰ, ਵਰਚੁਅਲ ਮਸ਼ੀਨਾਂ।

ਮਹੱਤਵਪੂਰਨ ਵਿਸ਼ੇਸ਼ਤਾ: ਕਲੱਸਟਰ ਕੰਟੇਨਰਾਂ ਵਿੱਚ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ ਪੋਡਮੈਨ ਭੌਤਿਕ ਮਸ਼ੀਨਾਂ 'ਤੇ ਨਹੀਂ, ਪਰ ਆਪਣਾ ਕਲਾਊਡ ਉਤਪਾਦ ਇੱਕ-ਕਲਾਊਡ. ਕੰਟੇਨਰਾਂ ਨੂੰ 2 ਕੋਰਾਂ ਦੀ ਗਾਰੰਟੀ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ, 2.0Ghz v4 ਦੇ ਸਮਾਨ, ਬਾਕੀ ਕੋਰਾਂ ਨੂੰ ਰੀਸਾਈਕਲ ਕਰਨ ਦੀ ਸੰਭਾਵਨਾ ਦੇ ਨਾਲ, ਜੇਕਰ ਉਹ ਨਿਸ਼ਕਿਰਿਆ ਹਨ।

ਹੋਰ ਸ਼ਬਦਾਂ ਵਿਚ:

ਟੌਪੋਲੋਜੀ

ਮੈਂ ਸ਼ੁਰੂ ਵਿੱਚ ਹੱਲ ਦਾ ਆਮ ਰੂਪ ਇਸ ਤਰ੍ਹਾਂ ਦੇਖਿਆ:

• 3-4 ਵੀਆਈਪੀ ਗ੍ਰੇਲੌਗ ਡੋਮੇਨ ਦੇ ਏ-ਰਿਕਾਰਡ ਦੇ ਪਿੱਛੇ ਹਨ, ਇਹ ਉਹ ਪਤਾ ਹੈ ਜਿਸ 'ਤੇ ਲੌਗ ਭੇਜੇ ਜਾਂਦੇ ਹਨ।
• ਹਰੇਕ VIP ਇੱਕ LVS ਬੈਲੇਂਸਰ ਹੈ।
• ਇਸ ਤੋਂ ਬਾਅਦ, ਲੌਗਸ ਗ੍ਰੇਲੌਗ ਬੈਟਰੀ ਵਿੱਚ ਜਾਂਦੇ ਹਨ, ਕੁਝ ਡੇਟਾ GELF ਫਾਰਮੈਟ ਵਿੱਚ ਹੁੰਦਾ ਹੈ, ਕੁਝ syslog ਫਾਰਮੈਟ ਵਿੱਚ ਹੁੰਦਾ ਹੈ।
• ਫਿਰ ਇਹ ਸਭ ਇਲਾਸਟਿਕ ਖੋਜ ਕੋਆਰਡੀਨੇਟਰਾਂ ਦੀ ਇੱਕ ਬੈਟਰੀ ਵਿੱਚ ਵੱਡੇ ਬੈਚਾਂ ਵਿੱਚ ਲਿਖਿਆ ਜਾਂਦਾ ਹੈ।
• ਅਤੇ ਉਹ, ਬਦਲੇ ਵਿੱਚ, ਸੰਬੰਧਿਤ ਡੇਟਾ ਨੋਡਾਂ ਨੂੰ ਲਿਖਣ ਅਤੇ ਪੜ੍ਹਨ ਦੀਆਂ ਬੇਨਤੀਆਂ ਭੇਜਦੇ ਹਨ।

ਪਰਿਭਾਸ਼ਾ

ਸ਼ਾਇਦ ਹਰ ਕੋਈ ਵਿਸਥਾਰ ਵਿੱਚ ਸ਼ਬਦਾਵਲੀ ਨੂੰ ਨਹੀਂ ਸਮਝਦਾ, ਇਸ ਲਈ ਮੈਂ ਇਸ 'ਤੇ ਥੋੜਾ ਜਿਹਾ ਧਿਆਨ ਦੇਣਾ ਚਾਹਾਂਗਾ.

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

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

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

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

ਗ੍ਰੇਲੌਗ
ਇਹ ਇੱਕ ELK ਸਟੈਕ ਵਿੱਚ Logstash ਨਾਲ Kibana ਦੇ ਇੱਕ ਫਿਊਜ਼ਨ ਵਰਗਾ ਹੈ। ਗ੍ਰੇਲੌਗ ਇੱਕ UI ਅਤੇ ਇੱਕ ਲੌਗ ਪ੍ਰੋਸੈਸਿੰਗ ਪਾਈਪਲਾਈਨ ਦੋਵਾਂ ਨੂੰ ਜੋੜਦਾ ਹੈ। ਹੁੱਡ ਦੇ ਹੇਠਾਂ, ਗ੍ਰੇਲੌਗ ਕਾਫਕਾ ਅਤੇ ਜ਼ੂਕੀਪਰ ਚਲਾਉਂਦਾ ਹੈ, ਜੋ ਕਿ ਗ੍ਰੇਲੌਗ ਨੂੰ ਇੱਕ ਕਲੱਸਟਰ ਦੇ ਰੂਪ ਵਿੱਚ ਕਨੈਕਟੀਵਿਟੀ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਗ੍ਰੇਲੌਗ ਲੌਗਸ (ਕਾਫਕਾ) ਨੂੰ ਕੈਸ਼ ਕਰ ਸਕਦਾ ਹੈ ਜੇਕਰ Elasticsearch ਉਪਲਬਧ ਨਹੀਂ ਹੈ ਅਤੇ ਅਸਫ਼ਲ ਰੀਡ ਅਤੇ ਰਾਈਟ ਬੇਨਤੀਆਂ ਨੂੰ ਦੁਹਰਾ ਸਕਦਾ ਹੈ, ਨਿਰਧਾਰਤ ਨਿਯਮਾਂ ਦੇ ਅਨੁਸਾਰ ਲੌਗਸ ਨੂੰ ਗਰੁੱਪ ਅਤੇ ਮਾਰਕ ਕਰ ਸਕਦਾ ਹੈ। ਲੌਗਸਟੈਸ਼ ਦੀ ਤਰ੍ਹਾਂ, ਗ੍ਰੇਲੌਗ ਕੋਲ ਕਤਾਰਾਂ ਨੂੰ Elasticsearch 'ਤੇ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ ਉਹਨਾਂ ਨੂੰ ਸੋਧਣ ਦੀ ਕਾਰਜਕੁਸ਼ਲਤਾ ਹੈ।

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

ਦ੍ਰਿਸ਼ਟੀਗਤ ਤੌਰ 'ਤੇ ਇਹ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ:

ਇਹ ਇੱਕ ਖਾਸ ਉਦਾਹਰਣ ਤੋਂ ਇੱਕ ਸਕ੍ਰੀਨਸ਼ੌਟ ਹੈ। ਇੱਥੇ ਅਸੀਂ ਖੋਜ ਪੁੱਛਗਿੱਛ ਦੇ ਅਧਾਰ ਤੇ ਇੱਕ ਹਿਸਟੋਗ੍ਰਾਮ ਬਣਾਉਂਦੇ ਹਾਂ ਅਤੇ ਸੰਬੰਧਿਤ ਕਤਾਰਾਂ ਨੂੰ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰਦੇ ਹਾਂ।

ਸੂਚੀ-ਪੱਤਰ

ਸਿਸਟਮ ਆਰਕੀਟੈਕਚਰ 'ਤੇ ਵਾਪਸ ਆਉਣਾ, ਮੈਂ ਇਸ ਬਾਰੇ ਵਧੇਰੇ ਵਿਸਥਾਰ ਨਾਲ ਵਿਚਾਰ ਕਰਨਾ ਚਾਹਾਂਗਾ ਕਿ ਅਸੀਂ ਇੰਡੈਕਸ ਮਾਡਲ ਕਿਵੇਂ ਬਣਾਇਆ ਹੈ ਤਾਂ ਜੋ ਇਹ ਸਭ ਸਹੀ ਢੰਗ ਨਾਲ ਕੰਮ ਕਰੇ।

ਉਪਰੋਕਤ ਚਿੱਤਰ ਵਿੱਚ, ਇਹ ਸਭ ਤੋਂ ਹੇਠਲਾ ਪੱਧਰ ਹੈ: Elasticsearch ਡੇਟਾ ਨੋਡਸ।

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

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

ਇਸ ਦਾ ਨਤੀਜਾ ਇਹ ਨਿਕਲਿਆ ਕਿ ਪ੍ਰਤੀ ਸੂਚਕਾਂਕ (ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਦੇ ਨਾਲ) ਸ਼ਾਰਡਾਂ ਦੀ ਸੰਖਿਆ ਡੇਟਾ ਨੋਡਾਂ ਦੀ ਸੰਖਿਆ ਦੇ ਬਰਾਬਰ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਦੋ ਦੇ ਬਰਾਬਰ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਕਾਰਕ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ (ਅਰਥਾਤ, ਅਸੀਂ ਅੱਧੇ ਕਲੱਸਟਰ ਨੂੰ ਗੁਆ ਸਕਦੇ ਹਾਂ)। ਅਤੇ, ਦੂਜਾ, ਕਲੱਸਟਰ ਦੇ ਘੱਟੋ-ਘੱਟ ਅੱਧੇ 'ਤੇ ਪੜ੍ਹਨ ਅਤੇ ਲਿਖਣ ਦੀਆਂ ਬੇਨਤੀਆਂ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰਨ ਲਈ।

ਅਸੀਂ ਪਹਿਲਾਂ ਸਟੋਰੇਜ ਸਮਾਂ 30 ਦਿਨਾਂ ਦੇ ਰੂਪ ਵਿੱਚ ਨਿਰਧਾਰਤ ਕੀਤਾ ਹੈ।

ਸ਼ਾਰਡਾਂ ਦੀ ਵੰਡ ਨੂੰ ਹੇਠਾਂ ਦਿੱਤੇ ਗ੍ਰਾਫਿਕ ਰੂਪ ਵਿੱਚ ਦਰਸਾਇਆ ਜਾ ਸਕਦਾ ਹੈ:

ਪੂਰਾ ਗੂੜ੍ਹਾ ਸਲੇਟੀ ਆਇਤ ਇੱਕ ਸੂਚਕਾਂਕ ਹੈ। ਇਸ ਵਿੱਚ ਖੱਬਾ ਲਾਲ ਵਰਗ ਪ੍ਰਾਇਮਰੀ ਸ਼ਾਰਡ ਹੈ, ਸੂਚਕਾਂਕ ਵਿੱਚ ਪਹਿਲਾ। ਅਤੇ ਨੀਲਾ ਵਰਗ ਇੱਕ ਪ੍ਰਤੀਰੂਪ ਸ਼ਾਰਡ ਹੈ। ਉਹ ਵੱਖ-ਵੱਖ ਡਾਟਾ ਸੈਂਟਰਾਂ ਵਿੱਚ ਸਥਿਤ ਹਨ।

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

ਸੂਚਕਾਂਕ ਦੀ ਰੋਟੇਸ਼ਨ, i.e. ਇੱਕ ਨਵਾਂ ਸੂਚਕਾਂਕ ਬਣਾਉਣਾ ਅਤੇ ਸਭ ਤੋਂ ਪੁਰਾਣੇ ਨੂੰ ਮਿਟਾਉਣਾ, ਅਸੀਂ ਇਸਨੂੰ 48 ਘੰਟਿਆਂ ਦੇ ਬਰਾਬਰ ਕਰ ਦਿੱਤਾ ਹੈ (ਸੂਚਕਾਂਕ ਦੀ ਵਰਤੋਂ ਦੇ ਪੈਟਰਨ ਦੇ ਅਨੁਸਾਰ: ਪਿਛਲੇ 48 ਘੰਟਿਆਂ ਨੂੰ ਅਕਸਰ ਖੋਜਿਆ ਜਾਂਦਾ ਹੈ)।

ਇਹ ਸੂਚਕਾਂਕ ਰੋਟੇਸ਼ਨ ਅੰਤਰਾਲ ਹੇਠਾਂ ਦਿੱਤੇ ਕਾਰਨਾਂ ਕਰਕੇ ਹੈ:

ਜਦੋਂ ਇੱਕ ਖੋਜ ਬੇਨਤੀ ਇੱਕ ਖਾਸ ਡੇਟਾ ਨੋਡ ਤੇ ਪਹੁੰਚਦੀ ਹੈ, ਤਾਂ, ਪ੍ਰਦਰਸ਼ਨ ਦੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ, ਇਹ ਵਧੇਰੇ ਲਾਭਦਾਇਕ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਇੱਕ ਸ਼ਾਰਡ ਦੀ ਪੁੱਛਗਿੱਛ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਜੇਕਰ ਇਸਦਾ ਆਕਾਰ ਨੋਡ ਦੇ ਕਮਰ ਦੇ ਆਕਾਰ ਨਾਲ ਤੁਲਨਾਯੋਗ ਹੈ. ਇਹ ਤੁਹਾਨੂੰ ਸੂਚਕਾਂਕ ਦੇ "ਗਰਮ" ਹਿੱਸੇ ਨੂੰ ਇੱਕ ਢੇਰ ਵਿੱਚ ਰੱਖਣ ਅਤੇ ਇਸ ਤੱਕ ਤੁਰੰਤ ਪਹੁੰਚ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ। ਜਦੋਂ ਬਹੁਤ ਸਾਰੇ "ਗਰਮ ਹਿੱਸੇ" ਹੁੰਦੇ ਹਨ, ਤਾਂ ਸੂਚਕਾਂਕ ਖੋਜ ਦੀ ਗਤੀ ਘਟ ਜਾਂਦੀ ਹੈ।

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

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

ਨਤੀਜੇ ਵਜੋਂ, ਅਸੀਂ ਪਾਇਆ ਕਿ ਔਸਤਨ ਇੱਕ ਸ਼ਾਰਡ ਦਾ ਭਾਰ ਲਗਭਗ 20 ਗੀਗਾਬਾਈਟ ਹੈ, ਅਤੇ ਪ੍ਰਤੀ ਸੂਚਕਾਂਕ ਵਿੱਚ 1 ਸ਼ਾਰਡ ਹਨ। ਇਸ ਅਨੁਸਾਰ, ਜੇਕਰ ਅਸੀਂ ਉਹਨਾਂ ਨੂੰ ਹਰ 360 ਘੰਟਿਆਂ ਵਿੱਚ ਇੱਕ ਵਾਰ ਘੁੰਮਾਉਂਦੇ ਹਾਂ, ਤਾਂ ਸਾਡੇ ਕੋਲ ਉਹਨਾਂ ਵਿੱਚੋਂ 48 ਹਨ। ਹਰੇਕ ਸੂਚਕਾਂਕ ਵਿੱਚ 15 ਦਿਨਾਂ ਦਾ ਡੇਟਾ ਹੁੰਦਾ ਹੈ।

ਡਾਟਾ ਰਾਈਟਿੰਗ ਅਤੇ ਰੀਡਿੰਗ ਸਰਕਟ

ਆਓ ਇਹ ਪਤਾ ਕਰੀਏ ਕਿ ਇਸ ਸਿਸਟਮ ਵਿੱਚ ਡੇਟਾ ਕਿਵੇਂ ਰਿਕਾਰਡ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

ਮੰਨ ਲਓ ਕਿ ਗ੍ਰੇਲੌਗ ਤੋਂ ਕੋਆਰਡੀਨੇਟਰ ਨੂੰ ਕੁਝ ਬੇਨਤੀ ਆਉਂਦੀ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਅਸੀਂ 2-3 ਹਜ਼ਾਰ ਕਤਾਰਾਂ ਨੂੰ ਇੰਡੈਕਸ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਾਂ।

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

ਮਾਸਟਰ ਜਵਾਬ ਦਿੰਦਾ ਹੈ: "ਇਸ ਜਾਣਕਾਰੀ ਨੂੰ ਸ਼ਾਰਡ ਨੰਬਰ 71 'ਤੇ ਲਿਖੋ," ਜਿਸ ਤੋਂ ਬਾਅਦ ਇਹ ਸਿੱਧੇ ਸੰਬੰਧਿਤ ਡੇਟਾ ਨੋਡ 'ਤੇ ਭੇਜੀ ਜਾਂਦੀ ਹੈ, ਜਿੱਥੇ ਪ੍ਰਾਇਮਰੀ-ਸ਼ਾਰਡ ਨੰਬਰ 71 ਸਥਿਤ ਹੈ।

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

ਗ੍ਰੇਲੌਗ ਤੋਂ ਕੋਆਰਡੀਨੇਟਰ ਨੂੰ ਇੱਕ ਖੋਜ ਬੇਨਤੀ ਆਉਂਦੀ ਹੈ। ਕੋਆਰਡੀਨੇਟਰ ਇਸ ਨੂੰ ਸੂਚਕਾਂਕ ਦੇ ਅਨੁਸਾਰ ਰੀਡਾਇਰੈਕਟ ਕਰਦਾ ਹੈ, ਜਦੋਂ ਕਿ Elasticsearch ਰਾਊਂਡ-ਰੋਬਿਨ ਸਿਧਾਂਤ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਪ੍ਰਾਇਮਰੀ-ਸ਼ਾਰਡ ਅਤੇ ਪ੍ਰਤੀਕ੍ਰਿਤੀ-ਸ਼ਾਰਡ ਵਿਚਕਾਰ ਬੇਨਤੀਆਂ ਨੂੰ ਵੰਡਦਾ ਹੈ।

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

ਇਹ ਸਮੁੱਚਾ ਸਿਸਟਮ ਔਸਤਨ 48-300ms ਵਿੱਚ ਪਿਛਲੇ 400 ਘੰਟਿਆਂ ਲਈ ਖੋਜ ਸਵਾਲਾਂ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰਦਾ ਹੈ, ਇੱਕ ਪ੍ਰਮੁੱਖ ਵਾਈਲਡਕਾਰਡ ਨਾਲ ਉਹਨਾਂ ਸਵਾਲਾਂ ਨੂੰ ਛੱਡ ਕੇ।

Elasticsearch ਦੇ ਨਾਲ ਫੁੱਲ: Java ਸੈੱਟਅੱਪ

ਇਹ ਸਭ ਕੁਝ ਉਸੇ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਨ ਲਈ ਜਿਸ ਤਰ੍ਹਾਂ ਅਸੀਂ ਅਸਲ ਵਿੱਚ ਚਾਹੁੰਦੇ ਸੀ, ਅਸੀਂ ਕਲੱਸਟਰ ਵਿੱਚ ਕਈ ਤਰ੍ਹਾਂ ਦੀਆਂ ਚੀਜ਼ਾਂ ਨੂੰ ਡੀਬੱਗ ਕਰਨ ਵਿੱਚ ਬਹੁਤ ਲੰਮਾ ਸਮਾਂ ਬਿਤਾਇਆ।

ਖੋਜੀਆਂ ਗਈਆਂ ਸਮੱਸਿਆਵਾਂ ਦਾ ਪਹਿਲਾ ਹਿੱਸਾ Elasticsearch ਵਿੱਚ ਡਿਫੌਲਟ ਰੂਪ ਵਿੱਚ ਜਾਵਾ ਨੂੰ ਪਹਿਲਾਂ ਤੋਂ ਸੰਰਚਿਤ ਕਰਨ ਦੇ ਤਰੀਕੇ ਨਾਲ ਸਬੰਧਤ ਸੀ।

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

ਇਹ ਪਤਾ ਚਲਿਆ ਕਿ ਲੂਸੀਨ ਸੂਚਕਾਂਕ ਦਾ ਅਭੇਦ ਕਮਰ ਦੇ ਬਾਹਰ ਹੁੰਦਾ ਹੈ. ਅਤੇ ਖਪਤ ਕੀਤੇ ਸਰੋਤਾਂ ਦੇ ਮਾਮਲੇ ਵਿੱਚ ਕੰਟੇਨਰ ਕਾਫ਼ੀ ਸਖਤੀ ਨਾਲ ਸੀਮਤ ਹਨ। ਇਹਨਾਂ ਸਰੋਤਾਂ ਵਿੱਚ ਸਿਰਫ਼ ਹੀਪ ਹੀ ਫਿੱਟ ਹੋ ਸਕਦਾ ਹੈ (heap.size ਮੁੱਲ ਲਗਭਗ RAM ਦੇ ਬਰਾਬਰ ਸੀ), ਅਤੇ ਕੁਝ ਔਫ-ਹੀਪ ਓਪਰੇਸ਼ਨ ਇੱਕ ਮੈਮੋਰੀ ਵੰਡ ਗਲਤੀ ਨਾਲ ਕ੍ਰੈਸ਼ ਹੋ ਜਾਂਦੇ ਹਨ ਜੇਕਰ ਕਿਸੇ ਕਾਰਨ ਕਰਕੇ ਉਹ ~ 500MB ਵਿੱਚ ਫਿੱਟ ਨਹੀਂ ਹੁੰਦੇ ਜੋ ਕਿ ਸੀਮਾ ਤੋਂ ਪਹਿਲਾਂ ਰਹਿ ਜਾਂਦੇ ਹਨ।

ਫਿਕਸ ਕਾਫ਼ੀ ਮਾਮੂਲੀ ਸੀ: ਕੰਟੇਨਰ ਲਈ ਉਪਲਬਧ ਰੈਮ ਦੀ ਮਾਤਰਾ ਵਧਾ ਦਿੱਤੀ ਗਈ ਸੀ, ਜਿਸ ਤੋਂ ਬਾਅਦ ਅਸੀਂ ਭੁੱਲ ਗਏ ਕਿ ਸਾਨੂੰ ਅਜਿਹੀਆਂ ਸਮੱਸਿਆਵਾਂ ਵੀ ਸਨ।

ਸਮੱਸਿਆ ਦੋ
ਕਲੱਸਟਰ ਦੇ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ 4-5 ਦਿਨ ਬਾਅਦ, ਅਸੀਂ ਦੇਖਿਆ ਕਿ ਡਾਟਾ ਨੋਡ ਸਮੇਂ-ਸਮੇਂ 'ਤੇ ਕਲੱਸਟਰ ਤੋਂ ਬਾਹਰ ਆਉਣੇ ਸ਼ੁਰੂ ਹੋ ਜਾਂਦੇ ਹਨ ਅਤੇ 10-20 ਸਕਿੰਟਾਂ ਬਾਅਦ ਇਸ ਵਿੱਚ ਦਾਖਲ ਹੁੰਦੇ ਹਨ।

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

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

ਹੱਲ ਇਸ ਤਰ੍ਹਾਂ ਸੀ: ਅਸੀਂ ਇਹਨਾਂ ਓਪਰੇਸ਼ਨਾਂ ਲਈ ਢੇਰ ਤੋਂ ਬਾਹਰ ਮੈਮੋਰੀ ਦੀ ਵੱਡੀ ਮਾਤਰਾ ਨੂੰ ਵਰਤਣ ਦੀ Java ਦੀ ਯੋਗਤਾ ਨੂੰ ਸੀਮਤ ਕਰ ਦਿੱਤਾ ਹੈ। ਅਸੀਂ ਇਸਨੂੰ 16 ਗੀਗਾਬਾਈਟ (-XX:MaxDirectMemorySize=16g) ਤੱਕ ਸੀਮਤ ਕਰ ਦਿੱਤਾ ਹੈ, ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਕਿ ਸਪਸ਼ਟ GC ਨੂੰ ਬਹੁਤ ਜ਼ਿਆਦਾ ਵਾਰ ਬੁਲਾਇਆ ਗਿਆ ਸੀ ਅਤੇ ਬਹੁਤ ਤੇਜ਼ੀ ਨਾਲ ਪ੍ਰਕਿਰਿਆ ਕੀਤੀ ਗਈ ਸੀ, ਇਸ ਤਰ੍ਹਾਂ ਹੁਣ ਕਲੱਸਟਰ ਨੂੰ ਅਸਥਿਰ ਨਹੀਂ ਕੀਤਾ ਜਾਵੇਗਾ।

ਸਮੱਸਿਆ ਤਿੰਨ
ਜੇ ਤੁਸੀਂ ਸੋਚਦੇ ਹੋ ਕਿ "ਸਭ ਤੋਂ ਅਚਾਨਕ ਪਲ 'ਤੇ ਕਲੱਸਟਰ ਨੂੰ ਛੱਡਣ ਵਾਲੇ ਨੋਡਸ" ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਖਤਮ ਹੋ ਗਈਆਂ ਹਨ, ਤਾਂ ਤੁਸੀਂ ਗਲਤ ਹੋ।

ਜਦੋਂ ਅਸੀਂ ਕੰਮ ਨੂੰ ਸੂਚਕਾਂਕ ਨਾਲ ਸੰਰਚਿਤ ਕੀਤਾ, ਅਸੀਂ mmapfs ਨੂੰ ਚੁਣਿਆ ਖੋਜ ਸਮਾਂ ਘਟਾਓ ਮਹਾਨ ਖੰਡ ਦੇ ਨਾਲ ਤਾਜ਼ੇ ਸ਼ਾਰਡਾਂ 'ਤੇ। ਇਹ ਕਾਫ਼ੀ ਗਲਤੀ ਸੀ, ਕਿਉਂਕਿ mmapfs ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ ਫਾਈਲ ਨੂੰ RAM ਵਿੱਚ ਮੈਪ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਫਿਰ ਅਸੀਂ ਮੈਪ ਕੀਤੀ ਫਾਈਲ ਨਾਲ ਕੰਮ ਕਰਦੇ ਹਾਂ। ਇਸਦੇ ਕਾਰਨ, ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ ਕਿ ਜਦੋਂ ਜੀਸੀ ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ ਥਰਿੱਡਾਂ ਨੂੰ ਰੋਕਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ, ਤਾਂ ਅਸੀਂ ਬਹੁਤ ਲੰਬੇ ਸਮੇਂ ਲਈ ਸੇਫ ਪੁਆਇੰਟ ਤੇ ਜਾਂਦੇ ਹਾਂ, ਅਤੇ ਇਸਦੇ ਰਸਤੇ ਵਿੱਚ, ਐਪਲੀਕੇਸ਼ਨ ਮਾਸਟਰ ਦੀਆਂ ਬੇਨਤੀਆਂ ਦਾ ਜਵਾਬ ਦੇਣਾ ਬੰਦ ਕਰ ਦਿੰਦੀ ਹੈ ਕਿ ਕੀ ਇਹ ਜਿੰਦਾ ਹੈ। . ਇਸ ਅਨੁਸਾਰ, ਮਾਸਟਰ ਦਾ ਮੰਨਣਾ ਹੈ ਕਿ ਨੋਡ ਹੁਣ ਕਲੱਸਟਰ ਵਿੱਚ ਮੌਜੂਦ ਨਹੀਂ ਹੈ। ਇਸ ਤੋਂ ਬਾਅਦ, 5-10 ਸਕਿੰਟਾਂ ਬਾਅਦ, ਕੂੜਾ ਇਕੱਠਾ ਕਰਨ ਵਾਲਾ ਕੰਮ ਕਰਦਾ ਹੈ, ਨੋਡ ਜੀਵਨ ਵਿੱਚ ਆਉਂਦਾ ਹੈ, ਦੁਬਾਰਾ ਕਲੱਸਟਰ ਵਿੱਚ ਦਾਖਲ ਹੁੰਦਾ ਹੈ ਅਤੇ ਸ਼ਾਰਡਾਂ ਨੂੰ ਸ਼ੁਰੂ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ। ਇਹ ਸਭ ਕੁਝ "ਉਤਪਾਦਨ ਜਿਸ ਦੇ ਅਸੀਂ ਹੱਕਦਾਰ ਸੀ" ਵਰਗਾ ਮਹਿਸੂਸ ਕੀਤਾ ਅਤੇ ਕਿਸੇ ਵੀ ਗੰਭੀਰ ਲਈ ਢੁਕਵਾਂ ਨਹੀਂ ਸੀ।

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

ਸਮੱਸਿਆ ਚਾਰ
ਫਿਰ ਇਕ ਹੋਰ ਬਹੁਤ ਦਿਲਚਸਪ ਸਮੱਸਿਆ ਸੀ ਜਿਸਦਾ ਅਸੀਂ ਰਿਕਾਰਡ ਸਮੇਂ ਲਈ ਇਲਾਜ ਕੀਤਾ. ਅਸੀਂ ਇਸਨੂੰ 2-3 ਮਹੀਨਿਆਂ ਲਈ ਫੜਿਆ ਕਿਉਂਕਿ ਇਸਦਾ ਪੈਟਰਨ ਬਿਲਕੁਲ ਸਮਝ ਤੋਂ ਬਾਹਰ ਸੀ।

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

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

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

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

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

ਇਹ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਜਾਵਾ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਖਤਮ ਹੋਈਆਂ ਅਤੇ ਬੈਂਡਵਿਡਥ ਸਮੱਸਿਆਵਾਂ ਸ਼ੁਰੂ ਹੋਈਆਂ।

Elasticsearch ਦੇ ਨਾਲ "ਬੇਰੀ": ਥ੍ਰੁਪੁੱਟ

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

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

ਇਹ ਇਸ ਤੱਥ ਦੇ ਕਾਰਨ ਸੀ ਕਿ ਇੱਕ ਡੇਟਾ ਨੋਡ 'ਤੇ thread_pool.write.queue, ਜਦੋਂ ਤੱਕ Elasticsearch ਇੰਡੈਕਸਿੰਗ ਬੇਨਤੀ ਨੂੰ ਪ੍ਰਕਿਰਿਆ ਕਰਨ ਅਤੇ ਡਿਸਕ 'ਤੇ ਸ਼ਾਰਡ ਵਿੱਚ ਜਾਣਕਾਰੀ ਅੱਪਲੋਡ ਕਰਨ ਦੇ ਯੋਗ ਨਹੀਂ ਹੁੰਦਾ, ਡਿਫੌਲਟ ਰੂਪ ਵਿੱਚ ਸਿਰਫ 200 ਬੇਨਤੀਆਂ ਨੂੰ ਕੈਸ਼ ਕਰਨ ਦੇ ਯੋਗ ਹੁੰਦਾ ਹੈ। ਅਤੇ ਵਿੱਚ ਲਚਕੀਲੇ ਖੋਜ ਦਸਤਾਵੇਜ਼ ਇਸ ਪੈਰਾਮੀਟਰ ਬਾਰੇ ਬਹੁਤ ਘੱਟ ਕਿਹਾ ਗਿਆ ਹੈ. ਸਿਰਫ਼ ਥਰਿੱਡਾਂ ਦੀ ਵੱਧ ਤੋਂ ਵੱਧ ਗਿਣਤੀ ਅਤੇ ਮੂਲ ਆਕਾਰ ਦਰਸਾਏ ਗਏ ਹਨ।

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

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

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

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

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

ਪਰ ਇਸ ਨੂੰ ਅੰਸ਼ਕ ਤੌਰ 'ਤੇ ਇਸ ਤੱਥ ਦੇ ਕਾਰਨ ਰੋਕਿਆ ਜਾ ਸਕਦਾ ਹੈ ਕਿ Elasticsearch ਦੇ ਛੇਵੇਂ ਸੰਸਕਰਣਾਂ ਵਿੱਚ, ਇੱਕ ਐਲਗੋਰਿਦਮ ਪ੍ਰਗਟ ਹੋਇਆ ਜੋ ਤੁਹਾਨੂੰ ਸੰਬੰਧਿਤ ਡੇਟਾ ਨੋਡਾਂ ਵਿਚਕਾਰ ਸਵਾਲਾਂ ਨੂੰ ਵੰਡਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ ਨਾ ਕਿ ਬੇਤਰਤੀਬ ਰਾਊਂਡ-ਰੋਬਿਨ ਸਿਧਾਂਤ (ਉਹ ਕੰਟੇਨਰ ਜੋ ਇੰਡੈਕਸਿੰਗ ਕਰਦਾ ਹੈ ਅਤੇ ਪ੍ਰਾਇਮਰੀ ਨੂੰ ਰੱਖਦਾ ਹੈ। -ਸ਼ਾਰਡ ਬਹੁਤ ਵਿਅਸਤ ਹੋ ਸਕਦਾ ਹੈ, ਜਲਦੀ ਜਵਾਬ ਦੇਣ ਦਾ ਕੋਈ ਤਰੀਕਾ ਨਹੀਂ ਹੋਵੇਗਾ), ਪਰ ਇਸ ਬੇਨਤੀ ਨੂੰ ਇੱਕ ਪ੍ਰਤੀਕ੍ਰਿਤੀ-ਸ਼ਾਰਡ ਵਾਲੇ ਇੱਕ ਘੱਟ ਲੋਡ ਕੀਤੇ ਕੰਟੇਨਰ ਵਿੱਚ ਅੱਗੇ ਭੇਜਣ ਲਈ, ਜੋ ਬਹੁਤ ਤੇਜ਼ੀ ਨਾਲ ਜਵਾਬ ਦੇਵੇਗਾ। ਦੂਜੇ ਸ਼ਬਦਾਂ ਵਿੱਚ, ਅਸੀਂ use_adaptive_replica_selection 'ਤੇ ਪਹੁੰਚੇ: ਸਹੀ।

ਪੜ੍ਹਨ ਦੀ ਤਸਵੀਰ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ:

ਇਸ ਐਲਗੋਰਿਦਮ ਵਿੱਚ ਤਬਦੀਲੀ ਨੇ ਉਹਨਾਂ ਪਲਾਂ ਵਿੱਚ ਪੁੱਛਗਿੱਛ ਦੇ ਸਮੇਂ ਵਿੱਚ ਮਹੱਤਵਪੂਰਨ ਸੁਧਾਰ ਕਰਨਾ ਸੰਭਵ ਬਣਾਇਆ ਜਦੋਂ ਸਾਡੇ ਕੋਲ ਲਿਖਣ ਲਈ ਲੌਗਸ ਦਾ ਇੱਕ ਵੱਡਾ ਪ੍ਰਵਾਹ ਸੀ।

ਅੰਤ ਵਿੱਚ, ਮੁੱਖ ਸਮੱਸਿਆ ਡੇਟਾ ਸੈਂਟਰ ਨੂੰ ਦਰਦ ਰਹਿਤ ਹਟਾਉਣਾ ਸੀ.

ਇੱਕ DC ਨਾਲ ਕੁਨੈਕਸ਼ਨ ਗੁਆਉਣ ਤੋਂ ਤੁਰੰਤ ਬਾਅਦ ਅਸੀਂ ਕਲੱਸਟਰ ਤੋਂ ਕੀ ਚਾਹੁੰਦੇ ਸੀ:

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

ਜਿਵੇਂ ਕਿ ਇਹ ਨਿਕਲਿਆ, ਅਸੀਂ ਇਸ ਤਰ੍ਹਾਂ ਕੁਝ ਚਾਹੁੰਦੇ ਸੀ:

ਅਤੇ ਸਾਨੂੰ ਹੇਠ ਲਿਖਿਆਂ ਮਿਲਿਆ ਹੈ:

ਇਹ ਕਿੱਦਾਂ ਹੋਇਆ?

ਜਦੋਂ ਡੇਟਾ ਸੈਂਟਰ ਡਿੱਗ ਗਿਆ, ਤਾਂ ਸਾਡਾ ਮਾਸਟਰ ਰੁਕਾਵਟ ਬਣ ਗਿਆ.

ਕਿਉਂ?

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

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

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

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

ਅਸੀਂ ਮਾਪ ਲਏ, ਅਤੇ ਸੰਸਕਰਣ 6.4.0 ਤੋਂ ਪਹਿਲਾਂ, ਜਿੱਥੇ ਇਹ ਫਿਕਸ ਕੀਤਾ ਗਿਆ ਸੀ, ਸਾਡੇ ਲਈ ਕਲੱਸਟਰ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬੰਦ ਕਰਨ ਲਈ ਇੱਕੋ ਸਮੇਂ 10 ਵਿੱਚੋਂ ਸਿਰਫ 360 ਡਾਟਾ ਨੋਡਾਂ ਨੂੰ ਆਉਟਪੁੱਟ ਕਰਨਾ ਕਾਫ਼ੀ ਸੀ।

ਇਹ ਕੁਝ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦਾ ਸੀ:

ਸੰਸਕਰਣ 6.4.0 ਤੋਂ ਬਾਅਦ, ਜਿੱਥੇ ਇਹ ਭਿਆਨਕ ਬੱਗ ਫਿਕਸ ਕੀਤਾ ਗਿਆ ਸੀ, ਡੇਟਾ ਨੋਡਸ ਨੇ ਮਾਸਟਰ ਨੂੰ ਮਾਰਨਾ ਬੰਦ ਕਰ ਦਿੱਤਾ। ਪਰ ਇਸਨੇ ਉਸਨੂੰ "ਹੁਸ਼ਿਆਰ" ਨਹੀਂ ਬਣਾਇਆ. ਅਰਥਾਤ: ਜਦੋਂ ਅਸੀਂ 2, 3 ਜਾਂ 10 (ਇੱਕ ਤੋਂ ਇਲਾਵਾ ਕੋਈ ਵੀ ਸੰਖਿਆ) ਡਾਟਾ ਨੋਡਾਂ ਨੂੰ ਆਉਟਪੁੱਟ ਕਰਦੇ ਹਾਂ, ਤਾਂ ਮਾਸਟਰ ਨੂੰ ਕੁਝ ਪਹਿਲਾ ਸੁਨੇਹਾ ਮਿਲਦਾ ਹੈ ਜੋ ਕਹਿੰਦਾ ਹੈ ਕਿ ਨੋਡ ਏ ਛੱਡ ਗਿਆ ਹੈ, ਅਤੇ ਨੋਡ ਬੀ, ਨੋਡ ਸੀ ਨੂੰ ਇਸ ਬਾਰੇ, ਨੋਡ ਡੀ ਨੂੰ ਦੱਸਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ।

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

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

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

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

ਨਤੀਜੇ ਵਜੋਂ, ਅੱਜ ਇੱਕ ਡੇਟਾ ਸੈਂਟਰ ਨੂੰ ਵਾਪਸ ਲੈਣ ਦੇ ਕੰਮ ਵਿੱਚ ਸਾਨੂੰ ਭੀੜ ਦੇ ਸਮੇਂ ਵਿੱਚ ਲਗਭਗ 5 ਮਿੰਟ ਲੱਗਦੇ ਹਨ। ਅਜਿਹੇ ਵੱਡੇ ਅਤੇ ਬੇਢੰਗੇ ਕੋਲੋਸਸ ਲਈ, ਇਹ ਇੱਕ ਬਹੁਤ ਵਧੀਆ ਨਤੀਜਾ ਹੈ.

ਨਤੀਜੇ ਵਜੋਂ, ਅਸੀਂ ਹੇਠਾਂ ਦਿੱਤੇ ਫੈਸਲੇ 'ਤੇ ਆਏ:

• ਸਾਡੇ ਕੋਲ 360 ਗੀਗਾਬਾਈਟ ਡਿਸਕਾਂ ਦੇ ਨਾਲ 700 ਡਾਟਾ ਨੋਡ ਹਨ।
• ਇਹਨਾਂ ਇੱਕੋ ਡੇਟਾ ਨੋਡਾਂ ਰਾਹੀਂ ਟ੍ਰੈਫਿਕ ਨੂੰ ਰੂਟ ਕਰਨ ਲਈ 60 ਕੋਆਰਡੀਨੇਟਰ।
• 40 ਮਾਸਟਰ ਜੋ ਅਸੀਂ 6.4.0 ਤੋਂ ਪਹਿਲਾਂ ਦੇ ਸੰਸਕਰਣਾਂ ਤੋਂ ਇੱਕ ਕਿਸਮ ਦੀ ਵਿਰਾਸਤ ਦੇ ਤੌਰ 'ਤੇ ਛੱਡੇ ਹਨ - ਡੇਟਾ ਸੈਂਟਰ ਨੂੰ ਵਾਪਸ ਲੈਣ ਤੋਂ ਬਚਣ ਲਈ, ਅਸੀਂ ਕਈ ਮਸ਼ੀਨਾਂ ਨੂੰ ਗੁਆਉਣ ਲਈ ਮਾਨਸਿਕ ਤੌਰ 'ਤੇ ਤਿਆਰ ਸੀ ਤਾਂ ਜੋ ਮਾਸਟਰਾਂ ਦੇ ਕੋਰਮ ਹੋਣ ਦੀ ਗਾਰੰਟੀ ਦਿੱਤੀ ਜਾ ਸਕੇ। ਸਭ ਤੋਂ ਮਾੜੀ ਸਥਿਤੀ
• ਇੱਕ ਕੰਟੇਨਰ 'ਤੇ ਭੂਮਿਕਾਵਾਂ ਨੂੰ ਜੋੜਨ ਦੀ ਕੋਈ ਵੀ ਕੋਸ਼ਿਸ਼ ਇਸ ਤੱਥ ਦੇ ਨਾਲ ਕੀਤੀ ਗਈ ਸੀ ਕਿ ਜਲਦੀ ਜਾਂ ਬਾਅਦ ਵਿੱਚ ਨੋਡ ਲੋਡ ਦੇ ਹੇਠਾਂ ਟੁੱਟ ਜਾਵੇਗਾ।
• ਪੂਰਾ ਕਲੱਸਟਰ 31 ਗੀਗਾਬਾਈਟ ਦੇ ਇੱਕ heap.size ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ: ਆਕਾਰ ਨੂੰ ਘਟਾਉਣ ਦੀਆਂ ਸਾਰੀਆਂ ਕੋਸ਼ਿਸ਼ਾਂ ਦੇ ਨਤੀਜੇ ਵਜੋਂ ਜਾਂ ਤਾਂ ਪ੍ਰਮੁੱਖ ਵਾਈਲਡਕਾਰਡ ਨਾਲ ਭਾਰੀ ਖੋਜ ਸਵਾਲਾਂ 'ਤੇ ਕੁਝ ਨੋਡਾਂ ਨੂੰ ਮਾਰ ਦਿੱਤਾ ਗਿਆ ਜਾਂ Elasticsearch ਵਿੱਚ ਹੀ ਸਰਕਟ ਬ੍ਰੇਕਰ ਪ੍ਰਾਪਤ ਕੀਤਾ ਗਿਆ।
• ਇਸ ਤੋਂ ਇਲਾਵਾ, ਖੋਜ ਕਾਰਜਕੁਸ਼ਲਤਾ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ, ਅਸੀਂ ਕਲੱਸਟਰ ਵਿੱਚ ਵਸਤੂਆਂ ਦੀ ਸੰਖਿਆ ਨੂੰ ਜਿੰਨਾ ਸੰਭਵ ਹੋ ਸਕੇ ਛੋਟਾ ਰੱਖਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ, ਤਾਂ ਜੋ ਅਸੀਂ ਮਾਸਟਰ ਵਿੱਚ ਪ੍ਰਾਪਤ ਕੀਤੀ ਰੁਕਾਵਟ ਵਿੱਚ ਸੰਭਵ ਤੌਰ 'ਤੇ ਘੱਟ ਤੋਂ ਘੱਟ ਘਟਨਾਵਾਂ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰ ਸਕੀਏ।

ਅੰਤ ਵਿੱਚ ਨਿਗਰਾਨੀ ਬਾਰੇ

ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਕਿ ਇਹ ਸਭ ਇਰਾਦੇ ਅਨੁਸਾਰ ਕੰਮ ਕਰਦਾ ਹੈ, ਅਸੀਂ ਹੇਠਾਂ ਦਿੱਤੇ ਦੀ ਨਿਗਰਾਨੀ ਕਰਦੇ ਹਾਂ:

• ਹਰੇਕ ਡੇਟਾ ਨੋਡ ਸਾਡੇ ਕਲਾਉਡ ਨੂੰ ਰਿਪੋਰਟ ਕਰਦਾ ਹੈ ਕਿ ਇਹ ਮੌਜੂਦ ਹੈ, ਅਤੇ ਇਸ 'ਤੇ ਅਜਿਹੇ ਅਤੇ ਅਜਿਹੇ ਸ਼ਾਰਡ ਹਨ। ਜਦੋਂ ਅਸੀਂ ਕਿਤੇ ਕਿਸੇ ਚੀਜ਼ ਨੂੰ ਬੁਝਾਉਂਦੇ ਹਾਂ, ਤਾਂ ਕਲੱਸਟਰ 2-3 ਸਕਿੰਟਾਂ ਬਾਅਦ ਰਿਪੋਰਟ ਕਰਦਾ ਹੈ ਕਿ ਕੇਂਦਰ A ਵਿੱਚ ਅਸੀਂ ਨੋਡਸ 2, 3, ਅਤੇ 4 ਨੂੰ ਬੁਝਾ ਦਿੱਤਾ ਹੈ - ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਦੂਜੇ ਡੇਟਾ ਸੈਂਟਰਾਂ ਵਿੱਚ ਅਸੀਂ ਉਹਨਾਂ ਨੋਡਾਂ ਨੂੰ ਕਿਸੇ ਵੀ ਹਾਲਤ ਵਿੱਚ ਨਹੀਂ ਬੁਝਾ ਸਕਦੇ ਹਾਂ ਜਿਨ੍ਹਾਂ ਉੱਤੇ ਸਿਰਫ ਇੱਕ ਸ਼ਾਰਡ ਹੁੰਦਾ ਹੈ। ਛੱਡ ਦਿੱਤਾ।
• ਮਾਸਟਰ ਦੇ ਵਿਹਾਰ ਦੀ ਪ੍ਰਕਿਰਤੀ ਨੂੰ ਜਾਣਦਿਆਂ, ਅਸੀਂ ਲੰਬਿਤ ਕੰਮਾਂ ਦੀ ਗਿਣਤੀ ਨੂੰ ਬਹੁਤ ਧਿਆਨ ਨਾਲ ਦੇਖਦੇ ਹਾਂ। ਕਿਉਂਕਿ ਇੱਕ ਅਟਕਿਆ ਹੋਇਆ ਕੰਮ, ਜੇਕਰ ਇਹ ਸਮੇਂ ਸਿਰ ਨਹੀਂ ਨਿਕਲਦਾ, ਤਾਂ ਸਿਧਾਂਤਕ ਤੌਰ 'ਤੇ ਕੁਝ ਸੰਕਟਕਾਲੀਨ ਸਥਿਤੀਆਂ ਵਿੱਚ ਕਾਰਨ ਬਣ ਸਕਦਾ ਹੈ, ਉਦਾਹਰਨ ਲਈ, ਪ੍ਰਾਇਮਰੀ ਵਿੱਚ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਸ਼ਾਰਡ ਦਾ ਪ੍ਰਚਾਰ ਕੰਮ ਨਹੀਂ ਕਰਦਾ, ਜਿਸ ਕਾਰਨ ਇੰਡੈਕਸਿੰਗ ਕੰਮ ਕਰਨਾ ਬੰਦ ਕਰ ਦੇਵੇਗੀ।
• ਅਸੀਂ ਕੂੜਾ ਇਕੱਠਾ ਕਰਨ ਵਾਲੇ ਦੇਰੀ 'ਤੇ ਵੀ ਬਹੁਤ ਧਿਆਨ ਨਾਲ ਦੇਖਦੇ ਹਾਂ, ਕਿਉਂਕਿ ਸਾਨੂੰ ਪਹਿਲਾਂ ਹੀ ਅਨੁਕੂਲਤਾ ਦੇ ਦੌਰਾਨ ਇਸ ਨਾਲ ਬਹੁਤ ਮੁਸ਼ਕਲਾਂ ਆਈਆਂ ਹਨ।
• ਪਹਿਲਾਂ ਤੋਂ ਇਹ ਸਮਝਣ ਲਈ ਥਰਿੱਡ ਦੁਆਰਾ ਅਸਵੀਕਾਰ ਕਰਦਾ ਹੈ ਕਿ ਰੁਕਾਵਟ ਕਿੱਥੇ ਹੈ।
• ਖੈਰ, ਮਿਆਰੀ ਮੈਟ੍ਰਿਕਸ ਜਿਵੇਂ ਕਿ ਹੀਪ, RAM ਅਤੇ I/O।

ਨਿਗਰਾਨੀ ਦਾ ਨਿਰਮਾਣ ਕਰਦੇ ਸਮੇਂ, ਤੁਹਾਨੂੰ ਇਲਾਸਟਿਕ ਖੋਜ ਵਿੱਚ ਥ੍ਰੈਡ ਪੂਲ ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ। ਇਲਾਸਟਿਕ ਖੋਜ ਦਸਤਾਵੇਜ਼ ਖੋਜ ਅਤੇ ਇੰਡੈਕਸਿੰਗ ਲਈ ਸੰਰਚਨਾ ਵਿਕਲਪਾਂ ਅਤੇ ਡਿਫੌਲਟ ਮੁੱਲਾਂ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ, ਪਰ thread_pool.management ਬਾਰੇ ਪੂਰੀ ਤਰ੍ਹਾਂ ਚੁੱਪ ਹੈ। ਇਹ ਥ੍ਰੈਡ ਪ੍ਰਕਿਰਿਆਵਾਂ, ਖਾਸ ਤੌਰ 'ਤੇ, _cat/shards ਅਤੇ ਹੋਰ ਸਮਾਨ ਸਵਾਲਾਂ, ਜੋ ਕਿ ਨਿਗਰਾਨੀ ਲਿਖਣ ਵੇਲੇ ਵਰਤਣ ਲਈ ਸੁਵਿਧਾਜਨਕ ਹਨ। ਕਲੱਸਟਰ ਜਿੰਨਾ ਵੱਡਾ ਹੁੰਦਾ ਹੈ, ਓਨੀ ਹੀ ਵੱਧ ਅਜਿਹੀਆਂ ਬੇਨਤੀਆਂ ਪ੍ਰਤੀ ਯੂਨਿਟ ਸਮੇਂ 'ਤੇ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਅਤੇ ਉਪਰੋਕਤ thread_pool.management ਨਾ ਸਿਰਫ਼ ਅਧਿਕਾਰਤ ਦਸਤਾਵੇਜ਼ਾਂ ਵਿੱਚ ਪੇਸ਼ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਸਗੋਂ ਇਹ ਮੂਲ ਰੂਪ ਵਿੱਚ 5 ਥ੍ਰੈੱਡਾਂ ਤੱਕ ਸੀਮਿਤ ਹੁੰਦਾ ਹੈ, ਜਿਸਦਾ ਬਹੁਤ ਜਲਦੀ ਨਿਪਟਾਰਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਬਾਅਦ ਵਿੱਚ ਜੋ ਨਿਗਰਾਨੀ ਸਹੀ ਢੰਗ ਨਾਲ ਕੰਮ ਕਰਨਾ ਬੰਦ ਕਰ ਦਿੰਦੀ ਹੈ।

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

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

ਸਰੋਤ: www.habr.com