ತಪ್ಪು ಸಹಿಷ್ಣುತೆ ಮತ್ತು ಹೆಚ್ಚಿನ ಲಭ್ಯತೆ ದೊಡ್ಡ ವಿಷಯಗಳಾಗಿವೆ, ಆದ್ದರಿಂದ ನಾವು RabbitMQ ಮತ್ತು Kafka ಗೆ ಪ್ರತ್ಯೇಕ ಲೇಖನಗಳನ್ನು ವಿನಿಯೋಗಿಸುತ್ತೇವೆ. ಈ ಲೇಖನವು RabbitMQ ಬಗ್ಗೆ ಮತ್ತು ಮುಂದಿನದು RabbitMQ ಗೆ ಹೋಲಿಸಿದರೆ ಕಾಫ್ಕಾ ಬಗ್ಗೆ. ಇದು ಸುದೀರ್ಘ ಲೇಖನವಾಗಿದೆ, ಆದ್ದರಿಂದ ನಿಮ್ಮನ್ನು ಆರಾಮದಾಯಕವಾಗಿಸಿ.

ತಪ್ಪು ಸಹಿಷ್ಣುತೆ, ಸ್ಥಿರತೆ ಮತ್ತು ಹೆಚ್ಚಿನ ಲಭ್ಯತೆ (HA) ತಂತ್ರಗಳು ಮತ್ತು ಪ್ರತಿ ತಂತ್ರವು ಮಾಡುವ ವಿನಿಮಯಗಳನ್ನು ನೋಡೋಣ. RabbitMQ ನೋಡ್‌ಗಳ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ರನ್ ಮಾಡಬಹುದು - ಮತ್ತು ನಂತರ ಅದನ್ನು ವಿತರಣಾ ವ್ಯವಸ್ಥೆಯಾಗಿ ವರ್ಗೀಕರಿಸಲಾಗುತ್ತದೆ. ವಿತರಣಾ ವ್ಯವಸ್ಥೆಗಳಿಗೆ ಬಂದಾಗ, ನಾವು ಸಾಮಾನ್ಯವಾಗಿ ಸ್ಥಿರತೆ ಮತ್ತು ಲಭ್ಯತೆಯ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತೇವೆ.

ವ್ಯವಸ್ಥೆಯು ವಿಫಲವಾದಾಗ ಹೇಗೆ ವರ್ತಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಈ ಪರಿಕಲ್ಪನೆಗಳು ವಿವರಿಸುತ್ತವೆ. ನೆಟ್‌ವರ್ಕ್ ಸಂಪರ್ಕ ವೈಫಲ್ಯ, ಸರ್ವರ್ ವೈಫಲ್ಯ, ಹಾರ್ಡ್ ಡ್ರೈವ್ ವೈಫಲ್ಯ, ಕಸ ಸಂಗ್ರಹಣೆಯಿಂದಾಗಿ ಸರ್ವರ್ ತಾತ್ಕಾಲಿಕ ಅಲಭ್ಯತೆ, ಪ್ಯಾಕೆಟ್ ನಷ್ಟ, ಅಥವಾ ನೆಟ್‌ವರ್ಕ್ ಸಂಪರ್ಕ ನಿಧಾನ. ಇದೆಲ್ಲವೂ ಡೇಟಾ ನಷ್ಟ ಅಥವಾ ಸಂಘರ್ಷಕ್ಕೆ ಕಾರಣವಾಗಬಹುದು. ಎಲ್ಲಾ ವೈಫಲ್ಯದ ಸನ್ನಿವೇಶಗಳಿಗೆ ಸಂಪೂರ್ಣವಾಗಿ ಸ್ಥಿರವಾದ (ಯಾವುದೇ ಡೇಟಾ ನಷ್ಟ, ಯಾವುದೇ ಡೇಟಾ ಡೈವರ್ಜೆನ್ಸ್) ಮತ್ತು ಲಭ್ಯವಿರುವ (ಓದಲು ಮತ್ತು ಬರೆಯಲು ಸ್ವೀಕರಿಸುತ್ತದೆ) ಸಿಸ್ಟಮ್ ಅನ್ನು ಹಾಕಲು ವಾಸ್ತವಿಕವಾಗಿ ಅಸಾಧ್ಯವಾಗಿದೆ ಎಂದು ಅದು ತಿರುಗುತ್ತದೆ.

ಸ್ಥಿರತೆ ಮತ್ತು ಲಭ್ಯತೆಯು ಸ್ಪೆಕ್ಟ್ರಮ್‌ನ ವಿರುದ್ಧ ತುದಿಗಳಲ್ಲಿದೆ ಎಂದು ನಾವು ನೋಡುತ್ತೇವೆ ಮತ್ತು ಯಾವ ರೀತಿಯಲ್ಲಿ ಆಪ್ಟಿಮೈಸ್ ಮಾಡಬೇಕೆಂದು ನೀವು ಆರಿಸಬೇಕಾಗುತ್ತದೆ. ಒಳ್ಳೆಯ ಸುದ್ದಿ ಎಂದರೆ RabbitMQ ನೊಂದಿಗೆ ಈ ಆಯ್ಕೆಯು ಸಾಧ್ಯ. ಸಮತೋಲನವನ್ನು ಹೆಚ್ಚಿನ ಸ್ಥಿರತೆ ಅಥವಾ ಹೆಚ್ಚಿನ ಪ್ರವೇಶದ ಕಡೆಗೆ ಬದಲಾಯಿಸಲು ನೀವು ಈ ರೀತಿಯ "ದಡ್ಡ" ಸನ್ನೆಕೋಲುಗಳನ್ನು ಹೊಂದಿದ್ದೀರಿ.

ದೃಢಪಡಿಸಿದ ದಾಖಲೆಗಳಿಂದ ಡೇಟಾ ನಷ್ಟಕ್ಕೆ ಯಾವ ಸಂರಚನೆಗಳು ಕಾರಣವಾಗುತ್ತವೆ ಎಂಬುದರ ಕುರಿತು ನಾವು ವಿಶೇಷ ಗಮನ ಹರಿಸುತ್ತೇವೆ. ಪ್ರಕಾಶಕರು, ದಲ್ಲಾಳಿಗಳು ಮತ್ತು ಗ್ರಾಹಕರ ನಡುವೆ ಜವಾಬ್ದಾರಿಯ ಸರಪಳಿ ಇದೆ. ಸಂದೇಶವನ್ನು ಬ್ರೋಕರ್‌ಗೆ ರವಾನಿಸಿದ ನಂತರ, ಸಂದೇಶವನ್ನು ಕಳೆದುಕೊಳ್ಳದಿರುವುದು ಅವನ ಕೆಲಸ. ಪ್ರಕಾಶಕರ ಸಂದೇಶದ ಸ್ವೀಕೃತಿಯನ್ನು ಬ್ರೋಕರ್ ಒಪ್ಪಿಕೊಂಡಾಗ, ಅದು ಕಳೆದುಹೋಗುತ್ತದೆ ಎಂದು ನಾವು ನಿರೀಕ್ಷಿಸುವುದಿಲ್ಲ. ಆದರೆ ನಿಮ್ಮ ಬ್ರೋಕರ್ ಮತ್ತು ಪ್ರಕಾಶಕರ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಅವಲಂಬಿಸಿ ಇದು ನಿಜವಾಗಿ ಸಂಭವಿಸಬಹುದು ಎಂದು ನಾವು ನೋಡುತ್ತೇವೆ.

ಸಿಂಗಲ್ ನೋಡ್ ರೆಸಿಲಿಯನ್ಸ್ ಪ್ರಿಮಿಟಿವ್ಸ್

ಸ್ಥಿತಿಸ್ಥಾಪಕ ಕ್ಯೂಯಿಂಗ್/ರೂಟಿಂಗ್

RabbitMQ ನಲ್ಲಿ ಎರಡು ವಿಧದ ಕ್ಯೂಗಳಿವೆ: ಬಾಳಿಕೆ ಬರುವ ಮತ್ತು ಬಾಳಿಕೆ ಬರದ. ಎಲ್ಲಾ ಸರತಿ ಸಾಲುಗಳನ್ನು Mnesia ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಉಳಿಸಲಾಗಿದೆ. ಬಾಳಿಕೆ ಬರುವ ಸರತಿ ಸಾಲುಗಳನ್ನು ನೋಡ್ ಸ್ಟಾರ್ಟ್‌ಅಪ್‌ನಲ್ಲಿ ಮರು-ಜಾಹೀರಾತು ಮಾಡಲಾಗುತ್ತದೆ ಮತ್ತು ಹೀಗಾಗಿ ಮರುಪ್ರಾರಂಭಗಳು, ಸಿಸ್ಟಮ್ ಕ್ರ್ಯಾಶ್‌ಗಳು ಅಥವಾ ಸರ್ವರ್ ಕ್ರ್ಯಾಶ್‌ಗಳು (ಡೇಟಾವು ನಿರಂತರವಾಗಿ ಇರುವವರೆಗೆ) ಉಳಿದುಕೊಳ್ಳುತ್ತವೆ. ಇದರರ್ಥ ನೀವು ರೂಟಿಂಗ್ (ವಿನಿಮಯ) ಮತ್ತು ಕ್ಯೂ ಸ್ಥಿತಿಸ್ಥಾಪಕತ್ವವನ್ನು ಘೋಷಿಸುವವರೆಗೆ, ಕ್ಯೂಯಿಂಗ್/ರೂಟಿಂಗ್ ಮೂಲಸೌಕರ್ಯವು ಆನ್‌ಲೈನ್‌ಗೆ ಹಿಂತಿರುಗುತ್ತದೆ.

ನೋಡ್ ಅನ್ನು ಮರುಪ್ರಾರಂಭಿಸಿದಾಗ ಬಾಷ್ಪಶೀಲ ಸಾಲುಗಳು ಮತ್ತು ರೂಟಿಂಗ್ ಅನ್ನು ತೆಗೆದುಹಾಕಲಾಗುತ್ತದೆ.

ನಿರಂತರ ಸಂದೇಶಗಳು

ಸರತಿಯು ಬಾಳಿಕೆ ಬರುವಂತಹದ್ದಾಗಿರುವುದರಿಂದ ಅದರ ಎಲ್ಲಾ ಸಂದೇಶಗಳು ನೋಡ್ ಮರುಪ್ರಾರಂಭದಲ್ಲಿ ಉಳಿಯುತ್ತವೆ ಎಂದು ಅರ್ಥವಲ್ಲ. ಪ್ರಕಾಶಕರು ಹೊಂದಿಸಿರುವ ಸಂದೇಶಗಳನ್ನು ಮಾತ್ರ ಚೇತರಿಸಿಕೊಳ್ಳುವ (ನಿರಂತರ). ನಿರಂತರ ಸಂದೇಶಗಳು ಬ್ರೋಕರ್‌ನಲ್ಲಿ ಹೆಚ್ಚುವರಿ ಲೋಡ್ ಅನ್ನು ರಚಿಸುತ್ತವೆ, ಆದರೆ ಸಂದೇಶ ನಷ್ಟವು ಸ್ವೀಕಾರಾರ್ಹವಲ್ಲದಿದ್ದರೆ, ಬೇರೆ ಆಯ್ಕೆಗಳಿಲ್ಲ.

ಅಕ್ಕಿ. 1. ಸಮರ್ಥನೀಯತೆ ಮ್ಯಾಟ್ರಿಕ್ಸ್

ಕ್ಯೂ ಮಿರರಿಂಗ್‌ನೊಂದಿಗೆ ಕ್ಲಸ್ಟರಿಂಗ್

ಬ್ರೋಕರ್ ನಷ್ಟದಿಂದ ಬದುಕಲು, ನಮಗೆ ಪುನರುಜ್ಜೀವನದ ಅಗತ್ಯವಿದೆ. ನಾವು ಬಹು RabbitMQ ನೋಡ್‌ಗಳನ್ನು ಒಂದು ಕ್ಲಸ್ಟರ್‌ಗೆ ಸಂಯೋಜಿಸಬಹುದು ಮತ್ತು ನಂತರ ಬಹು ನೋಡ್‌ಗಳ ನಡುವೆ ಕ್ಯೂಗಳನ್ನು ಪುನರಾವರ್ತಿಸುವ ಮೂಲಕ ಹೆಚ್ಚುವರಿ ಪುನರಾವರ್ತನೆಯನ್ನು ಸೇರಿಸಬಹುದು. ಈ ರೀತಿಯಾಗಿ, ಒಂದು ನೋಡ್ ವಿಫಲವಾದರೆ, ನಾವು ಡೇಟಾವನ್ನು ಕಳೆದುಕೊಳ್ಳುವುದಿಲ್ಲ ಮತ್ತು ಲಭ್ಯವಿರುತ್ತದೆ.

ಕ್ಯೂ ಮಿರರಿಂಗ್:

• ಒಂದು ಮುಖ್ಯ ಸಾಲು (ಮಾಸ್ಟರ್), ಇದು ಎಲ್ಲಾ ಬರೆಯುವ ಮತ್ತು ಓದುವ ಆಜ್ಞೆಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ
• ಮುಖ್ಯ ಸರದಿಯಿಂದ ಎಲ್ಲಾ ಸಂದೇಶಗಳು ಮತ್ತು ಮೆಟಾಡೇಟಾವನ್ನು ಸ್ವೀಕರಿಸುವ ಒಂದು ಅಥವಾ ಹೆಚ್ಚಿನ ಕನ್ನಡಿಗಳು. ಈ ಕನ್ನಡಿಗಳು ಸ್ಕೇಲಿಂಗ್‌ಗಾಗಿ ಅಲ್ಲ, ಆದರೆ ಸಂಪೂರ್ಣವಾಗಿ ಪುನರುಜ್ಜೀವನಕ್ಕಾಗಿ.

ಅಕ್ಕಿ. 2. ಕ್ಯೂ ಮಿರರಿಂಗ್

ಪ್ರತಿಬಿಂಬವನ್ನು ಸೂಕ್ತ ನೀತಿಯಿಂದ ಹೊಂದಿಸಲಾಗಿದೆ. ಅದರಲ್ಲಿ ನೀವು ಪುನರಾವರ್ತನೆ ಗುಣಾಂಕ ಮತ್ತು ಕ್ಯೂ ಇರಬೇಕಾದ ನೋಡ್‌ಗಳನ್ನು ಸಹ ಆಯ್ಕೆ ಮಾಡಬಹುದು. ಉದಾಹರಣೆಗಳು:

• ha-mode: all
• ha-mode: exactly, ha-params: 2 (ಒಬ್ಬ ಮಾಸ್ಟರ್ ಮತ್ತು ಒಬ್ಬ ಕನ್ನಡಿ)
• ha-mode: nodes, ha-params: rabbit@node1, rabbit@node2

ಪ್ರಕಾಶಕರ ದೃಢೀಕರಣ

ಸ್ಥಿರವಾದ ರೆಕಾರ್ಡಿಂಗ್ ಸಾಧಿಸಲು, ಪ್ರಕಾಶಕರು ದೃಢೀಕರಿಸುವ ಅಗತ್ಯವಿದೆ. ಅವರಿಲ್ಲದೆ, ಸಂದೇಶಗಳು ಕಳೆದುಹೋಗುವ ಅಪಾಯವಿದೆ. ಸಂದೇಶವನ್ನು ಡಿಸ್ಕ್‌ಗೆ ಬರೆದ ನಂತರ ಪ್ರಕಾಶಕರಿಗೆ ದೃಢೀಕರಣವನ್ನು ಕಳುಹಿಸಲಾಗುತ್ತದೆ. RabbitMQ ಡಿಸ್ಕ್‌ಗೆ ಸಂದೇಶಗಳನ್ನು ರಶೀದಿಯ ಮೇಲೆ ಬರೆಯುವುದಿಲ್ಲ, ಆದರೆ ಆವರ್ತಕ ಆಧಾರದ ಮೇಲೆ, ಹಲವಾರು ನೂರು ಮಿಲಿಸೆಕೆಂಡ್‌ಗಳ ಪ್ರದೇಶದಲ್ಲಿ. ಸರತಿಯನ್ನು ಪ್ರತಿಬಿಂಬಿಸಿದಾಗ, ಎಲ್ಲಾ ಕನ್ನಡಿಗಳು ತಮ್ಮ ಸಂದೇಶದ ಪ್ರತಿಯನ್ನು ಡಿಸ್ಕ್‌ಗೆ ಬರೆದ ನಂತರವೇ ಸ್ವೀಕೃತಿಯನ್ನು ಕಳುಹಿಸಲಾಗುತ್ತದೆ. ಇದರರ್ಥ ದೃಢೀಕರಣಗಳನ್ನು ಬಳಸುವುದು ಸುಪ್ತತೆಯನ್ನು ಸೇರಿಸುತ್ತದೆ, ಆದರೆ ಡೇಟಾ ಸುರಕ್ಷತೆಯು ಮುಖ್ಯವಾಗಿದ್ದರೆ, ಅವು ಅವಶ್ಯಕ.

ವಿಫಲ ಸರತಿ ಸಾಲು

ಬ್ರೋಕರ್ ತೊರೆದಾಗ ಅಥವಾ ಕ್ರ್ಯಾಶ್ ಮಾಡಿದಾಗ, ಆ ನೋಡ್‌ನಲ್ಲಿರುವ ಎಲ್ಲಾ ಕ್ಯೂ ಲೀಡರ್‌ಗಳು (ಮಾಸ್ಟರ್‌ಗಳು) ಅದರೊಂದಿಗೆ ಕ್ರ್ಯಾಶ್ ಆಗುತ್ತಾರೆ. ಕ್ಲಸ್ಟರ್ ನಂತರ ಪ್ರತಿ ಮಾಸ್ಟರ್‌ನ ಹಳೆಯ ಕನ್ನಡಿಯನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ ಮತ್ತು ಅದನ್ನು ಹೊಸ ಮಾಸ್ಟರ್ ಎಂದು ಪ್ರಚಾರ ಮಾಡುತ್ತದೆ.

ಅಕ್ಕಿ. 3. ಬಹು ಪ್ರತಿಬಿಂಬಿತ ಸರತಿ ಸಾಲುಗಳು ಮತ್ತು ಅವುಗಳ ನೀತಿಗಳು

ಬ್ರೋಕರ್ 3 ಕೆಳಗೆ ಹೋಗುತ್ತದೆ. ಬ್ರೋಕರ್ 2 ನಲ್ಲಿನ ಕ್ಯೂ ಸಿ ಮಿರರ್ ಅನ್ನು ಮಾಸ್ಟರ್ ಆಗಿ ಬಡ್ತಿ ನೀಡಲಾಗುತ್ತಿದೆ ಎಂಬುದನ್ನು ಗಮನಿಸಿ. ಬ್ರೋಕರ್ 1 ನಲ್ಲಿ ಕ್ಯೂ C ಗಾಗಿ ಹೊಸ ಕನ್ನಡಿಯನ್ನು ರಚಿಸಲಾಗಿದೆ ಎಂಬುದನ್ನು ಗಮನಿಸಿ. RabbitMQ ಯಾವಾಗಲೂ ನಿಮ್ಮ ನೀತಿಗಳಲ್ಲಿ ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ಪುನರಾವರ್ತನೆಯ ಅಂಶವನ್ನು ನಿರ್ವಹಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತದೆ.

ಅಕ್ಕಿ. 4. ಬ್ರೋಕರ್ 3 ವಿಫಲಗೊಳ್ಳುತ್ತದೆ, ಕ್ಯೂ ಸಿ ವಿಫಲಗೊಳ್ಳುತ್ತದೆ

ಮುಂದಿನ ಬ್ರೋಕರ್ 1 ಬೀಳುತ್ತದೆ! ನಮ್ಮಲ್ಲಿ ಒಬ್ಬ ಬ್ರೋಕರ್ ಮಾತ್ರ ಉಳಿದಿದ್ದಾರೆ. ಕ್ಯೂ ಬಿ ಕನ್ನಡಿಯನ್ನು ಮಾಸ್ಟರ್ ಆಗಿ ಬಡ್ತಿ ನೀಡಲಾಗಿದೆ.

ಅಂಜೂರ. 5

ನಾವು ಬ್ರೋಕರ್ 1 ಅನ್ನು ಹಿಂತಿರುಗಿಸಿದ್ದೇವೆ. ಬ್ರೋಕರ್‌ನ ನಷ್ಟ ಮತ್ತು ಮರುಪಡೆಯುವಿಕೆಯಿಂದ ಡೇಟಾ ಎಷ್ಟು ಚೆನ್ನಾಗಿ ಉಳಿದುಕೊಂಡಿದ್ದರೂ, ಮರುಪ್ರಾರಂಭಿಸಿದ ನಂತರ ಎಲ್ಲಾ ಪ್ರತಿಬಿಂಬಿತ ಕ್ಯೂ ಸಂದೇಶಗಳನ್ನು ತಿರಸ್ಕರಿಸಲಾಗುತ್ತದೆ. ಇದು ಗಮನಿಸಬೇಕಾದ ಅಂಶವಾಗಿದೆ ಏಕೆಂದರೆ ಪರಿಣಾಮಗಳು ಉಂಟಾಗುತ್ತವೆ. ನಾವು ಶೀಘ್ರದಲ್ಲೇ ಈ ಪರಿಣಾಮಗಳನ್ನು ನೋಡೋಣ. ಆದ್ದರಿಂದ ಬ್ರೋಕರ್ 1 ಈಗ ಮತ್ತೆ ಕ್ಲಸ್ಟರ್‌ನ ಸದಸ್ಯರಾಗಿದ್ದಾರೆ, ಮತ್ತು ಕ್ಲಸ್ಟರ್ ನೀತಿಗಳನ್ನು ಅನುಸರಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತದೆ ಮತ್ತು ಆದ್ದರಿಂದ ಬ್ರೋಕರ್ 1 ನಲ್ಲಿ ಕನ್ನಡಿಗಳನ್ನು ರಚಿಸುತ್ತದೆ.

ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಡೇಟಾದಂತೆ ಬ್ರೋಕರ್ 1 ರ ನಷ್ಟವು ಪೂರ್ಣಗೊಂಡಿತು, ಆದ್ದರಿಂದ ಪ್ರತಿಬಿಂಬಿಸದ ಕ್ಯೂ B ಸಂಪೂರ್ಣವಾಗಿ ಕಳೆದುಹೋಯಿತು.

ಅಕ್ಕಿ. 6. ಬ್ರೋಕರ್ 1 ಸೇವೆಗೆ ಹಿಂತಿರುಗುತ್ತಾನೆ

ಬ್ರೋಕರ್ 3 ಆನ್‌ಲೈನ್‌ಗೆ ಮರಳಿದೆ, ಆದ್ದರಿಂದ ಎ ಮತ್ತು ಬಿ ಕ್ಯೂಗಳು ತಮ್ಮ HA ನೀತಿಗಳನ್ನು ಪೂರೈಸಲು ಅದರ ಮೇಲೆ ರಚಿಸಲಾದ ಕನ್ನಡಿಗಳನ್ನು ಮರಳಿ ಪಡೆಯುತ್ತವೆ. ಆದರೆ ಈಗ ಎಲ್ಲಾ ಮುಖ್ಯ ಸಾಲುಗಳು ಒಂದೇ ನೋಡ್‌ನಲ್ಲಿವೆ! ಇದು ಸೂಕ್ತವಲ್ಲ, ನೋಡ್‌ಗಳ ನಡುವೆ ಸಮಾನ ವಿತರಣೆ ಉತ್ತಮವಾಗಿದೆ. ದುರದೃಷ್ಟವಶಾತ್, ಮಾಸ್ಟರ್‌ಗಳನ್ನು ಮರುಸಮತೋಲನಗೊಳಿಸಲು ಇಲ್ಲಿ ಹೆಚ್ಚಿನ ಆಯ್ಕೆಗಳಿಲ್ಲ. ನಾವು ನಂತರ ಈ ಸಮಸ್ಯೆಗೆ ಹಿಂತಿರುಗುತ್ತೇವೆ ಏಕೆಂದರೆ ನಾವು ಮೊದಲು ಕ್ಯೂ ಸಿಂಕ್ರೊನೈಸೇಶನ್ ಅನ್ನು ನೋಡಬೇಕಾಗಿದೆ.

ಅಕ್ಕಿ. 7. ಬ್ರೋಕರ್ 3 ಸೇವೆಗೆ ಮರಳುತ್ತದೆ. ಒಂದು ನೋಡ್‌ನಲ್ಲಿ ಎಲ್ಲಾ ಮುಖ್ಯ ಸಾಲುಗಳು!

ಆದ್ದರಿಂದ ಕನ್ನಡಿಗಳು ಹೇಗೆ ಪುನರುಕ್ತಿ ಮತ್ತು ದೋಷ ಸಹಿಷ್ಣುತೆಯನ್ನು ಒದಗಿಸುತ್ತವೆ ಎಂಬ ಕಲ್ಪನೆಯನ್ನು ಈಗ ನೀವು ಹೊಂದಿರಬೇಕು. ಇದು ಒಂದೇ ನೋಡ್ ವೈಫಲ್ಯದ ಸಂದರ್ಭದಲ್ಲಿ ಲಭ್ಯತೆಯನ್ನು ಖಾತ್ರಿಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ಡೇಟಾ ನಷ್ಟದಿಂದ ರಕ್ಷಿಸುತ್ತದೆ. ಆದರೆ ನಾವು ಇನ್ನೂ ಮಾಡಿಲ್ಲ, ಏಕೆಂದರೆ ವಾಸ್ತವದಲ್ಲಿ ಇದು ಹೆಚ್ಚು ಜಟಿಲವಾಗಿದೆ.

ಸಿಂಕ್ ಮಾಡಲಾಗುತ್ತಿದೆ

ಹೊಸ ಕನ್ನಡಿಯನ್ನು ರಚಿಸುವಾಗ, ಎಲ್ಲಾ ಹೊಸ ಸಂದೇಶಗಳನ್ನು ಯಾವಾಗಲೂ ಈ ಕನ್ನಡಿಗೆ ಮತ್ತು ಯಾವುದೇ ಇತರರಿಗೆ ಪುನರಾವರ್ತಿಸಲಾಗುತ್ತದೆ. ಮಾಸ್ಟರ್ ಕ್ಯೂನಲ್ಲಿ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಡೇಟಾಗೆ ಸಂಬಂಧಿಸಿದಂತೆ, ನಾವು ಅದನ್ನು ಹೊಸ ಕನ್ನಡಿಗೆ ಪುನರಾವರ್ತಿಸಬಹುದು, ಅದು ಮಾಸ್ಟರ್‌ನ ಸಂಪೂರ್ಣ ನಕಲು ಆಗುತ್ತದೆ. ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಸಂದೇಶಗಳನ್ನು ಪುನರಾವರ್ತಿಸದಿರಲು ನಾವು ಆಯ್ಕೆ ಮಾಡಬಹುದು ಮತ್ತು ಮುಖ್ಯ ಸರತಿ ಮತ್ತು ಹೊಸ ಕನ್ನಡಿಯು ಸಮಯಕ್ಕೆ ಒಮ್ಮುಖವಾಗಲು ಅವಕಾಶ ಮಾಡಿಕೊಡಿ, ಹೊಸ ಸಂದೇಶಗಳು ಬಾಲಕ್ಕೆ ಬರುತ್ತವೆ ಮತ್ತು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಸಂದೇಶಗಳು ಮುಖ್ಯ ಸರದಿಯ ಮುಖ್ಯಸ್ಥರನ್ನು ಬಿಟ್ಟುಬಿಡುತ್ತವೆ.

ಈ ಸಿಂಕ್ರೊನೈಸೇಶನ್ ಅನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಅಥವಾ ಹಸ್ತಚಾಲಿತವಾಗಿ ನಿರ್ವಹಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಕ್ಯೂ ನೀತಿಯನ್ನು ಬಳಸಿಕೊಂಡು ನಿರ್ವಹಿಸಲಾಗುತ್ತದೆ. ಒಂದು ಉದಾಹರಣೆಯನ್ನು ನೋಡೋಣ.

ನಮ್ಮಲ್ಲಿ ಎರಡು ಕನ್ನಡಿ ಸರತಿ ಸಾಲುಗಳಿವೆ. ಕ್ಯೂ A ಅನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡಲಾಗುತ್ತದೆ ಮತ್ತು ಕ್ಯೂ B ಅನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡಲಾಗುತ್ತದೆ. ಎರಡೂ ಸಾಲುಗಳು ಹತ್ತು ಸಂದೇಶಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತವೆ.

ಅಕ್ಕಿ. 8. ವಿಭಿನ್ನ ಸಿಂಕ್ರೊನೈಸೇಶನ್ ವಿಧಾನಗಳೊಂದಿಗೆ ಎರಡು ಸಾಲುಗಳು

ಈಗ ನಾವು ಬ್ರೋಕರ್ 3 ಅನ್ನು ಕಳೆದುಕೊಳ್ಳುತ್ತಿದ್ದೇವೆ.

ಅಕ್ಕಿ. 9. ಬ್ರೋಕರ್ 3 ಕುಸಿಯಿತು

ಬ್ರೋಕರ್ 3 ಸೇವೆಗೆ ಮರಳುತ್ತದೆ. ಕ್ಲಸ್ಟರ್ ಹೊಸ ನೋಡ್‌ನಲ್ಲಿ ಪ್ರತಿ ಸರತಿಗೆ ಕನ್ನಡಿಯನ್ನು ರಚಿಸುತ್ತದೆ ಮತ್ತು ಮಾಸ್ಟರ್‌ನೊಂದಿಗೆ ಹೊಸ ಕ್ಯೂ A ಅನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡುತ್ತದೆ. ಆದಾಗ್ಯೂ, ಹೊಸ ಕ್ಯೂ ಬಿ ಯ ಕನ್ನಡಿ ಖಾಲಿಯಾಗಿಯೇ ಉಳಿದಿದೆ. ಈ ರೀತಿಯಲ್ಲಿ ನಾವು ಕ್ಯೂ A ನಲ್ಲಿ ಪೂರ್ಣ ಪುನರುಜ್ಜೀವನವನ್ನು ಹೊಂದಿದ್ದೇವೆ ಮತ್ತು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಕ್ಯೂ B ಸಂದೇಶಗಳಿಗೆ ಕೇವಲ ಒಂದು ಕನ್ನಡಿ ಮಾತ್ರ.

ಅಕ್ಕಿ. 10. ಕ್ಯೂ A ಯ ಹೊಸ ಕನ್ನಡಿಯು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಎಲ್ಲಾ ಸಂದೇಶಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ, ಆದರೆ ಕ್ಯೂ B ಯ ಹೊಸ ಕನ್ನಡಿಯು ಸ್ವೀಕರಿಸುವುದಿಲ್ಲ.

ಎರಡೂ ಸರತಿ ಸಾಲುಗಳಲ್ಲಿ ಇನ್ನೂ ಹತ್ತು ಸಂದೇಶಗಳು ಬರುತ್ತವೆ. ಬ್ರೋಕರ್ 2 ನಂತರ ಕ್ರ್ಯಾಶ್ ಆಗುತ್ತದೆ ಮತ್ತು ಕ್ಯೂ ಎ ಬ್ರೋಕರ್ 1 ನಲ್ಲಿ ಇರುವ ಹಳೆಯ ಕನ್ನಡಿಗೆ ಹಿಂತಿರುಗುತ್ತದೆ. ಅದು ವಿಫಲವಾದಾಗ ಯಾವುದೇ ಡೇಟಾ ನಷ್ಟವಿಲ್ಲ. ಕ್ಯೂ B ನಲ್ಲಿ, ಮಾಸ್ಟರ್‌ನಲ್ಲಿ ಇಪ್ಪತ್ತು ಸಂದೇಶಗಳಿವೆ ಮತ್ತು ಕನ್ನಡಿಯಲ್ಲಿ ಕೇವಲ ಹತ್ತು ಸಂದೇಶಗಳಿವೆ ಏಕೆಂದರೆ ಈ ಸರತಿಯು ಮೂಲ ಹತ್ತು ಸಂದೇಶಗಳನ್ನು ಎಂದಿಗೂ ಪುನರಾವರ್ತಿಸಲಿಲ್ಲ.

ಅಕ್ಕಿ. 11. ಕ್ಯೂ A ಸಂದೇಶಗಳನ್ನು ಕಳೆದುಕೊಳ್ಳದೆ ಬ್ರೋಕರ್ 1 ಗೆ ಹಿಂತಿರುಗುತ್ತದೆ

ಎರಡೂ ಸರತಿ ಸಾಲುಗಳಲ್ಲಿ ಇನ್ನೂ ಹತ್ತು ಸಂದೇಶಗಳು ಬರುತ್ತವೆ. ಈಗ ಬ್ರೋಕರ್ 1 ಕ್ರ್ಯಾಶ್ ಆಗಿದೆ. ಕ್ಯೂ ಎ ಸಂದೇಶಗಳನ್ನು ಕಳೆದುಕೊಳ್ಳದೆ ಸುಲಭವಾಗಿ ಕನ್ನಡಿಗೆ ಬದಲಾಯಿಸುತ್ತದೆ. ಆದರೆ, ಬಿ ಕ್ಯೂ ಸಮಸ್ಯೆ ಎದುರಿಸುತ್ತಿದೆ. ಈ ಹಂತದಲ್ಲಿ ನಾವು ಲಭ್ಯತೆ ಅಥವಾ ಸ್ಥಿರತೆಯನ್ನು ಉತ್ತಮಗೊಳಿಸಬಹುದು.

ನಾವು ಪ್ರವೇಶವನ್ನು ಆಪ್ಟಿಮೈಜ್ ಮಾಡಲು ಬಯಸಿದರೆ, ನಂತರ ನೀತಿ ಹಾ-ಪ್ರಮೋಟ್ ಆನ್ ವೈಫಲ್ಯ ನಲ್ಲಿ ಅಳವಡಿಸಬೇಕು ಯಾವಾಗಲೂ. ಇದು ಡೀಫಾಲ್ಟ್ ಮೌಲ್ಯವಾಗಿದೆ, ಆದ್ದರಿಂದ ನೀವು ನೀತಿಯನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡದ ಕನ್ನಡಿಗಳಲ್ಲಿ ನಾವು ಮೂಲಭೂತವಾಗಿ ವೈಫಲ್ಯಗಳನ್ನು ಅನುಮತಿಸುತ್ತಿದ್ದೇವೆ. ಇದು ಸಂದೇಶಗಳನ್ನು ಕಳೆದುಕೊಳ್ಳಲು ಕಾರಣವಾಗುತ್ತದೆ, ಆದರೆ ಸರತಿಯು ಓದಬಲ್ಲ ಮತ್ತು ಬರೆಯಬಹುದಾದಂತೆ ಉಳಿಯುತ್ತದೆ.

ಅಕ್ಕಿ. 12. ಸಂದೇಶಗಳನ್ನು ಕಳೆದುಕೊಳ್ಳದೆ ಕ್ಯೂ A ಅನ್ನು ಬ್ರೋಕರ್ 3 ಗೆ ಹಿಂತಿರುಗಿಸಲಾಗುತ್ತದೆ. ಹತ್ತು ಸಂದೇಶಗಳು ಕಳೆದುಹೋದಾಗ ಕ್ಯೂ B ಬ್ರೋಕರ್ 3 ಗೆ ಹಿಂತಿರುಗುತ್ತದೆ

ನಾವು ಸಹ ಸ್ಥಾಪಿಸಬಹುದು ha-promote-on-failure ಅರ್ಥದಲ್ಲಿ when-synced. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಕನ್ನಡಿಗೆ ಹಿಂತಿರುಗುವ ಬದಲು, ಬ್ರೋಕರ್ 1 ಅದರ ಡೇಟಾದೊಂದಿಗೆ ಆನ್‌ಲೈನ್ ಮೋಡ್‌ಗೆ ಹಿಂತಿರುಗುವವರೆಗೆ ಕ್ಯೂ ಕಾಯುತ್ತದೆ. ಅದು ಹಿಂತಿರುಗಿದ ನಂತರ, ಮುಖ್ಯ ಸರತಿಯು ಯಾವುದೇ ಡೇಟಾ ನಷ್ಟವಿಲ್ಲದೆ ಬ್ರೋಕರ್ 1 ನಲ್ಲಿ ಹಿಂತಿರುಗುತ್ತದೆ. ಡೇಟಾ ಸುರಕ್ಷತೆಗಾಗಿ ಲಭ್ಯತೆಯನ್ನು ತ್ಯಾಗ ಮಾಡಲಾಗಿದೆ. ಆದರೆ ಇದು ಅಪಾಯಕಾರಿ ಮೋಡ್ ಆಗಿದ್ದು ಅದು ಸಂಪೂರ್ಣ ಡೇಟಾ ನಷ್ಟಕ್ಕೆ ಕಾರಣವಾಗಬಹುದು, ಅದನ್ನು ನಾವು ಶೀಘ್ರದಲ್ಲೇ ನೋಡುತ್ತೇವೆ.

ಅಕ್ಕಿ. 13. ಬ್ರೋಕರ್ 1 ಅನ್ನು ಕಳೆದುಕೊಂಡ ನಂತರ ಕ್ಯೂ B ಲಭ್ಯವಿಲ್ಲ

"ಸ್ವಯಂಚಾಲಿತ ಸಿಂಕ್ರೊನೈಸೇಶನ್ ಅನ್ನು ಎಂದಿಗೂ ಬಳಸದಿರುವುದು ಉತ್ತಮವೇ?" ಎಂದು ನೀವು ಕೇಳಬಹುದು. ಉತ್ತರವೆಂದರೆ ಸಿಂಕ್ರೊನೈಸೇಶನ್ ತಡೆಯುವ ಕಾರ್ಯಾಚರಣೆಯಾಗಿದೆ. ಸಿಂಕ್ರೊನೈಸೇಶನ್ ಸಮಯದಲ್ಲಿ, ಮುಖ್ಯ ಸರತಿಯು ಯಾವುದೇ ಓದುವ ಅಥವಾ ಬರೆಯುವ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ನಿರ್ವಹಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ!

ಒಂದು ಉದಾಹರಣೆಯನ್ನು ನೋಡೋಣ. ಈಗ ನಮಗೆ ಬಹಳ ಉದ್ದವಾದ ಸರತಿ ಸಾಲುಗಳಿವೆ. ಅವರು ಅಂತಹ ಗಾತ್ರಕ್ಕೆ ಹೇಗೆ ಬೆಳೆಯುತ್ತಾರೆ? ಹಲವಾರು ಕಾರಣಗಳಿಗಾಗಿ:

• ಸಾಲುಗಳನ್ನು ಸಕ್ರಿಯವಾಗಿ ಬಳಸಲಾಗುವುದಿಲ್ಲ
• ಇವುಗಳು ಹೆಚ್ಚಿನ ವೇಗದ ಸರತಿ ಸಾಲುಗಳಾಗಿವೆ ಮತ್ತು ಇದೀಗ ಗ್ರಾಹಕರು ನಿಧಾನವಾಗಿದ್ದಾರೆ
• ಇದು ಹೈ-ಸ್ಪೀಡ್ ಕ್ಯೂಗಳು, ಗ್ಲಿಚ್ ಕಂಡುಬಂದಿದೆ ಮತ್ತು ಗ್ರಾಹಕರು ಹಿಡಿಯುತ್ತಿದ್ದಾರೆ

ಅಕ್ಕಿ. 14. ವಿಭಿನ್ನ ಸಿಂಕ್ರೊನೈಸೇಶನ್ ಮೋಡ್‌ಗಳೊಂದಿಗೆ ಎರಡು ದೊಡ್ಡ ಸರತಿ ಸಾಲುಗಳು

ಈಗ ಬ್ರೋಕರ್ 3 ಬೀಳುತ್ತದೆ.

ಅಕ್ಕಿ. 15. ಬ್ರೋಕರ್ 3 ಬೀಳುತ್ತದೆ, ಪ್ರತಿ ಸರತಿಯಲ್ಲಿ ಒಬ್ಬ ಮಾಸ್ಟರ್ ಮತ್ತು ಕನ್ನಡಿಯನ್ನು ಬಿಡಲಾಗುತ್ತದೆ

ಬ್ರೋಕರ್ 3 ಆನ್‌ಲೈನ್‌ಗೆ ಹಿಂತಿರುಗುತ್ತದೆ ಮತ್ತು ಹೊಸ ಕನ್ನಡಿಗಳು ರಚಿಸಲ್ಪಡುತ್ತವೆ. ಮುಖ್ಯ ಸರತಿ A ಹೊಸ ಕನ್ನಡಿಗೆ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಸಂದೇಶಗಳನ್ನು ಪುನರಾವರ್ತಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ ಮತ್ತು ಈ ಸಮಯದಲ್ಲಿ ಸರತಿಯು ಲಭ್ಯವಿರುವುದಿಲ್ಲ. ಡೇಟಾವನ್ನು ಪುನರಾವರ್ತಿಸಲು ಇದು ಎರಡು ಗಂಟೆಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ, ಇದರಿಂದಾಗಿ ಈ ಸರತಿಗೆ ಎರಡು ಗಂಟೆಗಳ ಅಲಭ್ಯತೆ ಉಂಟಾಗುತ್ತದೆ!

ಆದಾಗ್ಯೂ, ಕ್ಯೂ B ಸಂಪೂರ್ಣ ಅವಧಿಯಲ್ಲಿ ಲಭ್ಯವಿರುತ್ತದೆ. ಪ್ರವೇಶಿಸುವಿಕೆಗಾಗಿ ಅವಳು ಕೆಲವು ಪುನರುಕ್ತಿಗಳನ್ನು ತ್ಯಾಗ ಮಾಡಿದಳು.

ಅಕ್ಕಿ. 16. ಸಿಂಕ್ರೊನೈಸೇಶನ್ ಸಮಯದಲ್ಲಿ ಕ್ಯೂ ಲಭ್ಯವಿಲ್ಲ

ಎರಡು ಗಂಟೆಗಳ ನಂತರ, ಕ್ಯೂ A ಸಹ ಲಭ್ಯವಾಗುತ್ತದೆ ಮತ್ತು ಮತ್ತೆ ಓದುವಿಕೆ ಮತ್ತು ಬರಹಗಳನ್ನು ಸ್ವೀಕರಿಸಲು ಪ್ರಾರಂಭಿಸಬಹುದು.

ಅಪ್ಡೇಟ್ಗಳು

ಸಿಂಕ್ರೊನೈಸೇಶನ್ ಸಮಯದಲ್ಲಿ ಈ ತಡೆಯುವ ನಡವಳಿಕೆಯು ದೊಡ್ಡ ಸರತಿ ಸಾಲುಗಳೊಂದಿಗೆ ಕ್ಲಸ್ಟರ್‌ಗಳನ್ನು ನವೀಕರಿಸಲು ಕಷ್ಟಕರವಾಗಿಸುತ್ತದೆ. ಕೆಲವು ಹಂತದಲ್ಲಿ, ಮಾಸ್ಟರ್ ನೋಡ್ ಅನ್ನು ಮರುಪ್ರಾರಂಭಿಸಬೇಕಾಗಿದೆ, ಅಂದರೆ ಮಿರರ್‌ಗೆ ಬದಲಾಯಿಸುವುದು ಅಥವಾ ಸರ್ವರ್ ಅನ್ನು ಅಪ್‌ಗ್ರೇಡ್ ಮಾಡುತ್ತಿರುವಾಗ ಸರದಿಯನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುವುದು. ನಾವು ಪರಿವರ್ತನೆಯನ್ನು ಆರಿಸಿದರೆ, ಕನ್ನಡಿಗಳನ್ನು ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡದಿದ್ದರೆ ನಾವು ಸಂದೇಶಗಳನ್ನು ಕಳೆದುಕೊಳ್ಳುತ್ತೇವೆ. ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ, ಬ್ರೋಕರ್ ಸ್ಥಗಿತದ ಸಮಯದಲ್ಲಿ, ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡದ ಕನ್ನಡಿಗೆ ವಿಫಲತೆಯನ್ನು ನಿರ್ವಹಿಸಲಾಗುವುದಿಲ್ಲ. ಇದರರ್ಥ ಬ್ರೋಕರ್ ಹಿಂತಿರುಗಿದ ತಕ್ಷಣ, ನಾವು ಯಾವುದೇ ಸಂದೇಶಗಳನ್ನು ಕಳೆದುಕೊಳ್ಳುವುದಿಲ್ಲ, ಸರಳ ಸರತಿ ಸಾಲು ಮಾತ್ರ ಹಾನಿಯಾಗಿದೆ. ಬ್ರೋಕರ್ ಸಂಪರ್ಕ ಕಡಿತಗೊಂಡಾಗ ನಡವಳಿಕೆಯ ನಿಯಮಗಳನ್ನು ನೀತಿಯಿಂದ ಹೊಂದಿಸಲಾಗಿದೆ ha-promote-on-shutdown. ನೀವು ಎರಡು ಮೌಲ್ಯಗಳಲ್ಲಿ ಒಂದನ್ನು ಹೊಂದಿಸಬಹುದು:

• always= ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡದ ಕನ್ನಡಿಗಳಿಗೆ ಪರಿವರ್ತನೆಯನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಲಾಗಿದೆ
• when-synced= ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡಿದ ಕನ್ನಡಿಗೆ ಮಾತ್ರ ಪರಿವರ್ತನೆ, ಇಲ್ಲದಿದ್ದರೆ ಸರತಿಯು ಓದಲಾಗುವುದಿಲ್ಲ ಮತ್ತು ಬರೆಯಲಾಗದಂತಾಗುತ್ತದೆ. ಬ್ರೋಕರ್ ಹಿಂತಿರುಗಿದ ತಕ್ಷಣ ಸರತಿಯು ಸೇವೆಗೆ ಮರಳುತ್ತದೆ

ಒಂದು ರೀತಿಯಲ್ಲಿ ಅಥವಾ ಇನ್ನೊಂದು ರೀತಿಯಲ್ಲಿ, ದೊಡ್ಡ ಸಾಲುಗಳೊಂದಿಗೆ ನೀವು ಡೇಟಾ ನಷ್ಟ ಮತ್ತು ಅಲಭ್ಯತೆಯ ನಡುವೆ ಆಯ್ಕೆ ಮಾಡಬೇಕಾಗುತ್ತದೆ.

ಲಭ್ಯತೆಯು ಡೇಟಾ ಭದ್ರತೆಯನ್ನು ಸುಧಾರಿಸಿದಾಗ

ನಿರ್ಧಾರ ತೆಗೆದುಕೊಳ್ಳುವ ಮೊದಲು ಪರಿಗಣಿಸಲು ಇನ್ನೂ ಒಂದು ತೊಡಕು ಇದೆ. ಪುನರಾವರ್ತನೆಗಾಗಿ ಸ್ವಯಂಚಾಲಿತ ಸಿಂಕ್ರೊನೈಸೇಶನ್ ಉತ್ತಮವಾಗಿದ್ದರೂ, ಅದು ಡೇಟಾ ಸುರಕ್ಷತೆಯ ಮೇಲೆ ಹೇಗೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ? ಸಹಜವಾಗಿ, ಉತ್ತಮ ಪುನರಾವರ್ತನೆಯೊಂದಿಗೆ, RabbitMQ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಸಂದೇಶಗಳನ್ನು ಕಳೆದುಕೊಳ್ಳುವ ಸಾಧ್ಯತೆ ಕಡಿಮೆ, ಆದರೆ ಪ್ರಕಾಶಕರಿಂದ ಹೊಸ ಸಂದೇಶಗಳ ಬಗ್ಗೆ ಏನು?

ಇಲ್ಲಿ ನೀವು ಈ ಕೆಳಗಿನವುಗಳನ್ನು ಪರಿಗಣಿಸಬೇಕಾಗಿದೆ:

• ಪ್ರಕಾಶಕರು ದೋಷವನ್ನು ಹಿಂತಿರುಗಿಸಬಹುದೇ ಮತ್ತು ಅಪ್‌ಸ್ಟ್ರೀಮ್ ಸೇವೆ ಅಥವಾ ಬಳಕೆದಾರರು ನಂತರ ಮತ್ತೆ ಪ್ರಯತ್ನಿಸಬಹುದೇ?
• ನಂತರ ಮತ್ತೆ ಪ್ರಯತ್ನಿಸಲು ಪ್ರಕಾಶಕರು ಸಂದೇಶವನ್ನು ಸ್ಥಳೀಯವಾಗಿ ಅಥವಾ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಉಳಿಸಬಹುದೇ?

ಪ್ರಕಾಶಕರು ಸಂದೇಶವನ್ನು ಮಾತ್ರ ತಿರಸ್ಕರಿಸಬಹುದಾದರೆ, ವಾಸ್ತವವಾಗಿ, ಪ್ರವೇಶವನ್ನು ಸುಧಾರಿಸುವುದು ಡೇಟಾ ಸುರಕ್ಷತೆಯನ್ನು ಸುಧಾರಿಸುತ್ತದೆ.

ಹೀಗಾಗಿ, ಸಮತೋಲನವನ್ನು ಹುಡುಕಬೇಕು, ಮತ್ತು ಪರಿಹಾರವು ನಿರ್ದಿಷ್ಟ ಪರಿಸ್ಥಿತಿಯನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ.

ha-promote-on-failure = ಯಾವಾಗ-ಸಿಂಕ್ ಮಾಡಲಾದ ತೊಂದರೆಗಳು

ಐಡಿಯಾ ಹಾ-ಪ್ರಮೋಟ್ ಆನ್ ವೈಫಲ್ಯ= ಯಾವಾಗ-ಸಿಂಕ್ ಮಾಡಲಾಗಿದೆ ನಾವು ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡದ ಕನ್ನಡಿಗೆ ಬದಲಾಯಿಸುವುದನ್ನು ತಡೆಯುತ್ತೇವೆ ಮತ್ತು ಆ ಮೂಲಕ ಡೇಟಾ ನಷ್ಟವನ್ನು ತಪ್ಪಿಸುತ್ತೇವೆ. ಸರತಿ ಸಾಲು ಓದಲು ಅಥವಾ ಬರೆಯಲು ಸಾಧ್ಯವಿಲ್ಲ. ಬದಲಾಗಿ, ಕ್ರ್ಯಾಶ್ ಆಗಿರುವ ಬ್ರೋಕರ್ ಅನ್ನು ಅದರ ಡೇಟಾದೊಂದಿಗೆ ಚೇತರಿಸಿಕೊಳ್ಳಲು ನಾವು ಪ್ರಯತ್ನಿಸುತ್ತೇವೆ ಇದರಿಂದ ಅದು ಡೇಟಾ ನಷ್ಟವಿಲ್ಲದೆ ಮಾಸ್ಟರ್ ಆಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದನ್ನು ಪುನರಾರಂಭಿಸಬಹುದು.

ಆದರೆ (ಮತ್ತು ಇದು ದೊಡ್ಡದಾಗಿದೆ ಆದರೆ) ಬ್ರೋಕರ್ ತನ್ನ ಡೇಟಾವನ್ನು ಕಳೆದುಕೊಂಡಿದ್ದರೆ, ನಮಗೆ ದೊಡ್ಡ ಸಮಸ್ಯೆ ಇದೆ: ಕ್ಯೂ ಕಳೆದುಹೋಗಿದೆ! ಎಲ್ಲಾ ಡೇಟಾ ಹೋಗಿದೆ! ನೀವು ಮುಖ್ಯ ಸರತಿಯಲ್ಲಿ ಹೆಚ್ಚಾಗಿ ಹಿಡಿಯುವ ಕನ್ನಡಿಗಳನ್ನು ಹೊಂದಿದ್ದರೂ ಸಹ, ಆ ಕನ್ನಡಿಗಳನ್ನು ಸಹ ತಿರಸ್ಕರಿಸಲಾಗುತ್ತದೆ.

ಅದೇ ಹೆಸರಿನೊಂದಿಗೆ ನೋಡ್ ಅನ್ನು ಮರು-ಸೇರಿಸಲು, ಕಳೆದುಹೋದ ನೋಡ್ ಅನ್ನು ಮರೆಯಲು ನಾವು ಕ್ಲಸ್ಟರ್‌ಗೆ ಹೇಳುತ್ತೇವೆ (ಆಜ್ಞೆಯೊಂದಿಗೆ rabbitmqctl ಮರೆತು_ಕ್ಲಸ್ಟರ್_ನೋಡ್) ಮತ್ತು ಅದೇ ಹೋಸ್ಟ್ ಹೆಸರಿನೊಂದಿಗೆ ಹೊಸ ಬ್ರೋಕರ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸಿ. ಕ್ಲಸ್ಟರ್ ಕಳೆದುಹೋದ ನೋಡ್ ಅನ್ನು ನೆನಪಿಸಿಕೊಳ್ಳುವಾಗ, ಅದು ಹಳೆಯ ಸರತಿ ಮತ್ತು ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡದ ಕನ್ನಡಿಗಳನ್ನು ನೆನಪಿಸಿಕೊಳ್ಳುತ್ತದೆ. ಒಂದು ಕ್ಲಸ್ಟರ್ ಅನಾಥ ನೋಡ್ ಅನ್ನು ಮರೆಯಲು ಹೇಳಿದಾಗ, ಆ ಕ್ಯೂ ಕೂಡ ಮರೆತುಹೋಗುತ್ತದೆ. ಈಗ ನಾವು ಅದನ್ನು ಮರು ಘೋಷಿಸಬೇಕಾಗಿದೆ. ನಾವು ಎಲ್ಲಾ ಡೇಟಾವನ್ನು ಕಳೆದುಕೊಂಡಿದ್ದೇವೆ, ಆದರೂ ನಾವು ಡೇಟಾದ ಭಾಗಶಃ ಸೆಟ್ನೊಂದಿಗೆ ಕನ್ನಡಿಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡದ ಕನ್ನಡಿಗೆ ಬದಲಾಯಿಸುವುದು ಉತ್ತಮ!

ಆದ್ದರಿಂದ, ಹಸ್ತಚಾಲಿತ ಸಿಂಕ್ರೊನೈಸೇಶನ್ (ಮತ್ತು ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡಲು ವಿಫಲತೆ) ಸಂಯೋಜನೆಯೊಂದಿಗೆ ha-promote-on-failure=when-synced, ನನ್ನ ಅಭಿಪ್ರಾಯದಲ್ಲಿ, ಸಾಕಷ್ಟು ಅಪಾಯಕಾರಿ. ಡೇಟಾ ಸುರಕ್ಷತೆಗಾಗಿ ಈ ಆಯ್ಕೆಯು ಅಸ್ತಿತ್ವದಲ್ಲಿದೆ ಎಂದು ಡಾಕ್ಸ್ ಹೇಳುತ್ತದೆ, ಆದರೆ ಇದು ಎರಡು ಅಂಚಿನ ಚಾಕು.

ಮಾಸ್ಟರ್ ಮರುಸಮತೋಲನ

ಭರವಸೆ ನೀಡಿದಂತೆ, ನಾವು ಒಂದು ಅಥವಾ ಹಲವಾರು ನೋಡ್‌ಗಳಲ್ಲಿ ಎಲ್ಲಾ ಮಾಸ್ಟರ್‌ಗಳ ಸಂಗ್ರಹಣೆಯ ಸಮಸ್ಯೆಗೆ ಹಿಂತಿರುಗುತ್ತೇವೆ. ರೋಲಿಂಗ್ ಕ್ಲಸ್ಟರ್ ನವೀಕರಣದ ಪರಿಣಾಮವಾಗಿ ಇದು ಸಂಭವಿಸಬಹುದು. ಮೂರು-ನೋಡ್ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ, ಎಲ್ಲಾ ಮಾಸ್ಟರ್ ಕ್ಯೂಗಳು ಒಂದು ಅಥವಾ ಎರಡು ನೋಡ್‌ಗಳಲ್ಲಿ ಸಂಗ್ರಹಗೊಳ್ಳುತ್ತವೆ.

ಮರುಸಮತೋಲನ ಮಾಸ್ಟರ್ಸ್ ಎರಡು ಕಾರಣಗಳಿಗಾಗಿ ಸಮಸ್ಯಾತ್ಮಕವಾಗಬಹುದು:

• ಮರುಸಮತೋಲನವನ್ನು ನಿರ್ವಹಿಸಲು ಯಾವುದೇ ಉತ್ತಮ ಸಾಧನಗಳಿಲ್ಲ
• ಕ್ಯೂ ಸಿಂಕ್ರೊನೈಸೇಶನ್

ಮರುಸಮತೋಲನಕ್ಕಾಗಿ ಮೂರನೇ ವ್ಯಕ್ತಿ ಇದೆ ಪ್ಲಗಿನ್, ಇದು ಅಧಿಕೃತವಾಗಿ ಬೆಂಬಲಿತವಾಗಿಲ್ಲ. RabbitMQ ಕೈಪಿಡಿಯಲ್ಲಿ ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಪ್ಲಗಿನ್‌ಗಳಿಗೆ ಸಂಬಂಧಿಸಿದಂತೆ ಎಂದರು: “ಪ್ಲಗಿನ್ ಕೆಲವು ಹೆಚ್ಚುವರಿ ಕಾನ್ಫಿಗರೇಶನ್ ಮತ್ತು ವರದಿ ಮಾಡುವ ಪರಿಕರಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ, ಆದರೆ RabbitMQ ತಂಡವು ಬೆಂಬಲಿಸುವುದಿಲ್ಲ ಅಥವಾ ಪರಿಶೀಲಿಸುವುದಿಲ್ಲ. ನಿಮ್ಮ ಸ್ವಂತ ಅಪಾಯದಲ್ಲಿ ಬಳಸಿ."

HA ನೀತಿಗಳ ಮೂಲಕ ಮುಖ್ಯ ಸರತಿಯನ್ನು ಸರಿಸಲು ಮತ್ತೊಂದು ಟ್ರಿಕ್ ಇದೆ. ಕೈಪಿಡಿಯಲ್ಲಿ ಉಲ್ಲೇಖಿಸಲಾಗಿದೆ ಸ್ಕ್ರಿಪ್ಟ್ ಇದಕ್ಕಾಗಿ. ಇದು ಈ ರೀತಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ:

• ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ HA ನೀತಿಗಿಂತ ಹೆಚ್ಚಿನ ಆದ್ಯತೆಯನ್ನು ಹೊಂದಿರುವ ತಾತ್ಕಾಲಿಕ ನೀತಿಯನ್ನು ಬಳಸಿಕೊಂಡು ಎಲ್ಲಾ ಕನ್ನಡಿಗಳನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ.
• ನೋಡ್ ಮೋಡ್ ಅನ್ನು ಬಳಸಲು HA ತಾತ್ಕಾಲಿಕ ನೀತಿಯನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ, ಮಾಸ್ಟರ್ ಕ್ಯೂ ಅನ್ನು ವರ್ಗಾಯಿಸಬೇಕಾದ ನೋಡ್ ಅನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುತ್ತದೆ.
• ಪುಶ್ ವಲಸೆಗಾಗಿ ಸರದಿಯನ್ನು ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡುತ್ತದೆ.
• ವಲಸೆ ಪೂರ್ಣಗೊಂಡ ನಂತರ, ತಾತ್ಕಾಲಿಕ ನೀತಿಯನ್ನು ಅಳಿಸುತ್ತದೆ. ಆರಂಭಿಕ HA ನೀತಿಯು ಜಾರಿಗೆ ಬರುತ್ತದೆ ಮತ್ತು ಅಗತ್ಯವಿರುವ ಸಂಖ್ಯೆಯ ಕನ್ನಡಿಗಳನ್ನು ರಚಿಸಲಾಗುತ್ತದೆ.

ತೊಂದರೆಯೆಂದರೆ ನೀವು ದೊಡ್ಡ ಸರತಿ ಸಾಲುಗಳು ಅಥವಾ ಕಟ್ಟುನಿಟ್ಟಾದ ಪುನರಾವರ್ತನೆಯ ಅವಶ್ಯಕತೆಗಳನ್ನು ಹೊಂದಿದ್ದರೆ ಈ ವಿಧಾನವು ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ.

ಈಗ RabbitMQ ಕ್ಲಸ್ಟರ್‌ಗಳು ನೆಟ್ವರ್ಕ್ ವಿಭಾಗಗಳೊಂದಿಗೆ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ ಎಂಬುದನ್ನು ನೋಡೋಣ.

ಸಂಪರ್ಕದ ನಷ್ಟ

ವಿತರಣಾ ವ್ಯವಸ್ಥೆಯ ನೋಡ್‌ಗಳನ್ನು ನೆಟ್‌ವರ್ಕ್ ಲಿಂಕ್‌ಗಳಿಂದ ಸಂಪರ್ಕಿಸಲಾಗಿದೆ ಮತ್ತು ನೆಟ್‌ವರ್ಕ್ ಲಿಂಕ್‌ಗಳು ಸಂಪರ್ಕ ಕಡಿತಗೊಳ್ಳಬಹುದು. ಸ್ಥಗಿತಗಳ ಆವರ್ತನವು ಸ್ಥಳೀಯ ಮೂಲಸೌಕರ್ಯ ಅಥವಾ ಆಯ್ದ ಮೋಡದ ವಿಶ್ವಾಸಾರ್ಹತೆಯನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ. ಯಾವುದೇ ಸಂದರ್ಭದಲ್ಲಿ, ವಿತರಿಸಿದ ವ್ಯವಸ್ಥೆಗಳು ಅವುಗಳನ್ನು ನಿಭಾಯಿಸಲು ಶಕ್ತವಾಗಿರಬೇಕು. ಮತ್ತೊಮ್ಮೆ ನಾವು ಲಭ್ಯತೆ ಮತ್ತು ಸ್ಥಿರತೆಯ ನಡುವೆ ಆಯ್ಕೆಯನ್ನು ಹೊಂದಿದ್ದೇವೆ ಮತ್ತು ಮತ್ತೊಮ್ಮೆ ಒಳ್ಳೆಯ ಸುದ್ದಿ ಎಂದರೆ RabbitMQ ಎರಡೂ ಆಯ್ಕೆಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ (ಕೇವಲ ಒಂದೇ ಸಮಯದಲ್ಲಿ ಅಲ್ಲ).

RabbitMQ ನೊಂದಿಗೆ ನಮಗೆ ಎರಡು ಮುಖ್ಯ ಆಯ್ಕೆಗಳಿವೆ:

• ತಾರ್ಕಿಕ ವಿಭಜನೆಯನ್ನು ಅನುಮತಿಸಿ (ಸ್ಪ್ಲಿಟ್-ಮೆದುಳು). ಇದು ಲಭ್ಯತೆಯನ್ನು ಖಚಿತಪಡಿಸುತ್ತದೆ, ಆದರೆ ಡೇಟಾ ನಷ್ಟಕ್ಕೆ ಕಾರಣವಾಗಬಹುದು.
• ತಾರ್ಕಿಕ ಪ್ರತ್ಯೇಕತೆಯನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಿ. ಕ್ಲೈಂಟ್‌ಗಳು ಕ್ಲಸ್ಟರ್‌ಗೆ ಹೇಗೆ ಸಂಪರ್ಕಿಸುತ್ತಾರೆ ಎಂಬುದರ ಆಧಾರದ ಮೇಲೆ ಅಲ್ಪಾವಧಿಯ ಲಭ್ಯತೆಯ ನಷ್ಟಕ್ಕೆ ಕಾರಣವಾಗಬಹುದು. ಎರಡು-ನೋಡ್ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಸಂಪೂರ್ಣ ಅಲಭ್ಯತೆಗೆ ಸಹ ಕಾರಣವಾಗಬಹುದು.

ಆದರೆ ತಾರ್ಕಿಕ ಪ್ರತ್ಯೇಕತೆ ಏನು? ನೆಟ್ವರ್ಕ್ ಸಂಪರ್ಕಗಳ ನಷ್ಟದಿಂದಾಗಿ ಒಂದು ಕ್ಲಸ್ಟರ್ ಎರಡು ಭಾಗಗಳಾಗಿ ವಿಭಜನೆಯಾದಾಗ ಇದು ಸಂಭವಿಸುತ್ತದೆ. ಪ್ರತಿ ಬದಿಯಲ್ಲಿ, ಕನ್ನಡಿಗರನ್ನು ಮಾಸ್ಟರ್ ಆಗಿ ಬಡ್ತಿ ನೀಡಲಾಗುತ್ತದೆ, ಇದರಿಂದಾಗಿ ಪ್ರತಿ ಸರತಿಗೆ ಹಲವಾರು ಮಾಸ್ಟರ್‌ಗಳು ಅಂತಿಮವಾಗಿ ಇರುತ್ತಾರೆ.

ಅಕ್ಕಿ. 17. ಮುಖ್ಯ ಕ್ಯೂ ಮತ್ತು ಎರಡು ಕನ್ನಡಿಗಳು, ಪ್ರತಿಯೊಂದೂ ಪ್ರತ್ಯೇಕ ನೋಡ್‌ನಲ್ಲಿ. ನಂತರ ನೆಟ್ವರ್ಕ್ ವೈಫಲ್ಯ ಸಂಭವಿಸುತ್ತದೆ ಮತ್ತು ಒಂದು ಕನ್ನಡಿ ಬೇರ್ಪಡುತ್ತದೆ. ಬೇರ್ಪಟ್ಟ ನೋಡ್ ಇನ್ನೆರಡು ಉದುರಿಹೋಗಿರುವುದನ್ನು ನೋಡುತ್ತದೆ ಮತ್ತು ಅದರ ಕನ್ನಡಿಗಳನ್ನು ಮಾಸ್ಟರ್‌ಗೆ ಉತ್ತೇಜಿಸುತ್ತದೆ. ನಾವು ಈಗ ಎರಡು ಮುಖ್ಯ ಸಾಲುಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಬರೆಯಬಹುದಾದ ಮತ್ತು ಓದಬಹುದಾದ ಎರಡೂ.

ಪ್ರಕಾಶಕರು ಇಬ್ಬರೂ ಮಾಸ್ಟರ್‌ಗಳಿಗೆ ಡೇಟಾವನ್ನು ಕಳುಹಿಸಿದರೆ, ನಾವು ಸರದಿಯ ಎರಡು ವಿಭಿನ್ನ ಪ್ರತಿಗಳೊಂದಿಗೆ ಕೊನೆಗೊಳ್ಳುತ್ತೇವೆ.

RabbitMQ ನ ವಿಭಿನ್ನ ವಿಧಾನಗಳು ಲಭ್ಯತೆ ಅಥವಾ ಸ್ಥಿರತೆಯನ್ನು ಒದಗಿಸುತ್ತದೆ.

ನಿರ್ಲಕ್ಷಿಸು ಮೋಡ್ (ಡೀಫಾಲ್ಟ್)

ಈ ಮೋಡ್ ಪ್ರವೇಶವನ್ನು ಖಚಿತಪಡಿಸುತ್ತದೆ. ಸಂಪರ್ಕದ ನಷ್ಟದ ನಂತರ, ತಾರ್ಕಿಕ ಬೇರ್ಪಡಿಕೆ ಸಂಭವಿಸುತ್ತದೆ. ಸಂಪರ್ಕವನ್ನು ಮರುಸ್ಥಾಪಿಸಿದ ನಂತರ, ನಿರ್ವಾಹಕರು ಯಾವ ವಿಭಾಗಕ್ಕೆ ಆದ್ಯತೆ ನೀಡಬೇಕೆಂದು ನಿರ್ಧರಿಸಬೇಕು. ಕಳೆದುಕೊಳ್ಳುವ ಭಾಗವನ್ನು ಮರುಪ್ರಾರಂಭಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಆ ಬದಿಯಲ್ಲಿ ಸಂಗ್ರಹವಾದ ಎಲ್ಲಾ ಡೇಟಾ ಕಳೆದುಹೋಗುತ್ತದೆ.

ಅಕ್ಕಿ. 18. ಮೂರು ಪ್ರಕಾಶಕರು ಮೂರು ದಲ್ಲಾಳಿಗಳೊಂದಿಗೆ ಸಂಬಂಧ ಹೊಂದಿದ್ದಾರೆ. ಆಂತರಿಕವಾಗಿ, ಕ್ಲಸ್ಟರ್ ಎಲ್ಲಾ ವಿನಂತಿಗಳನ್ನು ಬ್ರೋಕರ್ 2 ನಲ್ಲಿನ ಮುಖ್ಯ ಸರತಿಗೆ ರವಾನಿಸುತ್ತದೆ.

ಈಗ ನಾವು ಬ್ರೋಕರ್ 3 ಅನ್ನು ಕಳೆದುಕೊಳ್ಳುತ್ತಿದ್ದೇವೆ. ಅವನು ಇತರ ದಲ್ಲಾಳಿಗಳು ಬಿದ್ದಿರುವುದನ್ನು ನೋಡುತ್ತಾನೆ ಮತ್ತು ತನ್ನ ಕನ್ನಡಿಯನ್ನು ಮಾಸ್ಟರ್‌ಗೆ ಪ್ರಚಾರ ಮಾಡುತ್ತಾನೆ. ಈ ರೀತಿಯಾಗಿ ತಾರ್ಕಿಕ ಬೇರ್ಪಡಿಕೆ ಸಂಭವಿಸುತ್ತದೆ.

ಅಕ್ಕಿ. 19. ತಾರ್ಕಿಕ ವಿಭಾಗ (ಸ್ಪ್ಲಿಟ್-ಮೆದುಳು). ದಾಖಲೆಗಳು ಎರಡು ಮುಖ್ಯ ಸಾಲುಗಳಿಗೆ ಹೋಗುತ್ತವೆ ಮತ್ತು ಎರಡು ಪ್ರತಿಗಳು ಭಿನ್ನವಾಗಿರುತ್ತವೆ.

ಸಂಪರ್ಕವನ್ನು ಪುನಃಸ್ಥಾಪಿಸಲಾಗಿದೆ, ಆದರೆ ತಾರ್ಕಿಕ ಪ್ರತ್ಯೇಕತೆಯು ಉಳಿದಿದೆ. ನಿರ್ವಾಹಕರು ಕಳೆದುಕೊಳ್ಳುವ ಭಾಗವನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ಆಯ್ಕೆ ಮಾಡಬೇಕು. ಕೆಳಗಿನ ಸಂದರ್ಭದಲ್ಲಿ, ನಿರ್ವಾಹಕರು ಬ್ರೋಕರ್ 3 ಅನ್ನು ರೀಬೂಟ್ ಮಾಡುತ್ತಾರೆ. ಅವರು ರವಾನಿಸಲು ನಿರ್ವಹಿಸದ ಎಲ್ಲಾ ಸಂದೇಶಗಳು ಕಳೆದುಹೋಗಿವೆ.

ಅಕ್ಕಿ. 20. ನಿರ್ವಾಹಕರು ಬ್ರೋಕರ್ 3 ಅನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುತ್ತಾರೆ.

ಅಕ್ಕಿ. 21. ನಿರ್ವಾಹಕರು ಬ್ರೋಕರ್ 3 ಅನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತಾರೆ ಮತ್ತು ಅದು ಕ್ಲಸ್ಟರ್‌ಗೆ ಸೇರುತ್ತದೆ, ಅಲ್ಲಿ ಉಳಿದಿರುವ ಎಲ್ಲಾ ಸಂದೇಶಗಳನ್ನು ಕಳೆದುಕೊಳ್ಳುತ್ತದೆ.

ಸಂಪರ್ಕದ ನಷ್ಟದ ಸಮಯದಲ್ಲಿ ಮತ್ತು ಅದರ ಮರುಸ್ಥಾಪನೆಯ ನಂತರ, ಕ್ಲಸ್ಟರ್ ಮತ್ತು ಈ ಸರತಿಯು ಓದಲು ಮತ್ತು ಬರೆಯಲು ಲಭ್ಯವಿತ್ತು.

ಆಟೋಹೀಲ್ ಮೋಡ್

ಇಗ್ನೋರ್ ಮೋಡ್‌ನಂತೆಯೇ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಸಂಪರ್ಕವನ್ನು ವಿಭಜಿಸಿದ ನಂತರ ಮತ್ತು ಮರುಸ್ಥಾಪಿಸಿದ ನಂತರ ಕ್ಲಸ್ಟರ್ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಕಳೆದುಕೊಳ್ಳುವ ಭಾಗವನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ. ಸೋತ ಭಾಗವು ಖಾಲಿ ಕ್ಲಸ್ಟರ್‌ಗೆ ಹಿಂತಿರುಗುತ್ತದೆ ಮತ್ತು ಸರತಿಯು ಆ ಭಾಗಕ್ಕೆ ಮಾತ್ರ ಕಳುಹಿಸಲಾದ ಎಲ್ಲಾ ಸಂದೇಶಗಳನ್ನು ಕಳೆದುಕೊಳ್ಳುತ್ತದೆ.

ಅಲ್ಪಸಂಖ್ಯಾತ ಮೋಡ್ ಅನ್ನು ವಿರಾಮಗೊಳಿಸಿ

ನಾವು ತಾರ್ಕಿಕ ವಿಭಜನೆಯನ್ನು ಅನುಮತಿಸಲು ಬಯಸದಿದ್ದರೆ, ಕ್ಲಸ್ಟರ್ ವಿಭಜನೆಯ ನಂತರ ಚಿಕ್ಕ ಭಾಗದಲ್ಲಿ ಓದುವಿಕೆ ಮತ್ತು ಬರಹಗಳನ್ನು ತ್ಯಜಿಸುವುದು ನಮ್ಮ ಏಕೈಕ ಆಯ್ಕೆಯಾಗಿದೆ. ಅದು ಚಿಕ್ಕದಾಗಿದೆ ಎಂದು ಬ್ರೋಕರ್ ನೋಡಿದಾಗ, ಅದು ಕೆಲಸವನ್ನು ಸ್ಥಗಿತಗೊಳಿಸುತ್ತದೆ, ಅಂದರೆ, ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಎಲ್ಲಾ ಸಂಪರ್ಕಗಳನ್ನು ಮುಚ್ಚುತ್ತದೆ ಮತ್ತು ಯಾವುದೇ ಹೊಸದನ್ನು ನಿರಾಕರಿಸುತ್ತದೆ. ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಒಮ್ಮೆ ಅದು ಸಂಪರ್ಕ ಮರುಸ್ಥಾಪನೆಗಾಗಿ ಪರಿಶೀಲಿಸುತ್ತದೆ. ಸಂಪರ್ಕವನ್ನು ಪುನಃಸ್ಥಾಪಿಸಿದ ನಂತರ, ಅದು ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಪುನರಾರಂಭಿಸುತ್ತದೆ ಮತ್ತು ಕ್ಲಸ್ಟರ್‌ಗೆ ಸೇರುತ್ತದೆ.

ಅಕ್ಕಿ. 22. ಮೂರು ಪ್ರಕಾಶಕರು ಮೂರು ದಲ್ಲಾಳಿಗಳೊಂದಿಗೆ ಸಂಬಂಧ ಹೊಂದಿದ್ದಾರೆ. ಆಂತರಿಕವಾಗಿ, ಕ್ಲಸ್ಟರ್ ಎಲ್ಲಾ ವಿನಂತಿಗಳನ್ನು ಬ್ರೋಕರ್ 2 ನಲ್ಲಿನ ಮುಖ್ಯ ಸರತಿಗೆ ರವಾನಿಸುತ್ತದೆ.

ಬ್ರೋಕರ್‌ಗಳು 1 ಮತ್ತು 2 ನಂತರ ಬ್ರೋಕರ್ 3 ರಿಂದ ಬೇರ್ಪಟ್ಟರು. ತಮ್ಮ ಕನ್ನಡಿಯನ್ನು ಮಾಸ್ಟರ್‌ಗೆ ಪ್ರಚಾರ ಮಾಡುವ ಬದಲು, ಬ್ರೋಕರ್ 3 ಅಮಾನತುಗೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಲಭ್ಯವಿಲ್ಲ.

ಅಕ್ಕಿ. 23. ಬ್ರೋಕರ್ 3 ವಿರಾಮಗೊಳಿಸುತ್ತದೆ, ಎಲ್ಲಾ ಕ್ಲೈಂಟ್‌ಗಳನ್ನು ಸಂಪರ್ಕ ಕಡಿತಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ಸಂಪರ್ಕ ವಿನಂತಿಗಳನ್ನು ತಿರಸ್ಕರಿಸುತ್ತದೆ.

ಸಂಪರ್ಕವನ್ನು ಪುನಃಸ್ಥಾಪಿಸಿದ ನಂತರ, ಅದು ಕ್ಲಸ್ಟರ್‌ಗೆ ಹಿಂತಿರುಗುತ್ತದೆ.

ಬ್ರೋಕರ್ 3 ನಲ್ಲಿ ಮುಖ್ಯ ಸರತಿ ಇರುವ ಇನ್ನೊಂದು ಉದಾಹರಣೆಯನ್ನು ನೋಡೋಣ.

ಅಕ್ಕಿ. 24. ಬ್ರೋಕರ್ 3 ನಲ್ಲಿ ಮುಖ್ಯ ಸರತಿ.

ನಂತರ ಅದೇ ಸಂಪರ್ಕದ ನಷ್ಟ ಸಂಭವಿಸುತ್ತದೆ. ಬ್ರೋಕರ್ 3 ವಿರಾಮಗೊಳಿಸುತ್ತದೆ ಏಕೆಂದರೆ ಅದು ಚಿಕ್ಕ ಭಾಗದಲ್ಲಿದೆ. ಇನ್ನೊಂದು ಬದಿಯಲ್ಲಿ, ಬ್ರೋಕರ್ 3 ಕುಸಿದಿದೆ ಎಂದು ನೋಡ್‌ಗಳು ನೋಡುತ್ತವೆ, ಆದ್ದರಿಂದ ಬ್ರೋಕರ್‌ಗಳು 1 ಮತ್ತು 2 ರ ಹಳೆಯ ಕನ್ನಡಿಯನ್ನು ಮಾಸ್ಟರ್‌ಗೆ ಬಡ್ತಿ ನೀಡಲಾಗುತ್ತದೆ.

ಅಕ್ಕಿ. 25. ಬ್ರೋಕರ್ 2 ಲಭ್ಯವಿಲ್ಲದಿದ್ದರೆ ಬ್ರೋಕರ್ 3 ಗೆ ಪರಿವರ್ತನೆ.

ಸಂಪರ್ಕವನ್ನು ಪುನಃಸ್ಥಾಪಿಸಿದಾಗ, ಬ್ರೋಕರ್ 3 ಕ್ಲಸ್ಟರ್‌ಗೆ ಸೇರುತ್ತದೆ.

ಅಕ್ಕಿ. 26. ಕ್ಲಸ್ಟರ್ ಸಾಮಾನ್ಯ ಕಾರ್ಯಾಚರಣೆಗೆ ಮರಳಿದೆ.

ಇಲ್ಲಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕಾದ ಪ್ರಮುಖ ವಿಷಯವೆಂದರೆ ನಾವು ಸ್ಥಿರತೆಯನ್ನು ಪಡೆಯುತ್ತೇವೆ, ಆದರೆ ನಾವು ಲಭ್ಯತೆಯನ್ನು ಸಹ ಪಡೆಯಬಹುದು, ವೇಳೆ ನಾವು ಗ್ರಾಹಕರನ್ನು ಹೆಚ್ಚಿನ ವಿಭಾಗಕ್ಕೆ ಯಶಸ್ವಿಯಾಗಿ ವರ್ಗಾಯಿಸುತ್ತೇವೆ. ಹೆಚ್ಚಿನ ಸಂದರ್ಭಗಳಲ್ಲಿ, ನಾನು ವೈಯಕ್ತಿಕವಾಗಿ ವಿರಾಮ ಅಲ್ಪಸಂಖ್ಯಾತ ಮೋಡ್ ಅನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತೇನೆ, ಆದರೆ ಇದು ನಿಜವಾಗಿಯೂ ವೈಯಕ್ತಿಕ ಪ್ರಕರಣವನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ.

ಲಭ್ಯತೆಯನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು, ಕ್ಲೈಂಟ್‌ಗಳು ಹೋಸ್ಟ್‌ಗೆ ಯಶಸ್ವಿಯಾಗಿ ಸಂಪರ್ಕ ಸಾಧಿಸುವುದನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುವುದು ಮುಖ್ಯವಾಗಿದೆ. ನಮ್ಮ ಆಯ್ಕೆಗಳನ್ನು ನೋಡೋಣ.

ಗ್ರಾಹಕರ ಸಂಪರ್ಕವನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುವುದು

ಸಂಪರ್ಕ ನಷ್ಟದ ನಂತರ ಕ್ಲಸ್ಟರ್‌ನ ಮುಖ್ಯ ಭಾಗಕ್ಕೆ ಅಥವಾ ವರ್ಕಿಂಗ್ ನೋಡ್‌ಗಳಿಗೆ (ಒಂದು ನೋಡ್ ವಿಫಲವಾದ ನಂತರ) ಕ್ಲೈಂಟ್‌ಗಳನ್ನು ಹೇಗೆ ನಿರ್ದೇಶಿಸುವುದು ಎಂಬುದರ ಕುರಿತು ನಾವು ಹಲವಾರು ಆಯ್ಕೆಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಮೊದಲಿಗೆ, ನಿರ್ದಿಷ್ಟ ಕ್ಯೂ ಅನ್ನು ನಿರ್ದಿಷ್ಟ ನೋಡ್‌ನಲ್ಲಿ ಹೋಸ್ಟ್ ಮಾಡಲಾಗಿದೆ ಎಂಬುದನ್ನು ನೆನಪಿನಲ್ಲಿಡೋಣ, ಆದರೆ ರೂಟಿಂಗ್ ಮತ್ತು ನೀತಿಗಳನ್ನು ಎಲ್ಲಾ ನೋಡ್‌ಗಳಲ್ಲಿ ಪುನರಾವರ್ತಿಸಲಾಗುತ್ತದೆ. ಗ್ರಾಹಕರು ಯಾವುದೇ ನೋಡ್‌ಗೆ ಸಂಪರ್ಕಿಸಬಹುದು ಮತ್ತು ಆಂತರಿಕ ರೂಟಿಂಗ್ ಅವರು ಎಲ್ಲಿಗೆ ಹೋಗಬೇಕೆಂದು ನಿರ್ದೇಶಿಸುತ್ತದೆ. ಆದರೆ ನೋಡ್ ಅನ್ನು ಅಮಾನತುಗೊಳಿಸಿದಾಗ, ಅದು ಸಂಪರ್ಕಗಳನ್ನು ತಿರಸ್ಕರಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಗ್ರಾಹಕರು ಇನ್ನೊಂದು ನೋಡ್‌ಗೆ ಸಂಪರ್ಕಿಸಬೇಕು. ನೋಡ್ ಉದುರಿಹೋದರೆ, ಅವನು ಸ್ವಲ್ಪವೇ ಮಾಡಬಹುದು.

ನಮ್ಮ ಆಯ್ಕೆಗಳು:

• ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಪ್ರವೇಶಿಸಲಾಗುತ್ತದೆ, ಅದು ನೋಡ್‌ಗಳ ಮೂಲಕ ಸರಳವಾಗಿ ಚಲಿಸುತ್ತದೆ ಮತ್ತು ಕ್ಲೈಂಟ್‌ಗಳು ಯಶಸ್ವಿಯಾಗುವವರೆಗೆ ಸಂಪರ್ಕಿಸಲು ಮರುಪ್ರಯತ್ನಿಸುತ್ತಾರೆ. ನೋಡ್ ಡೌನ್ ಆಗಿದ್ದರೆ ಅಥವಾ ಅಮಾನತುಗೊಂಡಿದ್ದರೆ, ಆ ನೋಡ್‌ಗೆ ಸಂಪರ್ಕಿಸುವ ಪ್ರಯತ್ನಗಳು ವಿಫಲಗೊಳ್ಳುತ್ತವೆ, ಆದರೆ ನಂತರದ ಪ್ರಯತ್ನಗಳು ಇತರ ಸರ್ವರ್‌ಗಳಿಗೆ ಹೋಗುತ್ತವೆ (ರೌಂಡ್-ರಾಬಿನ್ ಶೈಲಿಯಲ್ಲಿ). ಸಂಪರ್ಕದ ಅಲ್ಪಾವಧಿಯ ನಷ್ಟ ಅಥವಾ ಡೌನ್‌ಡ್ ಸರ್ವರ್‌ಗೆ ಇದು ಸೂಕ್ತವಾಗಿದೆ, ಅದನ್ನು ತ್ವರಿತವಾಗಿ ಹಿಂತಿರುಗಿಸಲಾಗುತ್ತದೆ.
• ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ ಮೂಲಕ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಪ್ರವೇಶಿಸಿ ಮತ್ತು ಅಮಾನತುಗೊಂಡ/ವಿಫಲವಾದ ನೋಡ್‌ಗಳನ್ನು ಪತ್ತೆಯಾದ ತಕ್ಷಣ ಪಟ್ಟಿಯಿಂದ ತೆಗೆದುಹಾಕಿ. ನಾವು ಇದನ್ನು ತ್ವರಿತವಾಗಿ ಮಾಡಿದರೆ ಮತ್ತು ಗ್ರಾಹಕರು ಸಂಪರ್ಕವನ್ನು ಮರುಪ್ರಯತ್ನಿಸಲು ಸಾಧ್ಯವಾದರೆ, ನಾವು ನಿರಂತರ ಲಭ್ಯತೆಯನ್ನು ಸಾಧಿಸುತ್ತೇವೆ.
• ಪ್ರತಿ ಕ್ಲೈಂಟ್‌ಗೆ ಎಲ್ಲಾ ನೋಡ್‌ಗಳ ಪಟ್ಟಿಯನ್ನು ನೀಡಿ, ಮತ್ತು ಸಂಪರ್ಕಿಸುವಾಗ ಕ್ಲೈಂಟ್ ಯಾದೃಚ್ಛಿಕವಾಗಿ ಅವುಗಳಲ್ಲಿ ಒಂದನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ. ಸಂಪರ್ಕಿಸಲು ಪ್ರಯತ್ನಿಸುವಾಗ ಅದು ದೋಷವನ್ನು ಸ್ವೀಕರಿಸಿದರೆ, ಅದು ಸಂಪರ್ಕಿಸುವವರೆಗೆ ಪಟ್ಟಿಯಲ್ಲಿರುವ ಮುಂದಿನ ನೋಡ್‌ಗೆ ಚಲಿಸುತ್ತದೆ.
• DNS ಬಳಸಿಕೊಂಡು ವಿಫಲ/ಅಮಾನತುಗೊಂಡ ನೋಡ್‌ನಿಂದ ಟ್ರಾಫಿಕ್ ಅನ್ನು ತೆಗೆದುಹಾಕಿ. ಇದನ್ನು ಸಣ್ಣ ಟಿಟಿಎಲ್ ಬಳಸಿ ಮಾಡಲಾಗುತ್ತದೆ.

ಸಂಶೋಧನೆಗಳು

RabbitMQ ಕ್ಲಸ್ಟರಿಂಗ್ ಅದರ ಅನುಕೂಲಗಳು ಮತ್ತು ಅನಾನುಕೂಲಗಳನ್ನು ಹೊಂದಿದೆ. ಅತ್ಯಂತ ಗಂಭೀರ ಅನಾನುಕೂಲಗಳು ಹೀಗಿವೆ:

• ಕ್ಲಸ್ಟರ್‌ಗೆ ಸೇರುವಾಗ, ನೋಡ್‌ಗಳು ತಮ್ಮ ಡೇಟಾವನ್ನು ತ್ಯಜಿಸುತ್ತವೆ;
• ಸಿಂಕ್ರೊನೈಸೇಶನ್ ಅನ್ನು ನಿರ್ಬಂಧಿಸುವುದರಿಂದ ಸರತಿಯು ಅಲಭ್ಯವಾಗಲು ಕಾರಣವಾಗುತ್ತದೆ.

ಎಲ್ಲಾ ಕಠಿಣ ನಿರ್ಧಾರಗಳು ಈ ಎರಡು ವಾಸ್ತುಶಿಲ್ಪದ ವೈಶಿಷ್ಟ್ಯಗಳಿಂದ ಹುಟ್ಟಿಕೊಂಡಿವೆ. ಕ್ಲಸ್ಟರ್ ಮರುಸೇರ್ಪಡೆಯಾದಾಗ RabbitMQ ಡೇಟಾವನ್ನು ಉಳಿಸಲು ಸಾಧ್ಯವಾದರೆ, ಸಿಂಕ್ರೊನೈಸೇಶನ್ ವೇಗವಾಗಿರುತ್ತದೆ. ಇದು ಸಿಂಕ್ರೊನೈಸೇಶನ್ ಅನ್ನು ನಿರ್ಬಂಧಿಸದಿರುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಹೊಂದಿದ್ದರೆ, ಅದು ದೊಡ್ಡ ಸರತಿ ಸಾಲುಗಳನ್ನು ಉತ್ತಮವಾಗಿ ಬೆಂಬಲಿಸುತ್ತದೆ. ಈ ಎರಡು ಸಮಸ್ಯೆಗಳನ್ನು ಸರಿಪಡಿಸುವುದು ದೋಷ-ಸಹಿಷ್ಣು ಮತ್ತು ಹೆಚ್ಚು ಲಭ್ಯವಿರುವ ಸಂದೇಶ ರವಾನೆ ತಂತ್ರಜ್ಞಾನವಾಗಿ RabbitMQ ನ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಉತ್ತಮಗೊಳಿಸುತ್ತದೆ. ಕೆಳಗಿನ ಸಂದರ್ಭಗಳಲ್ಲಿ ಕ್ಲಸ್ಟರಿಂಗ್‌ನೊಂದಿಗೆ RabbitMQ ಅನ್ನು ಶಿಫಾರಸು ಮಾಡಲು ನಾನು ಹಿಂಜರಿಯುತ್ತೇನೆ:

• ವಿಶ್ವಾಸಾರ್ಹವಲ್ಲದ ನೆಟ್‌ವರ್ಕ್.
• ವಿಶ್ವಾಸಾರ್ಹವಲ್ಲದ ಸಂಗ್ರಹಣೆ.
• ಬಹಳ ಉದ್ದದ ಸಾಲುಗಳು.

ಹೆಚ್ಚಿನ ಲಭ್ಯತೆಯ ಸೆಟ್ಟಿಂಗ್‌ಗಳಿಗೆ ಬಂದಾಗ, ಈ ಕೆಳಗಿನವುಗಳನ್ನು ಪರಿಗಣಿಸಿ:

• ha-promote-on-failure=always
• ha-sync-mode=manual
• cluster_partition_handling=ignore (ಅಥವಾ autoheal)
• ನಿರಂತರ ಸಂದೇಶಗಳು
• ಕೆಲವು ನೋಡ್ ವಿಫಲವಾದಾಗ ಕ್ಲೈಂಟ್‌ಗಳು ಸಕ್ರಿಯ ನೋಡ್‌ಗೆ ಸಂಪರ್ಕಗೊಳ್ಳುವುದನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ

ಸ್ಥಿರತೆಗಾಗಿ (ಡೇಟಾ ಭದ್ರತೆ), ಈ ಕೆಳಗಿನ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಪರಿಗಣಿಸಿ:

• ಗ್ರಾಹಕರ ಕಡೆಯಿಂದ ಪ್ರಕಾಶಕರು ದೃಢೀಕರಿಸುತ್ತಾರೆ ಮತ್ತು ಹಸ್ತಚಾಲಿತ ಸ್ವೀಕೃತಿಗಳು
• ha-promote-on-failure=when-synced, ಪ್ರಕಾಶಕರು ನಂತರ ಮತ್ತೆ ಪ್ರಯತ್ನಿಸಬಹುದಾದರೆ ಮತ್ತು ನೀವು ಅತ್ಯಂತ ವಿಶ್ವಾಸಾರ್ಹ ಸಂಗ್ರಹಣೆಯನ್ನು ಹೊಂದಿದ್ದರೆ! ಇಲ್ಲದಿದ್ದರೆ ಹಾಕಿ =always.
• ha-sync-mode=automatic (ಆದರೆ ದೊಡ್ಡ ನಿಷ್ಕ್ರಿಯ ಸರತಿ ಸಾಲುಗಳಿಗಾಗಿ ಹಸ್ತಚಾಲಿತ ಮೋಡ್ ಅಗತ್ಯವಾಗಬಹುದು; ಅಲಭ್ಯತೆಯು ಸಂದೇಶಗಳನ್ನು ಕಳೆದುಕೊಳ್ಳುತ್ತದೆಯೇ ಎಂಬುದನ್ನು ಸಹ ಪರಿಗಣಿಸಿ)
• ಅಲ್ಪಸಂಖ್ಯಾತ ಮೋಡ್ ಅನ್ನು ವಿರಾಮಗೊಳಿಸಿ
• ನಿರಂತರ ಸಂದೇಶಗಳು

ದೋಷ ಸಹಿಷ್ಣುತೆ ಮತ್ತು ಹೆಚ್ಚಿನ ಲಭ್ಯತೆಯ ಎಲ್ಲಾ ಸಮಸ್ಯೆಗಳನ್ನು ನಾವು ಇನ್ನೂ ಒಳಗೊಂಡಿಲ್ಲ; ಉದಾಹರಣೆಗೆ, ಆಡಳಿತಾತ್ಮಕ ಕಾರ್ಯವಿಧಾನಗಳನ್ನು ಸುರಕ್ಷಿತವಾಗಿ ನಿರ್ವಹಿಸುವುದು ಹೇಗೆ (ಉದಾಹರಣೆಗೆ ರೋಲಿಂಗ್ ನವೀಕರಣಗಳು). ನಾವು ಒಕ್ಕೂಟ ಮತ್ತು ಸಲಿಕೆ ಪ್ಲಗಿನ್ ಬಗ್ಗೆ ಮಾತನಾಡಬೇಕಾಗಿದೆ.

ನಾನು ಬೇರೆ ಯಾವುದನ್ನಾದರೂ ಕಳೆದುಕೊಂಡಿದ್ದರೆ, ದಯವಿಟ್ಟು ನನಗೆ ತಿಳಿಸಿ.

ನನ್ನನ್ನೂ ನೋಡಿ ಪೋಸ್ಟ್, ಈ ಲೇಖನದಲ್ಲಿ ವಿವರಿಸಲಾದ ಕೆಲವು ಸಂದೇಶ ನಷ್ಟದ ಸನ್ನಿವೇಶಗಳನ್ನು ಪರೀಕ್ಷಿಸಲು ಡಾಕರ್ ಮತ್ತು ಬ್ಲಾಕೇಡ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ನಾನು RabbitMQ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಹಾನಿಯನ್ನುಂಟುಮಾಡುತ್ತೇನೆ.

ಸರಣಿಯ ಹಿಂದಿನ ಲೇಖನಗಳು:
ಸಂಖ್ಯೆ 1 - habr.com/ru/company/itsumma/blog/416629
ಸಂಖ್ಯೆ 2 - habr.com/ru/company/itsumma/blog/418389
ಸಂಖ್ಯೆ 3 - habr.com/ru/company/itsumma/blog/437446

ಮೂಲ: www.habr.com