ਓਡੀਸੀ ਰੋਡਮੈਪ: ਅਸੀਂ ਕਨੈਕਸ਼ਨ ਪੂਲਰ ਤੋਂ ਹੋਰ ਕੀ ਚਾਹੁੰਦੇ ਹਾਂ। ਆਂਦਰੇ ਬੋਰੋਡਿਨ (2019)

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

ਵੀਡੀਓ:

ਸਾਰਿਆਂ ਨੂੰ ਸਤਿ ਸ਼੍ਰੀ ਅਕਾਲ! ਮੇਰਾ ਨਾਮ ਐਂਡਰਿਊ ਹੈ।

Yandex ਵਿਖੇ, ਮੈਂ ਓਪਨ ਸੋਰਸ ਡੇਟਾਬੇਸ ਵਿਕਸਿਤ ਕਰਦਾ ਹਾਂ। ਅਤੇ ਅੱਜ ਸਾਡੇ ਕੋਲ ਕੁਨੈਕਸ਼ਨ ਪੂਲਰ ਕੁਨੈਕਸ਼ਨਾਂ ਬਾਰੇ ਇੱਕ ਵਿਸ਼ਾ ਹੈ.

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

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

Yandex ਕੋਲ Postgres ਹੈ। ਕਈ Yandex ਸੇਵਾਵਾਂ Yandex.Cloud ਵਿੱਚ ਰਹਿੰਦੀਆਂ ਹਨ। ਅਤੇ ਸਾਡੇ ਕੋਲ ਕਈ ਪੇਟਾਬਾਈਟ ਡੇਟਾ ਹਨ ਜੋ ਪੋਸਟਗ੍ਰੇਸ ਵਿੱਚ ਪ੍ਰਤੀ ਸਕਿੰਟ ਘੱਟੋ-ਘੱਟ ਇੱਕ ਮਿਲੀਅਨ ਬੇਨਤੀਆਂ ਪੈਦਾ ਕਰਦੇ ਹਨ।

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

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

ਕੁਨੈਕਸ਼ਨ ਪੂਲਰ ਦਾ ਮੁੱਖ ਉਦੇਸ਼ ਕੀ ਹੈ?

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

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

ਇੱਥੇ 3 ਸੰਭਵ ਪਹੁੰਚ ਹਨ:

• ਐਪਲੀਕੇਸ਼ਨ ਵਾਲੇ ਪਾਸੇ.
• ਡਾਟਾਬੇਸ ਪਾਸੇ 'ਤੇ.
• ਅਤੇ ਵਿਚਕਾਰ, ਅਰਥਾਤ, ਹਰ ਕਿਸਮ ਦੇ ਸੰਜੋਗ।

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

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

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

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

ਜੇਕਰ ਅਸੀਂ ਪ੍ਰੌਕਸੀ ਪੂਲਰ ਦੀ ਗੱਲ ਕਰੀਏ, ਤਾਂ ਇੱਥੇ ਦੋ ਪੂਲਰ ਹਨ ਜੋ ਬਹੁਤ ਕੁਝ ਕਰ ਸਕਦੇ ਹਨ। ਉਹ ਸਿਰਫ਼ ਪੂਲਰ ਹੀ ਨਹੀਂ ਹਨ। ਉਹ ਪੂਲਰ + ਵਧੇਰੇ ਠੰਡਾ ਕਾਰਜਸ਼ੀਲਤਾ ਹਨ। ਇਹ Pgpool и ਕਰੰਚੀ-ਪ੍ਰਾਕਸੀ.

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

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

ਅਤੇ ਸਾਡੇ ਕੰਮ ਦੇ ਬੋਝ ਵਿੱਚ, ਇਹ ਸੱਚ ਹੈ. ਪਰ ਕੁਝ ਸਮੱਸਿਆਵਾਂ ਹਨ.

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

ਬੇਸ਼ਕ ਤੁਸੀਂ ਐਪਲੀਕੇਸ਼ਨ_ਨਾਮ_ਐਡ_ਹੋਸਟ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ। ਇਹ ਐਪਲੀਕੇਸ਼ਨ_ਨਾਮ ਵਿੱਚ ਇੱਕ IP ਐਡਰੈੱਸ ਜੋੜਨ ਲਈ ਬਾਊਂਸਰ ਵਾਲੇ ਪਾਸੇ ਇੱਕ ਤਰੀਕਾ ਹੈ। ਪਰ ਐਪਲੀਕੇਸ਼ਨ_ਨਾਮ ਇੱਕ ਵਾਧੂ ਕਨੈਕਸ਼ਨ ਦੁਆਰਾ ਸੈੱਟ ਕੀਤਾ ਗਿਆ ਹੈ।

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

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

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

ਅਸੀਂ, ਬੇਸ਼ੱਕ, ਬਾਊਂਸਰ ਲਈ ਇੱਕ ਛੋਟਾ ਪੈਚ ਲਿਖਿਆ ਜਿਸ ਨੇ ਇਸ ਸੈਟਿੰਗ ਨੂੰ ਜੋੜਿਆ, ਅਰਥਾਤ ਪੂਲ ਵਿੱਚ ਗਾਹਕਾਂ ਨੂੰ ਸੀਮਤ ਕਰਨਾ।

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

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

ਕਿਸੇ ਖਾਸ ਬਿੰਦੂ 'ਤੇ, ਤੁਸੀਂ ਐਪਲੀਕੇਸ਼ਨ ਗ੍ਰਾਫਾਂ ਨੂੰ ਦੇਖਦੇ ਹੋ ਅਤੇ ਦੇਖਦੇ ਹੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਕੰਮ ਨਹੀਂ ਕਰ ਰਹੀ ਹੈ।

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

ਅਸੀਂ ਇਸ ਸਿੱਟੇ 'ਤੇ ਪਹੁੰਚੇ ਹਾਂ ਕਿ ਸਾਨੂੰ ਹੋਰ PgBouncers ਦੀ ਲੋੜ ਹੈ।

https://lwn.net/Articles/542629/

ਬਾਊਂਸਰ ਨੂੰ ਥੋੜਾ ਪੈਚ ਕੀਤਾ ਗਿਆ ਹੈ।

ਅਤੇ ਉਹਨਾਂ ਨੇ ਇਸਨੂੰ ਬਣਾਇਆ ਹੈ ਤਾਂ ਜੋ TCP ਪੋਰਟ ਦੀ ਮੁੜ ਵਰਤੋਂ ਕਰਕੇ ਕਈ ਬਾਊਂਸਰ ਬਣਾਏ ਜਾ ਸਕਣ। ਅਤੇ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਰਾਉਂਡ-ਰੋਬਿਨ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਆਪਣੇ ਆਪ ਹੀ ਆਉਣ ਵਾਲੇ TCP ਕਨੈਕਸ਼ਨਾਂ ਨੂੰ ਉਹਨਾਂ ਵਿਚਕਾਰ ਟ੍ਰਾਂਸਫਰ ਕਰਦਾ ਹੈ।

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

ਅਤੇ ਇੱਕ ਨਿਸ਼ਚਿਤ ਪਲ 'ਤੇ ਤੁਸੀਂ ਦੇਖ ਸਕਦੇ ਹੋ ਕਿ ਇਹ 3 ਬਾਊਂਸਰ 100% ਦੁਆਰਾ ਆਪਣੇ ਕੋਰ ਨੂੰ ਖਾ ਜਾਂਦੇ ਹਨ। ਤੁਹਾਨੂੰ ਕਾਫ਼ੀ ਕੁਝ ਬਾਊਂਸਰਾਂ ਦੀ ਲੋੜ ਹੈ। ਕਿਉਂ?

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

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

ਅਤੇ TLS ਹੈਂਡਸ਼ੇਕ ਦੀ ਇੱਕ ਵੱਡੀ ਗਿਣਤੀ ਹੁਣ ਬਾਊਂਸਰ ਨੂੰ ਹੈਲੋ ਨਹੀਂ ਕਹਿ ਸਕਦੀ, ਪਰ ਉਸਦਾ ਗਲਾ ਦਬਾ ਦੇਵੇਗੀ। ਸਮਾਂ ਸਮਾਪਤ ਹੋਣ ਕਾਰਨ, ਆਉਣ ਵਾਲੇ ਕੁਨੈਕਸ਼ਨਾਂ ਦੀ ਲਹਿਰ ਬੇਕਾਬੂ ਹੋ ਸਕਦੀ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ ਬਿਨਾਂ ਘਾਤਕ ਬੈਕਆਫ ਦੇ ਅਧਾਰ 'ਤੇ ਮੁੜ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹੋ, ਤਾਂ ਉਹ ਇੱਕ ਅਨੁਕੂਲ ਤਰੰਗ ਵਿੱਚ ਬਾਰ ਬਾਰ ਨਹੀਂ ਆਉਣਗੇ।

ਇੱਥੇ 16 PgBouncers ਦੀ ਇੱਕ ਉਦਾਹਰਨ ਹੈ ਜੋ 16% 'ਤੇ 100 ਕੋਰ ਲੋਡ ਕਰਦੇ ਹਨ।

ਅਸੀਂ ਕੈਸਕੇਡ PgBouncer ਤੇ ਆਏ. ਇਹ ਸਭ ਤੋਂ ਵਧੀਆ ਸੰਰਚਨਾ ਹੈ ਜੋ ਬਾਊਂਸਰ ਨਾਲ ਸਾਡੇ ਲੋਡ 'ਤੇ ਪ੍ਰਾਪਤ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ। ਸਾਡੇ ਬਾਹਰੀ ਬਾਊਂਸਰਾਂ ਦੀ ਵਰਤੋਂ TCP ਹੈਂਡਸ਼ੇਕ ਲਈ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਅੰਦਰੂਨੀ ਬਾਊਂਸਰ ਅਸਲ ਪੂਲਿੰਗ ਲਈ ਵਰਤੇ ਜਾਂਦੇ ਹਨ, ਤਾਂ ਜੋ ਬਾਹਰੀ ਕਨੈਕਸ਼ਨਾਂ ਨੂੰ ਬਹੁਤ ਜ਼ਿਆਦਾ ਟੁਕੜੇ ਨਾ ਕੀਤਾ ਜਾ ਸਕੇ।

ਇਸ ਸੰਰਚਨਾ ਵਿੱਚ, ਇੱਕ ਨਿਰਵਿਘਨ ਮੁੜ ਚਾਲੂ ਕਰਨਾ ਸੰਭਵ ਹੈ. ਤੁਸੀਂ ਇਹਨਾਂ ਸਾਰੇ 18 ਬਾਊਂਸਰਾਂ ਨੂੰ ਇੱਕ-ਇੱਕ ਕਰਕੇ ਮੁੜ ਚਾਲੂ ਕਰ ਸਕਦੇ ਹੋ। ਪਰ ਅਜਿਹੀ ਸੰਰਚਨਾ ਨੂੰ ਕਾਇਮ ਰੱਖਣਾ ਕਾਫ਼ੀ ਮੁਸ਼ਕਲ ਹੈ. Sysadmins, DevOps, ਅਤੇ ਉਹ ਲੋਕ ਜੋ ਅਸਲ ਵਿੱਚ ਇਸ ਸਰਵਰ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹਨ, ਇਸ ਪ੍ਰਬੰਧ ਤੋਂ ਬਹੁਤ ਖੁਸ਼ ਨਹੀਂ ਹੋਣਗੇ।

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

https://www.postgresql.org/docs/current/libpq-cancel.html

https://github.com/pgbouncer/pgbouncer/pull/79

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

ਇਸ ਨੂੰ ਪੈਚ ਕੀਤਾ ਗਿਆ ਹੈ ਅਤੇ ਇਸ ਸਮੱਸਿਆ ਨੂੰ ਅਜੇ ਤੱਕ ਬਾਊਂਸਰ ਦੇ ਅੱਪਸਟ੍ਰੀਮ ਵਿੱਚ ਮਿਲਾਇਆ ਨਹੀਂ ਗਿਆ ਹੈ।

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

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

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

ਨਤੀਜੇ ਵਜੋਂ, ਸਾਡੇ ਕੋਲ ਇੱਕ ਥਰਿੱਡ ਹੈ ਜੋ TCP ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ ਅਤੇ ਰਾਉਂਡ-ਰੋਬਿਨ ਬਹੁਤ ਸਾਰੇ ਵਰਕਰਾਂ ਨੂੰ TPC ਕੁਨੈਕਸ਼ਨ ਪਾਸ ਕਰਦਾ ਹੈ।

ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਹਰੇਕ ਕਲਾਇੰਟ ਕੁਨੈਕਸ਼ਨ ਹਮੇਸ਼ਾ ਇੱਕ ਪ੍ਰੋਸੈਸਰ 'ਤੇ ਚੱਲਦਾ ਹੈ। ਅਤੇ ਇਹ ਤੁਹਾਨੂੰ ਇਸਨੂੰ ਕੈਸ਼-ਅਨੁਕੂਲ ਬਣਾਉਣ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ.

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

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

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

ਅਸੀਂ Yandex.Cloud ਦੇ ਹਿੱਤਾਂ ਵਿੱਚ ਕੰਮ ਕਰਦੇ ਹਾਂ। ਅਤੇ ਜੇਕਰ ਤੁਸੀਂ ਪ੍ਰਬੰਧਿਤ PostgreSQL ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋ ਅਤੇ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਕਨੈਕਸ਼ਨ ਪੂਲਰ ਸਥਾਪਿਤ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਲਾਜ਼ੀਕਲ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਬਾਹਰ ਵੱਲ ਲਾਜ਼ੀਕਲ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਬਣਾ ਸਕਦੇ ਹੋ, ਭਾਵ, ਸਾਨੂੰ ਛੱਡੋ, ਜੇਕਰ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ, ਬਾਊਂਸਰ ਲਾਜ਼ੀਕਲ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਦੇ ਪ੍ਰਵਾਹ ਨੂੰ ਬਾਹਰ ਨਹੀਂ ਛੱਡੇਗਾ।

ਇਹ ਲਾਜ਼ੀਕਲ ਰੀਪਲੀਕੇਸ਼ਨ ਸਥਾਪਤ ਕਰਨ ਦੀ ਇੱਕ ਉਦਾਹਰਨ ਹੈ।

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

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

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

ਜੇਕਰ ਤੁਹਾਨੂੰ PgBouncer ਨਾਲ 100% ਅਨੁਕੂਲਤਾ ਦੀ ਲੋੜ ਹੈ ਤਾਂ ਇਹ ਵਿਸ਼ੇਸ਼ਤਾ ਅਯੋਗ ਹੈ। ਅਸੀਂ ਬਾਊਂਸਰ ਵਾਂਗ ਹੀ ਵਿਵਹਾਰ ਕਰ ਸਕਦੇ ਹਾਂ, ਸਿਰਫ਼ ਸੁਰੱਖਿਅਤ ਪਾਸੇ ਹੋਣ ਲਈ।

ਵਿਕਾਸ

ਓਡੀਸੀ ਸਰੋਤ ਕੋਡ ਬਾਰੇ ਕੁਝ ਸ਼ਬਦ।

https://github.com/yandex/odyssey/pull/66

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

https://github.com/yandex/odyssey/pull/73 - ਪਹਿਲਾਂ ਹੀ ਜੰਮਿਆ ਹੋਇਆ ਹੈ

ਇਸ ਤੋਂ ਇਲਾਵਾ, PgBouncer ਦੀਆਂ ਨਵੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਵਿੱਚੋਂ ਇੱਕ SCRAM ਪ੍ਰਮਾਣੀਕਰਨ ਲਈ ਸਮਰਥਨ ਹੈ, ਜੋ ਸਾਡੇ ਕੋਲ ਇੱਕ ਵਿਅਕਤੀ ਦੁਆਰਾ ਲਿਆਇਆ ਗਿਆ ਸੀ ਜੋ Yandex.Cloud ਵਿੱਚ ਕੰਮ ਨਹੀਂ ਕਰਦਾ ਹੈ। ਦੋਵੇਂ ਗੁੰਝਲਦਾਰ ਕਾਰਜਸ਼ੀਲਤਾ ਅਤੇ ਮਹੱਤਵਪੂਰਨ ਹਨ.

ਇਸ ਲਈ, ਮੈਂ ਤੁਹਾਨੂੰ ਦੱਸਣਾ ਚਾਹਾਂਗਾ ਕਿ ਓਡੀਸੀ ਕਿਸ ਚੀਜ਼ ਤੋਂ ਬਣੀ ਹੈ, ਜੇਕਰ ਤੁਸੀਂ ਹੁਣੇ ਇੱਕ ਛੋਟਾ ਕੋਡ ਵੀ ਲਿਖਣਾ ਚਾਹੁੰਦੇ ਹੋ।

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

Machinarium ਲਾਇਬ੍ਰੇਰੀ ਇੱਕ ਥਰਿੱਡ ਲਾਗੂ ਕਰਨ ਵਾਲੀ ਲਾਇਬ੍ਰੇਰੀ ਹੈ। ਇਸ ਮਸ਼ੀਨੀਰੀਅਮ ਦਾ ਇੱਕ ਛੋਟਾ ਜਿਹਾ ਹਿੱਸਾ ਅਸੈਂਬਲੀ ਭਾਸ਼ਾ ਵਿੱਚ ਲਿਖਿਆ ਗਿਆ ਹੈ। ਪਰ ਘਬਰਾਓ ਨਾ, ਇੱਥੇ ਸਿਰਫ਼ 15 ਲਾਈਨਾਂ ਹਨ।

ਓਡੀਸੀ ਆਰਕੀਟੈਕਚਰ. ਇੱਥੇ ਇੱਕ ਮੁੱਖ ਮਸ਼ੀਨ ਹੈ ਜਿਸ 'ਤੇ ਕੋਰੋਟੀਨ ਚੱਲ ਰਹੇ ਹਨ। ਇਹ ਮਸ਼ੀਨ ਆਉਣ ਵਾਲੇ TCP ਕੁਨੈਕਸ਼ਨਾਂ ਨੂੰ ਸਵੀਕਾਰ ਕਰਦੀ ਹੈ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਵਰਕਰਾਂ ਵਿੱਚ ਵੰਡਦੀ ਹੈ।

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

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

ਇਸ ਤੋਂ ਇਲਾਵਾ, ਬਹੁਤ ਸਾਰੇ ਡਰਾਈਵਰ ਹਨ ਜਿਨ੍ਹਾਂ ਦੀ ਆਪਣੀ ਜਾਂਚ ਹੈ. ਅਤੇ ਅਸੀਂ ਓਡੀਸੀ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ ਉਹਨਾਂ ਦੇ ਟੈਸਟਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ.

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

ਰੈਕ

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

ਫਿਰ ਅਸੀਂ ਖੋਜਿਆ ਕਿ ਕਨੈਕਸ਼ਨ ਪੂਲਰ ਵਿੱਚ ਇਨਕਮਿੰਗ TLS ਕਨੈਕਸ਼ਨ ਅਤੇ ਆਊਟਗੋਇੰਗ TLS ਕਨੈਕਸ਼ਨ ਹਨ। ਅਤੇ ਕੁਨੈਕਸ਼ਨਾਂ ਲਈ ਕਲਾਇੰਟ ਸਰਟੀਫਿਕੇਟ ਅਤੇ ਸਰਵਰ ਸਰਟੀਫਿਕੇਟ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

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

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

ਅਸੀਂ ਇੱਕ ਸਧਾਰਨ ਕਾਰਨ ਕਰਕੇ ਇਸਨੂੰ ਲਾਗੂ ਨਹੀਂ ਕੀਤਾ। ਸਾਡੇ ਕੋਲ ਬਹੁਤ ਸਾਰੇ ਧਾਗੇ ਹਨ. ਸਾਨੂੰ ਇਸ ਦੀ ਲੋੜ ਕਿਉਂ ਹੈ?

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

ਇੱਕ ਹੋਰ ਰੇਕ ਇਹ ਸੀ ਕਿ ਸਾਡੇ ਕੋਲ ਇੱਕ ਥਰਿੱਡ ਹੈ ਜੋ ਆਉਣ ਵਾਲੇ ਸਾਰੇ ਕਨੈਕਸ਼ਨਾਂ ਨੂੰ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ। ਅਤੇ ਫਿਰ ਉਹਨਾਂ ਨੂੰ ਵਰਕਰ ਪੂਲ ਵਿੱਚ ਤਬਦੀਲ ਕਰ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ, ਜਿੱਥੇ TLS ਹੈਂਡਸ਼ੇਕ ਹੋਵੇਗਾ।

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

ਜੇਕਰ ਉਹ ਸਾਰੇ ਇੱਕੋ ਸਮੇਂ ਡੇਟਾਬੇਸ ਵਿੱਚ ਦਾਖਲ ਨਹੀਂ ਹੋ ਸਕਦੇ ਹਨ, ਤਾਂ ਉਹ ਡੇਟਾਬੇਸ ਵਿੱਚ ਦਾਖਲ ਨਹੀਂ ਹੋ ਸਕਦੇ ਹਨ, ਕਿਉਂਕਿ ਇਹ ਸਭ ਗੈਰ-ਘਾਤਕ ਮੁੜ ਕੋਸ਼ਿਸ਼ ਦੁਆਰਾ ਕਵਰ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

ਅਸੀਂ ਇਸ ਸਿੱਟੇ 'ਤੇ ਪਹੁੰਚੇ ਹਾਂ ਕਿ ਅਸੀਂ PgBouncer ਤੋਂ ਇੱਥੇ ਇਸ ਤੱਥ ਦੇ ਨਾਲ ਸਕੀਮ ਦੀ ਨਕਲ ਕੀਤੀ ਹੈ ਕਿ ਅਸੀਂ TCP ਕੁਨੈਕਸ਼ਨਾਂ ਦੀ ਗਿਣਤੀ ਨੂੰ ਥ੍ਰੋਟਲ ਕਰ ਰਹੇ ਹਾਂ ਜਿਨ੍ਹਾਂ ਨੂੰ ਅਸੀਂ ਸਵੀਕਾਰ ਕਰਦੇ ਹਾਂ।

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

ਨਿਸ਼ਾਨੇ

ਤੁਸੀਂ ਭਵਿੱਖ ਵਿੱਚ ਓਡੀਸੀ ਵਿੱਚ ਕੀ ਦੇਖਣਾ ਚਾਹੋਗੇ? ਅਸੀਂ ਆਪਣੇ ਆਪ ਨੂੰ ਵਿਕਸਤ ਕਰਨ ਲਈ ਕੀ ਤਿਆਰ ਹਾਂ ਅਤੇ ਅਸੀਂ ਸਮਾਜ ਤੋਂ ਕੀ ਉਮੀਦ ਰੱਖਦੇ ਹਾਂ?

ਅਗਸਤ 2019 ਤੱਕ।

ਅਗਸਤ ਵਿੱਚ ਓਡੀਸੀ ਰੋਡਮੈਪ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦਾ ਸੀ:

• ਅਸੀਂ SCRAM ਅਤੇ PAM ਪ੍ਰਮਾਣਿਕਤਾ ਚਾਹੁੰਦੇ ਸੀ।
• ਅਸੀਂ ਪੜ੍ਹਨ ਦੀਆਂ ਬੇਨਤੀਆਂ ਨੂੰ ਸਟੈਂਡਬਾਏ ਲਈ ਅੱਗੇ ਭੇਜਣਾ ਚਾਹੁੰਦੇ ਸੀ।
• ਮੈਂ ਇੱਕ ਔਨਲਾਈਨ ਰੀਸਟਾਰਟ ਚਾਹੁੰਦਾ ਹਾਂ।
• ਅਤੇ ਸਰਵਰ 'ਤੇ ਵਿਰਾਮ ਕਰਨ ਦੀ ਸਮਰੱਥਾ.

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

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

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

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

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

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

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

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

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

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

ਅਤੇ ਇੱਕ ਹੋਰ ਵਿਸ਼ੇਸ਼ਤਾ ਜੋ ਸਾਨੂੰ ਲਾਗੂ ਕਰਨ ਦੀ ਲੋੜ ਹੈ. ਸਾਡੇ ਕੋਲ ਹੁਣ PgBouncer ਦੇ ਅਨੁਕੂਲ ਨਿਗਰਾਨੀ ਹੈ। ਅਸੀਂ ਔਸਤ ਪੁੱਛਗਿੱਛ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਟਾਈਮ ਵਾਪਸ ਕਰ ਸਕਦੇ ਹਾਂ। ਪਰ ਔਸਤ ਸਮਾਂ ਹਸਪਤਾਲ ਵਿੱਚ ਔਸਤ ਤਾਪਮਾਨ ਹੈ: ਕੁਝ ਠੰਡੇ ਹਨ, ਕੁਝ ਨਿੱਘੇ ਹਨ - ਔਸਤਨ, ਹਰ ਕੋਈ ਸਿਹਤਮੰਦ ਹੈ। ਇਹ ਸੱਚ ਨਹੀਂ ਹੈ।

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

ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਗੱਲ ਇਹ ਹੈ ਕਿ ਮੈਨੂੰ ਸੰਸਕਰਣ 1.0 ਚਾਹੀਦਾ ਹੈ (ਵਰਜਨ 1.1 ਪਹਿਲਾਂ ਹੀ ਜਾਰੀ ਕੀਤਾ ਜਾ ਚੁੱਕਾ ਹੈ)। ਤੱਥ ਇਹ ਹੈ ਕਿ ਓਡੀਸੀ ਹੁਣ ਸੰਸਕਰਣ 1.0rc ਵਿੱਚ ਹੈ, ਯਾਨੀ ਰੀਲੀਜ਼ ਉਮੀਦਵਾਰ। ਅਤੇ ਮੈਮੋਰੀ ਲੀਕ ਨੂੰ ਛੱਡ ਕੇ, ਮੈਂ ਸੂਚੀਬੱਧ ਕੀਤੀਆਂ ਸਾਰੀਆਂ ਸਮੱਸਿਆਵਾਂ ਬਿਲਕੁਲ ਉਸੇ ਸੰਸਕਰਣ ਨਾਲ ਹੱਲ ਕੀਤੀਆਂ ਗਈਆਂ ਸਨ।

ਵਰਜਨ 1.0 ਦਾ ਸਾਡੇ ਲਈ ਕੀ ਅਰਥ ਹੋਵੇਗਾ? ਅਸੀਂ ਓਡੀਸੀ ਨੂੰ ਆਪਣੇ ਅਧਾਰਾਂ ਵਿੱਚ ਰੋਲ ਆਊਟ ਕਰ ਰਹੇ ਹਾਂ। ਇਹ ਸਾਡੇ ਡੇਟਾਬੇਸ 'ਤੇ ਪਹਿਲਾਂ ਹੀ ਚੱਲ ਰਿਹਾ ਹੈ, ਪਰ ਜਦੋਂ ਇਹ ਪ੍ਰਤੀ ਸਕਿੰਟ 1 ਬੇਨਤੀਆਂ ਦੇ ਬਿੰਦੂ ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ, ਤਾਂ ਅਸੀਂ ਕਹਿ ਸਕਦੇ ਹਾਂ ਕਿ ਇਹ ਰੀਲੀਜ਼ ਸੰਸਕਰਣ ਹੈ ਅਤੇ ਇਹ ਇੱਕ ਅਜਿਹਾ ਸੰਸਕਰਣ ਹੈ ਜਿਸ ਨੂੰ 000 ਕਿਹਾ ਜਾ ਸਕਦਾ ਹੈ।

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

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

ਇਹ ਮੇਰੇ ਹਿੱਸੇ ਦਾ ਅੰਤ ਹੈ, ਮੈਂ ਤੁਹਾਨੂੰ ਸੁਣਨਾ ਚਾਹੁੰਦਾ ਹਾਂ. ਤੁਹਾਡਾ ਧੰਨਵਾਦ!

ਤੁਹਾਡੇ ਸਵਾਲ

ਜੇਕਰ ਮੈਂ ਆਪਣਾ ਐਪਲੀਕੇਸ਼ਨ_ਨਾਮ ਸੈਟ ਕਰਦਾ ਹਾਂ, ਤਾਂ ਕੀ ਇਹ ਓਡੀਸੀ ਵਿੱਚ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਪੂਲਿੰਗ ਸਮੇਤ, ਸਹੀ ਢੰਗ ਨਾਲ ਅੱਗੇ ਭੇਜਿਆ ਜਾਵੇਗਾ?

ਓਡੀਸੀ ਜਾਂ ਬਾਊਂਸਰ?

ਓਡੀਸੀ ਵਿੱਚ. ਬਾਊਂਸਰ ਵਿੱਚ ਇਸ ਨੂੰ ਸੁੱਟਿਆ ਜਾਂਦਾ ਹੈ।

ਅਸੀਂ ਇੱਕ ਸੈੱਟ ਕਰਾਂਗੇ।

ਅਤੇ ਜੇਕਰ ਮੇਰਾ ਅਸਲ ਕੁਨੈਕਸ਼ਨ ਦੂਜੇ ਕੁਨੈਕਸ਼ਨਾਂ 'ਤੇ ਛਾਲ ਮਾਰਦਾ ਹੈ, ਤਾਂ ਕੀ ਇਹ ਸੰਚਾਰਿਤ ਹੋਵੇਗਾ?

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

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

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

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

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

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

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

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

ਹਾਂ, ਭਾਰ ਵਧਾਓ।

ਇਹ ਇੱਕ ਚੰਗਾ ਵਿਚਾਰ ਹੈ। ਪਰ ਪਹਿਲਾਂ ਸਾਨੂੰ ਇਸ ਬੰਦ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਪਹਿਲਾਂ ਸਾਨੂੰ ਬੰਦ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਅਤੇ ਫਿਰ ਅਸੀਂ ਇਸ ਬਾਰੇ ਸੋਚਾਂਗੇ ਕਿ ਕਿਵੇਂ ਚਾਲੂ ਕਰਨਾ ਹੈ। ਇਹ ਸੁਚਾਰੂ ਢੰਗ ਨਾਲ ਯੋਗ ਕਰਨ ਲਈ ਇੱਕ ਵਧੀਆ ਵਿਸ਼ੇਸ਼ਤਾ ਹੈ.

Nginx ਕੋਲ ਇਹ ਵਿਕਲਪ ਹੈ slowly start ਸਰਵਰ ਲਈ ਇੱਕ ਕਲੱਸਟਰ ਵਿੱਚ. ਅਤੇ ਉਹ ਹੌਲੀ ਹੌਲੀ ਭਾਰ ਵਧਾਉਂਦਾ ਹੈ.

ਹਾਂ, ਬਹੁਤ ਵਧੀਆ ਵਿਚਾਰ, ਅਸੀਂ ਇਸਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਾਂਗੇ ਜਦੋਂ ਅਸੀਂ ਇਸਦੇ ਆਲੇ ਦੁਆਲੇ ਪਹੁੰਚਦੇ ਹਾਂ.

ਸਰੋਤ: www.habr.com