ਜਾਣ ਪਛਾਣ

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

ਇਸ ਫੈਸਲੇ ਨੇ ਇੱਕ ਵਾਜਬ ਸਵਾਲ ਖੜ੍ਹਾ ਕੀਤਾ: ਇੱਕ ਫੇਲਓਵਰ ਕਲੱਸਟਰ ਕਿੰਨਾ ਨੁਕਸ-ਸਹਿਣਸ਼ੀਲ ਹੋਵੇਗਾ? ਇਸਦੀ ਜਾਂਚ ਕਰਨ ਲਈ, ਮੈਂ ਇੱਕ ਟੈਸਟ ਬੈਂਚ ਵਿਕਸਤ ਕੀਤਾ ਜੋ ਕਲੱਸਟਰ ਨੋਡਾਂ 'ਤੇ ਵੱਖ-ਵੱਖ ਅਸਫਲਤਾਵਾਂ ਦੀ ਨਕਲ ਕਰਦਾ ਹੈ, ਸੇਵਾ ਦੇ ਮੁੜ ਬਹਾਲ ਹੋਣ ਦੀ ਉਡੀਕ ਕਰਦਾ ਹੈ, ਅਸਫਲ ਨੋਡ ਨੂੰ ਮੁੜ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ, ਅਤੇ ਇੱਕ ਲੂਪ ਵਿੱਚ ਟੈਸਟਿੰਗ ਜਾਰੀ ਰੱਖਦਾ ਹੈ। ਇਸ ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਅਸਲ ਵਿੱਚ hapgsql ਕਿਹਾ ਜਾਂਦਾ ਸੀ, ਪਰ ਸਮੇਂ ਦੇ ਨਾਲ ਮੈਂ ਨਾਮ ਤੋਂ ਬੋਰ ਹੋ ਗਿਆ, ਜਿਸ ਵਿੱਚ ਸਿਰਫ ਇੱਕ ਸਵਰ ਸੀ। ਇਸ ਲਈ, ਮੈਂ ਨੁਕਸ-ਸਹਿਣਸ਼ੀਲ ਡੇਟਾਬੇਸ ਨੂੰ ਕਾਲ ਕਰਨਾ ਸ਼ੁਰੂ ਕੀਤਾ (ਅਤੇ ਫਲੋਟ ਆਈਪੀ ਉਹਨਾਂ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ) krogan (ਇੱਕ ਕੰਪਿਊਟਰ ਗੇਮ ਦਾ ਇੱਕ ਅੱਖਰ ਜਿਸ ਵਿੱਚ ਸਾਰੇ ਮਹੱਤਵਪੂਰਨ ਅੰਗ ਡੁਪਲੀਕੇਟ ਕੀਤੇ ਜਾਂਦੇ ਹਨ), ਅਤੇ ਨੋਡ, ਕਲੱਸਟਰ ਅਤੇ ਪ੍ਰੋਜੈਕਟ ਆਪਣੇ ਆਪ ਵਿੱਚ ਹਨ ਤੁਚੰਕਾ (ਗ੍ਰਹਿ ਜਿੱਥੇ ਕ੍ਰੋਗਨ ਰਹਿੰਦੇ ਹਨ)।

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

ਕਲੱਸਟਰ ਵਰਚੁਅਲ ਮਸ਼ੀਨਾਂ 'ਤੇ ਤਾਇਨਾਤ ਕੀਤੇ ਗਏ ਹਨ ਵਰਚੁਅਲਬੌਕਸ. ਕੁੱਲ 12 ਵਰਚੁਅਲ ਮਸ਼ੀਨਾਂ (ਕੁੱਲ 36GiB) ਤਾਇਨਾਤ ਕੀਤੀਆਂ ਜਾਣਗੀਆਂ, ਜੋ ਕਿ 4 ਨੁਕਸ-ਸਹਿਣਸ਼ੀਲ ਕਲੱਸਟਰ (ਵੱਖ-ਵੱਖ ਵਿਕਲਪ) ਬਣਾਉਂਦੀਆਂ ਹਨ। ਪਹਿਲੇ ਦੋ ਕਲੱਸਟਰਾਂ ਵਿੱਚ ਦੋ PostgreSQL ਸਰਵਰ ਹੁੰਦੇ ਹਨ, ਜੋ ਕਿ ਵੱਖ-ਵੱਖ ਡਾਟਾ ਸੈਂਟਰਾਂ ਵਿੱਚ ਸਥਿਤ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਇੱਕ ਸਾਂਝਾ ਸਰਵਰ ਗਵਾਹ c ਕੋਰਮ ਜੰਤਰ (ਇੱਕ ਤੀਜੇ ਡੇਟਾ ਸੈਂਟਰ ਵਿੱਚ ਇੱਕ ਸਸਤੀ ਵਰਚੁਅਲ ਮਸ਼ੀਨ 'ਤੇ ਹੋਸਟ ਕੀਤਾ ਗਿਆ), ਜੋ ਅਨਿਸ਼ਚਿਤਤਾ ਨੂੰ ਹੱਲ ਕਰਦਾ ਹੈ 50% / 50%, ਪਾਰਟੀ ਵਿੱਚੋਂ ਕਿਸੇ ਇੱਕ ਨੂੰ ਆਪਣੀ ਵੋਟ ਦੇਣਾ। ਤਿੰਨ ਡਾਟਾ ਸੈਂਟਰਾਂ ਵਿੱਚ ਤੀਜਾ ਕਲੱਸਟਰ: ਇੱਕ ਮਾਲਕ, ਦੋ ਨੌਕਰ, ਨੰ ਕੋਰਮ ਜੰਤਰ. ਚੌਥੇ ਕਲੱਸਟਰ ਵਿੱਚ ਚਾਰ PostgreSQL ਸਰਵਰ ਹੁੰਦੇ ਹਨ, ਦੋ ਪ੍ਰਤੀ ਡਾਟਾ ਸੈਂਟਰ: ਇੱਕ ਮਾਸਟਰ, ਬਾਕੀ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ, ਅਤੇ ਇਹ ਵੀ ਵਰਤਦਾ ਹੈ ਗਵਾਹ c ਕੋਰਮ ਜੰਤਰ. ਚੌਥਾ ਦੋ ਸਰਵਰਾਂ ਜਾਂ ਇੱਕ ਡਾਟਾ ਸੈਂਟਰ ਦੀ ਅਸਫਲਤਾ ਦਾ ਸਾਮ੍ਹਣਾ ਕਰ ਸਕਦਾ ਹੈ. ਜੇ ਲੋੜ ਹੋਵੇ ਤਾਂ ਇਸ ਘੋਲ ਨੂੰ ਵੱਡੀ ਗਿਣਤੀ ਵਿੱਚ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਤੱਕ ਸਕੇਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

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

ਵਰਜਨ

v0. VirtualBox 7 'ਤੇ CentOS 11 ਅਤੇ PostgreSQL 6.1 ਨਾਲ ਕੰਮ ਕਰਦਾ ਹੈ।

ਕਲੱਸਟਰ ਬਣਤਰ

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

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

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

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

ਤੁਚੰਕਾ 1 (ਕੰਪੈਕਸ਼ਨ ਵਾਲਾ ਸਰਕਟ)

ਬਣਤਰ

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

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

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

ਗਵਾਹੀ ਦੇਣ ਵਿੱਚ ਅਸਫਲ

ਗਵਾਹੀ ਦੇਣ ਵਿੱਚ ਅਸਫਲ (ਕੋਰਮ ਜੰਤਰ) ਮੈਂ ਸਿਰਫ਼ Tuchanka1 ਕਲੱਸਟਰ ਲਈ ਵਿਚਾਰ ਕਰਾਂਗਾ, ਬਾਕੀ ਸਭ ਦੇ ਨਾਲ ਇਹ ਉਹੀ ਕਹਾਣੀ ਹੋਵੇਗੀ। ਜੇਕਰ ਗਵਾਹ ਫੇਲ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਕਲੱਸਟਰ ਢਾਂਚੇ ਵਿੱਚ ਕੁਝ ਵੀ ਨਹੀਂ ਬਦਲੇਗਾ, ਸਭ ਕੁਝ ਉਸੇ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਨਾ ਜਾਰੀ ਰੱਖੇਗਾ ਜਿਵੇਂ ਇਹ ਕੀਤਾ ਗਿਆ ਸੀ। ਪਰ ਕੋਰਮ 2 ਵਿੱਚੋਂ 3 ਬਣ ਜਾਵੇਗਾ, ਅਤੇ ਇਸਲਈ ਕੋਈ ਵੀ ਅਗਲੀ ਅਸਫਲਤਾ ਕਲੱਸਟਰ ਲਈ ਘਾਤਕ ਹੋਵੇਗੀ। ਇਸ ਨੂੰ ਅਜੇ ਵੀ ਤੁਰੰਤ ਠੀਕ ਕਰਨਾ ਹੋਵੇਗਾ।

ਤੁਚੰਕਾ੧ ਇਨਕਾਰ

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

ਤੁਚੰਕਾ 2 (ਕਲਾਸੀਕਲ)

ਬਣਤਰ

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

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

ਤੁਚੰਕਾ੧ ਇਨਕਾਰ

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

ਤੁਚੰਕਾ੪ (ਬਹੁਤ ਸਾਰੇ ਦਾਸ)

ਬਣਤਰ

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

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

ਤੁਚੰਕਾ੧ ਇਨਕਾਰ

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

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

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

Tuchanka3 (3 ਡਾਟਾ ਸੈਂਟਰ)

ਬਣਤਰ

ਇਹ ਇੱਕ ਅਜਿਹੀ ਸਥਿਤੀ ਲਈ ਇੱਕ ਕਲੱਸਟਰ ਹੈ ਜਿੱਥੇ ਤਿੰਨ ਪੂਰੀ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਨ ਵਾਲੇ ਡੇਟਾ ਸੈਂਟਰ ਹਨ, ਜਿਨ੍ਹਾਂ ਵਿੱਚੋਂ ਹਰੇਕ ਵਿੱਚ ਇੱਕ ਪੂਰੀ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਨ ਵਾਲਾ ਡਾਟਾਬੇਸ ਸਰਵਰ ਹੈ। ਇਸ ਮਾਮਲੇ ਵਿੱਚ ਕੋਰਮ ਜੰਤਰ ਲੋੜ ਨਹੀਂ ਇੱਕ ਡੇਟਾ ਸੈਂਟਰ ਵਿੱਚ ਇੱਕ ਮਾਸਟਰ ਦੁਆਰਾ ਸਟਾਫ਼ ਹੈ, ਦੂਜੇ ਦੋ ਨੌਕਰਾਂ ਦੁਆਰਾ ਸਟਾਫ਼ ਹਨ. ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਸਮਕਾਲੀ ਹੈ, ਕੋਈ ਵੀ ਟਾਈਪ ਕਰੋ (ਸਲੇਵ 1, ਸਲੇਵ 2), ਭਾਵ, ਕਲਾਇੰਟ ਨੂੰ ਇੱਕ ਵਚਨਬੱਧਤਾ ਦੀ ਪੁਸ਼ਟੀ ਮਿਲੇਗੀ ਜਦੋਂ ਕੋਈ ਵੀ ਸਲੇਵ ਜਵਾਬ ਦੇਣ ਵਾਲਾ ਪਹਿਲਾ ਹੁੰਦਾ ਹੈ ਕਿ ਉਸਨੇ ਵਚਨਬੱਧਤਾ ਨੂੰ ਸਵੀਕਾਰ ਕਰ ਲਿਆ ਹੈ। ਸਰੋਤਾਂ ਨੂੰ ਮਾਸਟਰ ਲਈ ਇੱਕ ਫਲੋਟ IP ਅਤੇ ਦੋ ਨੌਕਰਾਂ ਲਈ ਦਰਸਾਏ ਜਾਂਦੇ ਹਨ। Tuchanka4 ਦੇ ਉਲਟ, ਸਾਰੇ ਤਿੰਨ ਫਲੋਟ IP ਨੁਕਸ-ਸਹਿਣਸ਼ੀਲ ਹਨ। ਸਿਰਫ਼-ਪੜ੍ਹਨ ਲਈ SQL ਸਵਾਲਾਂ ਨੂੰ ਸੰਤੁਲਿਤ ਕਰਨ ਲਈ ਤੁਸੀਂ ਵਰਤ ਸਕਦੇ ਹੋ sql ਪਰਾਕਸੀ (ਵੱਖਰੇ ਨੁਕਸ ਸਹਿਣਸ਼ੀਲਤਾ ਦੇ ਨਾਲ), ਜਾਂ ਅੱਧੇ ਗਾਹਕਾਂ ਨੂੰ ਇੱਕ ਸਲੇਵ ਫਲੋਟ IP, ਅਤੇ ਦੂਜੇ ਅੱਧ ਨੂੰ ਦੂਜੇ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰੋ।

ਤੁਚੰਕਾ੧ ਇਨਕਾਰ

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

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

ਆਟੋਮੈਟਿਕ ਟੈਸਟਿੰਗ ਸਿਸਟਮ

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

test/failure 2 3

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

ਟਰਮੀਨਲ ਨੂੰ ਟੈਸਟ ਕੀਤੇ ਜਾ ਰਹੇ ਕਲੱਸਟਰਾਂ ਦੀ ਗਿਣਤੀ ਦੇ ਅਨੁਸਾਰ ਕਾਲਮਾਂ ਵਿੱਚ ਵੰਡਿਆ ਗਿਆ ਹੈ; ਮੂਲ ਰੂਪ ਵਿੱਚ (ਸਕ੍ਰੀਨਸ਼ਾਟ ਵਿੱਚ) ਚਾਰ ਹਨ। ਮੈਂ Tuchanka2 ਦੀ ਉਦਾਹਰਨ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਕਾਲਮਾਂ ਦੀ ਸਮੱਗਰੀ ਦਾ ਵਰਣਨ ਕਰਾਂਗਾ। ਸਕ੍ਰੀਨਸ਼ੌਟ ਵਿੱਚ ਪੈਨਲਾਂ ਨੂੰ ਨੰਬਰ ਦਿੱਤਾ ਗਿਆ ਹੈ:

1. ਟੈਸਟ ਦੇ ਅੰਕੜੇ ਇੱਥੇ ਪ੍ਰਦਰਸ਼ਿਤ ਕੀਤੇ ਗਏ ਹਨ। ਕਾਲਮ:
   • ਅਸਫਲਤਾ - ਟੈਸਟ ਦਾ ਨਾਮ (ਸਕ੍ਰਿਪਟ ਵਿੱਚ ਫੰਕਸ਼ਨ) ਜੋ ਨੁਕਸ ਦੀ ਨਕਲ ਕਰਦਾ ਹੈ।
   • ਪ੍ਰਤੀਕਰਮ - ਸਕਿੰਟਾਂ ਵਿੱਚ ਅੰਕਗਣਿਤ ਔਸਤ ਸਮਾਂ ਜਿਸ ਦੌਰਾਨ ਕਲੱਸਟਰ ਨੇ ਆਪਣੀ ਕਾਰਜਕੁਸ਼ਲਤਾ ਮੁੜ ਪ੍ਰਾਪਤ ਕੀਤੀ। ਇਹ ਸਕ੍ਰਿਪਟ ਦੀ ਸ਼ੁਰੂਆਤ ਤੋਂ ਲੈ ਕੇ ਕਿਸੇ ਨੁਕਸ ਦੀ ਨਕਲ ਕਰਨ ਤੋਂ ਉਸ ਪਲ ਤੱਕ ਮਾਪਿਆ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਕਲੱਸਟਰ ਆਪਣੀ ਕਾਰਜਕੁਸ਼ਲਤਾ ਨੂੰ ਬਹਾਲ ਕਰਦਾ ਹੈ ਅਤੇ ਸੇਵਾਵਾਂ ਪ੍ਰਦਾਨ ਕਰਨਾ ਜਾਰੀ ਰੱਖਣ ਦੇ ਯੋਗ ਹੁੰਦਾ ਹੈ। ਜੇ ਸਮਾਂ ਬਹੁਤ ਛੋਟਾ ਹੈ, ਉਦਾਹਰਨ ਲਈ, ਛੇ ਸਕਿੰਟ (ਇਹ ਕਈ ਗੁਲਾਮਾਂ (Tuchanka3 ਅਤੇ Tuchanka4) ਦੇ ਨਾਲ ਕਲੱਸਟਰਾਂ ਵਿੱਚ ਵਾਪਰਦਾ ਹੈ), ਇਸ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਨੁਕਸ ਅਸਿੰਕਰੋਨਸ ਸਲੇਵ 'ਤੇ ਸੀ ਅਤੇ ਕਿਸੇ ਵੀ ਤਰੀਕੇ ਨਾਲ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਨਹੀਂ ਕਰਦਾ ਸੀ; ਕੋਈ ਨਹੀਂ ਸਨ ਕਲੱਸਟਰ ਸਟੇਟ ਸਵਿੱਚ.
   • ਭਟਕਣਾ — ਮੁੱਲ ਦਾ ਫੈਲਾਅ (ਸ਼ੁੱਧਤਾ) ਦਿਖਾਉਂਦਾ ਹੈ ਪ੍ਰਤੀਕਰਮ ਮਿਆਰੀ ਵਿਵਹਾਰ ਵਿਧੀ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ.
   • ਦੀ ਗਿਣਤੀ - ਇਹ ਟੈਸਟ ਕਿੰਨੀ ਵਾਰ ਕੀਤਾ ਗਿਆ ਸੀ।
2. ਇੱਕ ਛੋਟਾ ਲੌਗ ਤੁਹਾਨੂੰ ਇਹ ਮੁਲਾਂਕਣ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ ਕਿ ਕਲੱਸਟਰ ਵਰਤਮਾਨ ਵਿੱਚ ਕੀ ਕਰ ਰਿਹਾ ਹੈ। ਦੁਹਰਾਓ (ਟੈਸਟ) ਨੰਬਰ, ਟਾਈਮਸਟੈਂਪ ਅਤੇ ਓਪਰੇਸ਼ਨ ਦਾ ਨਾਮ ਪ੍ਰਦਰਸ਼ਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਬਹੁਤ ਲੰਮਾ ਚੱਲਣਾ (> 5 ਮਿੰਟ) ਇੱਕ ਸਮੱਸਿਆ ਦਰਸਾਉਂਦਾ ਹੈ।
3. ਦਿਲ (ਦਿਲ) - ਮੌਜੂਦਾ ਸਮਾਂ. ਪ੍ਰਦਰਸ਼ਨ ਦੇ ਵਿਜ਼ੂਅਲ ਮੁਲਾਂਕਣ ਲਈ ਮਾਸਟਰ ਮੌਜੂਦਾ ਸਮਾਂ ਫਲੋਟ ਆਈਪੀ ਮਾਸਟਰ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇਸਦੇ ਸਾਰਣੀ ਵਿੱਚ ਲਗਾਤਾਰ ਲਿਖਿਆ ਜਾਂਦਾ ਹੈ। ਜੇਕਰ ਸਫਲ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਨਤੀਜਾ ਇਸ ਪੈਨਲ ਵਿੱਚ ਪ੍ਰਦਰਸ਼ਿਤ ਹੁੰਦਾ ਹੈ।
4. ਬੀਟ (ਨਬਜ਼) - "ਮੌਜੂਦਾ ਸਮਾਂ", ਜੋ ਪਹਿਲਾਂ ਸਕ੍ਰਿਪਟ ਦੁਆਰਾ ਰਿਕਾਰਡ ਕੀਤਾ ਗਿਆ ਸੀ ਦਿਲ ਮਾਸਟਰ ਕਰਨ ਲਈ, ਹੁਣ ਤੱਕ ਪੜ੍ਹੋ ਗੁਲਾਮ ਇਸਦੇ ਫਲੋਟ ਆਈਪੀ ਦੁਆਰਾ. ਤੁਹਾਨੂੰ ਸਲੇਵ ਅਤੇ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਦੇ ਪ੍ਰਦਰਸ਼ਨ ਦਾ ਦ੍ਰਿਸ਼ਟੀਗਤ ਮੁਲਾਂਕਣ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ। ਤੁਚੰਕਾ 1 ਵਿੱਚ ਫਲੋਟ ਆਈਪੀ (ਸੇਵਾਵਾਂ ਪ੍ਰਦਾਨ ਕਰਨ ਵਾਲੇ ਕੋਈ ਗੁਲਾਮ ਨਹੀਂ) ਵਾਲੇ ਕੋਈ ਗੁਲਾਮ ਨਹੀਂ ਹਨ, ਪਰ ਦੋ ਉਦਾਹਰਣਾਂ (ਡੀਬੀ) ਹਨ, ਇਸਲਈ ਇਹ ਇੱਥੇ ਨਹੀਂ ਦਿਖਾਇਆ ਜਾਵੇਗਾ। ਬੀਟਅਤੇ ਦਿਲ ਦੂਜੀ ਮਿਸਾਲ.
5. ਉਪਯੋਗਤਾ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਕਲੱਸਟਰ ਦੀ ਸਿਹਤ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨਾ pcs mon. ਬਣਤਰ, ਨੋਡਾਂ ਵਿੱਚ ਸਰੋਤਾਂ ਦੀ ਵੰਡ ਅਤੇ ਹੋਰ ਉਪਯੋਗੀ ਜਾਣਕਾਰੀ ਦਿਖਾਉਂਦਾ ਹੈ।
6. ਕਲੱਸਟਰ ਵਿੱਚ ਹਰੇਕ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਤੋਂ ਸਿਸਟਮ ਨਿਗਰਾਨੀ ਇੱਥੇ ਪ੍ਰਦਰਸ਼ਿਤ ਕੀਤੀ ਗਈ ਹੈ। ਕਲੱਸਟਰ ਵਿੱਚ ਕਿੰਨੀਆਂ ਵਰਚੁਅਲ ਮਸ਼ੀਨਾਂ ਹਨ ਇਸ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹੋਏ ਅਜਿਹੇ ਹੋਰ ਪੈਨਲ ਹੋ ਸਕਦੇ ਹਨ। ਦੋ ਗ੍ਰਾਫ਼ CPU ਲੋਡ (ਵਰਚੁਅਲ ਮਸ਼ੀਨਾਂ ਵਿੱਚ ਦੋ ਪ੍ਰੋਸੈਸਰ ਹੁੰਦੇ ਹਨ), ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਦਾ ਨਾਮ, ਸਿਸਟਮ ਲੋਡ (ਲੋਡ ਔਸਤ ਨਾਮ ਦਿੱਤਾ ਗਿਆ ਹੈ ਕਿਉਂਕਿ ਇਹ 5, 10 ਅਤੇ 15 ਮਿੰਟਾਂ ਤੋਂ ਵੱਧ ਔਸਤ ਹੈ), ਪ੍ਰਕਿਰਿਆ ਡੇਟਾ ਅਤੇ ਮੈਮੋਰੀ ਵੰਡ।
7. ਸਕ੍ਰਿਪਟ ਦਾ ਟਰੇਸ ਪ੍ਰਦਰਸ਼ਨ ਟੈਸਟਿੰਗ। ਖਰਾਬੀ ਦੀ ਸਥਿਤੀ ਵਿੱਚ - ਓਪਰੇਸ਼ਨ ਵਿੱਚ ਅਚਾਨਕ ਰੁਕਾਵਟ ਜਾਂ ਇੱਕ ਬੇਅੰਤ ਉਡੀਕ ਚੱਕਰ - ਇੱਥੇ ਤੁਸੀਂ ਇਸ ਵਿਵਹਾਰ ਦਾ ਕਾਰਨ ਦੇਖ ਸਕਦੇ ਹੋ.

ਟੈਸਟਿੰਗ ਦੋ ਪੜਾਵਾਂ ਵਿੱਚ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਪਹਿਲਾਂ, ਸਕ੍ਰਿਪਟ ਹਰ ਕਿਸਮ ਦੇ ਟੈਸਟਾਂ ਵਿੱਚੋਂ ਲੰਘਦੀ ਹੈ, ਬੇਤਰਤੀਬੇ ਇੱਕ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਦੀ ਚੋਣ ਕਰਦੀ ਹੈ ਜਿਸ ਵਿੱਚ ਇਹ ਟੈਸਟ ਲਾਗੂ ਕਰਨਾ ਹੈ। ਫਿਰ ਟੈਸਟਿੰਗ ਦਾ ਇੱਕ ਬੇਅੰਤ ਚੱਕਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਵਰਚੁਅਲ ਮਸ਼ੀਨਾਂ ਅਤੇ ਨੁਕਸ ਹਰ ਵਾਰ ਬੇਤਰਤੀਬੇ ਚੁਣੇ ਜਾਂਦੇ ਹਨ। ਟੈਸਟਿੰਗ ਸਕ੍ਰਿਪਟ (ਹੇਠਲੇ ਪੈਨਲ) ਦੀ ਅਚਾਨਕ ਸਮਾਪਤੀ ਜਾਂ ਕਿਸੇ ਚੀਜ਼ ਦੀ ਉਡੀਕ ਕਰਨ ਦਾ ਇੱਕ ਬੇਅੰਤ ਲੂਪ (> ਇੱਕ ਓਪਰੇਸ਼ਨ ਲਈ 5 ਮਿੰਟ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਸਮਾਂ, ਇਹ ਟਰੇਸ ਵਿੱਚ ਦੇਖਿਆ ਜਾ ਸਕਦਾ ਹੈ) ਇਹ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਇਸ ਕਲੱਸਟਰ ਦੇ ਕੁਝ ਟੈਸਟ ਫੇਲ੍ਹ ਹੋ ਗਏ ਹਨ।

ਹਰੇਕ ਟੈਸਟ ਵਿੱਚ ਹੇਠ ਲਿਖੇ ਓਪਰੇਸ਼ਨ ਹੁੰਦੇ ਹਨ:

1. ਇੱਕ ਫੰਕਸ਼ਨ ਲਾਂਚ ਕਰੋ ਜੋ ਇੱਕ ਨੁਕਸ ਦੀ ਨਕਲ ਕਰਦਾ ਹੈ।
2. ਤਿਆਰ ਹੋ? — ਕਲੱਸਟਰ ਨੂੰ ਬਹਾਲ ਕੀਤੇ ਜਾਣ ਦੀ ਉਡੀਕ (ਜਦੋਂ ਸਾਰੀਆਂ ਸੇਵਾਵਾਂ ਪ੍ਰਦਾਨ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ)।
3. ਕਲੱਸਟਰ ਰਿਕਵਰੀ ਟਾਈਮਆਉਟ ਦਿਖਾਉਂਦਾ ਹੈ (ਪ੍ਰਤੀਕਰਮ).
4. ਫਿਕਸ - ਕਲੱਸਟਰ ਦੀ "ਮੁਰੰਮਤ" ਕੀਤੀ ਜਾ ਰਹੀ ਹੈ। ਜਿਸ ਤੋਂ ਬਾਅਦ ਇਸਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਕਾਰਜਸ਼ੀਲ ਸਥਿਤੀ ਵਿੱਚ ਵਾਪਸ ਆਉਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਅਗਲੀ ਖਰਾਬੀ ਲਈ ਤਿਆਰ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ।

ਇੱਥੇ ਟੈਸਟਾਂ ਦੀ ਇੱਕ ਸੂਚੀ ਹੈ ਜਿਸ ਵਿੱਚ ਉਹ ਕੀ ਕਰਦੇ ਹਨ:

• ਫੋਰਕਬੌਮ: ਫੋਰਕ ਬੰਬ ਦੀ ਵਰਤੋਂ ਕਰਕੇ "ਮੈਮੋਰੀ ਤੋਂ ਬਾਹਰ" ਬਣਾਉਂਦਾ ਹੈ।
• ਸਪੇਸ ਤੋਂ ਬਾਹਰ: ਹਾਰਡ ਡਰਾਈਵ ਭਰ ਗਈ ਹੈ। ਪਰ ਟੈਸਟ ਇਸ ਦੀ ਬਜਾਏ ਪ੍ਰਤੀਕਾਤਮਕ ਹੈ; ਮਾਮੂਲੀ ਲੋਡ ਦੇ ਨਾਲ ਜੋ ਟੈਸਟਿੰਗ ਦੌਰਾਨ ਬਣਾਇਆ ਗਿਆ ਹੈ, PostgreSQL ਆਮ ਤੌਰ 'ਤੇ ਉਦੋਂ ਅਸਫਲ ਨਹੀਂ ਹੁੰਦਾ ਜਦੋਂ ਹਾਰਡ ਡਰਾਈਵ ਭਰ ਜਾਂਦੀ ਹੈ।
• Postgres-KILL: ਕਮਾਂਡ ਨਾਲ PostgreSQL ਨੂੰ ਮਾਰਦਾ ਹੈ killall -KILL postgres.
• ਪੋਸਟਗ੍ਰੇਸ-ਸਟਾਪ: PostgreSQL ਕਮਾਂਡ ਲਟਕਦੀ ਹੈ killall -STOP postgres.
• ਬਿਜਲੀ ਦੀ ਬੰਦ: ਕਮਾਂਡ ਨਾਲ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਨੂੰ "ਡੀ-ਐਨਰਜੀਜ਼" ਕਰਦਾ ਹੈ VBoxManage controlvm "виртуалка" poweroff.
• ਰੀਸੈੱਟ: ਕਮਾਂਡ ਨਾਲ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਨੂੰ ਓਵਰਲੋਡ ਕਰਦਾ ਹੈ VBoxManage controlvm "виртуалка" reset.
• SBD-ਸਟਾਪ: ਕਮਾਂਡ ਨਾਲ SBD ਭੂਤ ਨੂੰ ਮੁਅੱਤਲ ਕਰਦਾ ਹੈ killall -STOP sbd.
• ਸ਼ਟ ਡਾਉਨ: SSH ਰਾਹੀਂ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਨੂੰ ਕਮਾਂਡ ਭੇਜਦਾ ਹੈ systemctl poweroff, ਸਿਸਟਮ ਸ਼ਾਨਦਾਰ ਤਰੀਕੇ ਨਾਲ ਬੰਦ ਹੋ ਜਾਂਦਾ ਹੈ।
• ਅਣਲਿੰਕ ਕਰੋ: ਨੈੱਟਵਰਕ ਆਈਸੋਲੇਸ਼ਨ, ਕਮਾਂਡ VBoxManage controlvm "виртуалка" setlinkstate1 off.

ਜਾਂ ਤਾਂ ਮਿਆਰੀ tmux ਕਮਾਂਡ "kill-window" ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਟੈਸਟਿੰਗ ਨੂੰ ਪੂਰਾ ਕਰਨਾ Ctrl-b &, ਜਾਂ "detach-client" ਕਮਾਂਡ Ctrl-b d: ਇਸ ਸਮੇਂ ਟੈਸਟਿੰਗ ਖਤਮ ਹੋ ਜਾਂਦੀ ਹੈ, tmux ਬੰਦ ਹੋ ਜਾਂਦਾ ਹੈ, ਵਰਚੁਅਲ ਮਸ਼ੀਨਾਂ ਬੰਦ ਹੋ ਜਾਂਦੀਆਂ ਹਨ।

ਜਾਂਚ ਦੌਰਾਨ ਪਛਾਣੀਆਂ ਗਈਆਂ ਸਮੱਸਿਆਵਾਂ

• ਇਸ ਮੌਕੇ ਤੇ ਵਾਚਡੌਗ ਡੈਮਨ ਐਸ.ਬੀ.ਡੀ ਦੇਖਿਆ ਗਿਆ ਡੈਮਨ ਨੂੰ ਰੋਕਣ 'ਤੇ ਕੰਮ ਕਰਦਾ ਹੈ, ਪਰ ਉਹਨਾਂ ਨੂੰ ਫ੍ਰੀਜ਼ ਕਰਨ 'ਤੇ ਨਹੀਂ। ਅਤੇ, ਨਤੀਜੇ ਵਜੋਂ, ਨੁਕਸ ਜੋ ਸਿਰਫ ਫ੍ਰੀਜ਼ਿੰਗ ਦੀ ਅਗਵਾਈ ਕਰਦੇ ਹਨ ਕੋਰੋਸਿੰਕ и ਪੇਸਮੇਕਰ, ਪਰ ਲਟਕਿਆ ਨਹੀਂ sbd... ਜਾਂਚ ਲਈ ਕੋਰੋਸਿੰਕ ਪਹਿਲਾਂ ਹੀ ਹੈ PR#83 (GitHub 'ਤੇ sbd), ਧਾਗੇ ਨੂੰ ਸਵੀਕਾਰ ਕੀਤਾ ਗਿਆ ਮਾਸਟਰ. ਉਹਨਾਂ ਨੇ ਵਾਅਦਾ ਕੀਤਾ (PR#83 ਵਿੱਚ) ਕਿ ਪੇਸਮੇਕਰ ਲਈ ਕੁਝ ਅਜਿਹਾ ਹੀ ਹੋਵੇਗਾ, ਮੈਨੂੰ ਉਮੀਦ ਹੈ ਕਿ ਇਸ ਦੁਆਰਾ ਰੈਡਹੱਟ 8 ਕਰਣਗੇ. ਪਰ ਅਜਿਹੇ "ਨੁਕਸਾਨ" ਅੰਦਾਜ਼ੇ ਵਾਲੇ ਹੁੰਦੇ ਹਨ ਅਤੇ ਆਸਾਨੀ ਨਾਲ ਨਕਲੀ ਢੰਗ ਨਾਲ ਨਕਲ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ, ਉਦਾਹਰਨ ਲਈ, killall -STOP corosync, ਪਰ ਅਸਲ ਜ਼ਿੰਦਗੀ ਵਿੱਚ ਕਦੇ ਨਹੀਂ ਮਿਲਦੇ।

• У ਪੇਸਮੇਕਰ ਲਈ ਵਰਜਨ ਵਿੱਚ CentOS 7 ਗਲਤ ਢੰਗ ਨਾਲ ਸੈੱਟ ਕੀਤਾ ਸਿੰਕ_ਟਾਈਮਆਊਟ у ਕੋਰਮ ਜੰਤਰ, ਫਲਸਰੂਪ ਜੇਕਰ ਇੱਕ ਨੋਡ ਫੇਲ੍ਹ ਹੋ ਜਾਂਦਾ ਹੈ, ਕੁਝ ਸੰਭਾਵਨਾ ਦੇ ਨਾਲ ਦੂਜਾ ਨੋਡ ਵੀ ਰੀਬੂਟ ਹੁੰਦਾ ਹੈ, ਜਿਸ ਵੱਲ ਮਾਸਟਰ ਨੇ ਜਾਣਾ ਸੀ। ਵਧਣ ਦੁਆਰਾ ਠੀਕ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਸਿੰਕ_ਟਾਈਮਆਊਟ у ਕੋਰਮ ਜੰਤਰ ਤੈਨਾਤੀ ਦੌਰਾਨ (ਸਕ੍ਰਿਪਟ ਵਿੱਚ setup/setup1). ਇਸ ਸੋਧ ਨੂੰ ਡਿਵੈਲਪਰਾਂ ਦੁਆਰਾ ਸਵੀਕਾਰ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਸੀ ਪੇਸਮੇਕਰ, ਇਸ ਦੀ ਬਜਾਏ ਉਹਨਾਂ ਨੇ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਨੂੰ ਇਸ ਤਰੀਕੇ ਨਾਲ ਮੁੜ ਡਿਜ਼ਾਈਨ ਕਰਨ ਦਾ ਵਾਅਦਾ ਕੀਤਾ (ਕਿਸੇ ਅਣ-ਨਿਰਧਾਰਤ ਭਵਿੱਖ ਵਿੱਚ) ਕਿ ਇਹ ਸਮਾਂ ਸਮਾਪਤੀ ਆਪਣੇ ਆਪ ਹੀ ਗਣਨਾ ਕੀਤੀ ਜਾਵੇਗੀ।

• ਜੇਕਰ ਡੇਟਾਬੇਸ ਕੌਂਫਿਗਰੇਸ਼ਨ ਇਹ ਦਰਸਾਉਂਦੀ ਹੈ LC_MESSAGES (ਟੈਕਸਟ ਸੁਨੇਹੇ) ਯੂਨੀਕੋਡ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ, ਉਦਾਹਰਨ ਲਈ ru_RU.UTF-8, ਫਿਰ ਸ਼ੁਰੂਆਤ 'ਤੇ ਡਾਕਖਾਨੇ ਇੱਕ ਵਾਤਾਵਰਣ ਵਿੱਚ ਜਿੱਥੇ ਲੋਕੇਲ UTF-8 ਨਹੀਂ ਹੈ, ਖਾਲੀ ਵਾਤਾਵਰਣ ਵਿੱਚ ਕਹੋ (ਇੱਥੇ ਪੇਸਮੇਕਰ+pgsqlms(paf) ਚੱਲਦਾ ਹੈ ਡਾਕਖਾਨੇ), ਫਿਰ ਲੌਗ ਵਿੱਚ UTF-8 ਅੱਖਰਾਂ ਦੀ ਬਜਾਏ ਪ੍ਰਸ਼ਨ ਚਿੰਨ੍ਹ ਹੋਣਗੇ. PostgreSQL ਡਿਵੈਲਪਰ ਇਸ ਗੱਲ 'ਤੇ ਸਹਿਮਤ ਨਹੀਂ ਹੋਏ ਹਨ ਕਿ ਇਸ ਕੇਸ ਵਿੱਚ ਕੀ ਕਰਨਾ ਹੈ। ਇਹ ਲਾਗਤ ਹੈ, ਤੁਹਾਨੂੰ ਇੰਸਟਾਲ ਕਰਨ ਦੀ ਲੋੜ ਹੈ LC_MESSAGES=en_US.UTF-8 ਜਦੋਂ ਇੱਕ ਡੇਟਾਬੇਸ ਉਦਾਹਰਣ ਨੂੰ ਕੌਂਫਿਗਰ (ਬਣਾਉਣਾ) ਹੁੰਦਾ ਹੈ।

• ਜੇਕਰ wal_receiver_timeout ਸੈੱਟ ਕੀਤਾ ਗਿਆ ਹੈ (ਮੂਲ ਰੂਪ ਵਿੱਚ ਇਹ 60s ਹੈ), ਤਾਂ Tuchanka3 ਅਤੇ tuchanka4 ਕਲੱਸਟਰਾਂ ਵਿੱਚ ਮਾਸਟਰ 'ਤੇ PostgreSQL-STOP ਟੈਸਟ ਦੌਰਾਨ ਰੀਪਲੀਕੇਸ਼ਨ ਨਵੇਂ ਮਾਸਟਰ ਨਾਲ ਮੁੜ ਕਨੈਕਟ ਨਹੀਂ ਹੁੰਦੀ ਹੈ. ਉੱਥੇ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਸਮਕਾਲੀ ਹੈ, ਇਸ ਲਈ ਨਾ ਸਿਰਫ਼ ਗੁਲਾਮ ਰੁਕਦਾ ਹੈ, ਸਗੋਂ ਨਵਾਂ ਮਾਲਕ ਵੀ. PostgreSQL ਨੂੰ ਕੌਂਫਿਗਰ ਕਰਨ ਵੇਲੇ wal_receiver_timeout=0 ਸੈੱਟ ਕਰਕੇ ਕੰਮ ਕਰਦਾ ਹੈ।

• ਕਦੇ-ਕਦਾਈਂ ਮੈਂ ਫੋਰਕਬੌਮ ਟੈਸਟ (ਮੈਮੋਰੀ ਓਵਰਫਲੋ) ਵਿੱਚ PostgreSQL ਵਿੱਚ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਫ੍ਰੀਜ਼ ਨੂੰ ਦੇਖਿਆ। ਫੋਰਕਬੌਮ ਤੋਂ ਬਾਅਦ, ਕਈ ਵਾਰੀ ਗੁਲਾਮ ਨਵੇਂ ਮਾਸਟਰ ਨਾਲ ਦੁਬਾਰਾ ਕਨੈਕਟ ਨਹੀਂ ਕਰ ਸਕਦੇ ਹਨ. ਮੈਂ ਇਸਦਾ ਸਾਹਮਣਾ ਸਿਰਫ਼ tuchanka3 ਅਤੇ tuchanka4 ਕਲੱਸਟਰਾਂ ਵਿੱਚ ਕੀਤਾ ਹੈ, ਜਿੱਥੇ ਸਮਕਾਲੀ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਦੇ ਕਾਰਨ ਮਾਸਟਰ ਫ੍ਰੀਜ਼ ਹੋ ਗਿਆ ਹੈ। ਲੰਬੇ ਸਮੇਂ (ਲਗਭਗ ਦੋ ਘੰਟੇ) ਬਾਅਦ ਸਮੱਸਿਆ ਆਪਣੇ ਆਪ ਦੂਰ ਹੋ ਗਈ। ਇਸ ਨੂੰ ਠੀਕ ਕਰਨ ਲਈ ਹੋਰ ਖੋਜ ਦੀ ਲੋੜ ਹੈ। ਲੱਛਣ ਪਿਛਲੇ ਬੱਗ ਦੇ ਸਮਾਨ ਹਨ, ਜੋ ਕਿ ਇੱਕ ਵੱਖਰੇ ਕਾਰਨ ਕਰਕੇ ਹੁੰਦਾ ਹੈ, ਪਰ ਉਸੇ ਦੇ ਨਤੀਜੇ ਦੇ ਨਾਲ.

ਕ੍ਰੋਗਨ ਦੀ ਤਸਵੀਰ ਤੋਂ ਲਈ ਗਈ ਭਟਕਿਆ ਕਲਾ ਲੇਖਕ ਦੀ ਇਜਾਜ਼ਤ ਨਾਲ:

ਸਰੋਤ: www.habr.com