ರೆಡಿಸ್‌ನಿಂದ ರೆಡಿಸ್-ಕ್ಲಸ್ಟರ್‌ಗೆ ಸ್ಥಳಾಂತರಗೊಳ್ಳುವ ಬಗ್ಗೆ

ರೆಡಿಸ್‌ನಿಂದ ರೆಡಿಸ್-ಕ್ಲಸ್ಟರ್‌ಗೆ ಸ್ಥಳಾಂತರಗೊಳ್ಳುವ ಬಗ್ಗೆ

ಒಂದು ದಶಕಕ್ಕೂ ಹೆಚ್ಚು ಕಾಲ ಅಭಿವೃದ್ಧಿ ಹೊಂದುತ್ತಿರುವ ಉತ್ಪನ್ನಕ್ಕೆ ಬಂದರೆ, ಅದರಲ್ಲಿ ಹಳತಾದ ತಂತ್ರಜ್ಞಾನಗಳನ್ನು ಕಂಡುಹಿಡಿಯುವುದು ಆಶ್ಚರ್ಯವೇನಿಲ್ಲ. ಆದರೆ ಆರು ತಿಂಗಳಲ್ಲಿ ನೀವು ಲೋಡ್ ಅನ್ನು 10 ಪಟ್ಟು ಹೆಚ್ಚು ಇರಿಸಬೇಕಾದರೆ ಮತ್ತು ಬೀಳುವ ವೆಚ್ಚವು ನೂರಾರು ಪಟ್ಟು ಹೆಚ್ಚಾಗುತ್ತದೆ? ಈ ಸಂದರ್ಭದಲ್ಲಿ, ನಿಮಗೆ ತಂಪಾದ ಹೈಲೋಡ್ ಇಂಜಿನಿಯರ್ ಅಗತ್ಯವಿದೆ. ಆದರೆ ಸೇವಕಿ ಇಲ್ಲದ ಕಾರಣ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುವ ಜವಾಬ್ದಾರಿಯನ್ನು ನನಗೆ ವಹಿಸಿದರು. ಲೇಖನದ ಮೊದಲ ಭಾಗದಲ್ಲಿ ನಾವು ರೆಡಿಸ್‌ನಿಂದ ರೆಡಿಸ್-ಕ್ಲಸ್ಟರ್‌ಗೆ ಹೇಗೆ ಸ್ಥಳಾಂತರಗೊಂಡಿದ್ದೇವೆ ಎಂದು ನಾನು ನಿಮಗೆ ಹೇಳುತ್ತೇನೆ ಮತ್ತು ಎರಡನೇ ಭಾಗದಲ್ಲಿ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಹೇಗೆ ಬಳಸುವುದನ್ನು ಪ್ರಾರಂಭಿಸಬೇಕು ಮತ್ತು ಅದನ್ನು ಬಳಸುವಾಗ ಏನು ಗಮನ ಕೊಡಬೇಕು ಎಂಬುದರ ಕುರಿತು ನಾನು ಸಲಹೆ ನೀಡುತ್ತೇನೆ.

ತಂತ್ರಜ್ಞಾನ ಆಯ್ಕೆ

ಅದು ಕೆಟ್ಟದ್ದೇ? ಪ್ರತ್ಯೇಕ ರೆಡಿಸ್ (ಸ್ಟ್ಯಾಂಡಲೋನ್ ರೆಡಿಸ್) 1 ಮಾಸ್ಟರ್ ಮತ್ತು ಎನ್ ಗುಲಾಮರ ಸಂರಚನೆಯಲ್ಲಿ? ನಾನು ಅದನ್ನು ಬಳಕೆಯಲ್ಲಿಲ್ಲದ ತಂತ್ರಜ್ಞಾನ ಎಂದು ಏಕೆ ಕರೆಯುತ್ತೇನೆ?

ಇಲ್ಲ, ರೆಡಿಸ್ ಕೆಟ್ಟದ್ದಲ್ಲ ... ಆದಾಗ್ಯೂ, ನಿರ್ಲಕ್ಷಿಸಲಾಗದ ಕೆಲವು ನ್ಯೂನತೆಗಳಿವೆ.

  • ಮೊದಲನೆಯದಾಗಿ, ಮಾಸ್ಟರ್ ವೈಫಲ್ಯದ ನಂತರ ವಿಪತ್ತು ಚೇತರಿಕೆ ಕಾರ್ಯವಿಧಾನಗಳನ್ನು ರೆಡಿಸ್ ಬೆಂಬಲಿಸುವುದಿಲ್ಲ. ಈ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು, ನಾವು ಹೊಸ ಮಾಸ್ಟರ್‌ಗೆ ವಿಐಪಿಗಳ ಸ್ವಯಂಚಾಲಿತ ವರ್ಗಾವಣೆಯೊಂದಿಗೆ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಬಳಸಿದ್ದೇವೆ, ಗುಲಾಮರ ಪಾತ್ರವನ್ನು ಬದಲಾಯಿಸುತ್ತೇವೆ ಮತ್ತು ಉಳಿದವರನ್ನು ಬದಲಾಯಿಸುತ್ತೇವೆ. ಈ ಕಾರ್ಯವಿಧಾನವು ಕೆಲಸ ಮಾಡಿದೆ, ಆದರೆ ಅದನ್ನು ವಿಶ್ವಾಸಾರ್ಹ ಪರಿಹಾರ ಎಂದು ಕರೆಯಲಾಗಲಿಲ್ಲ. ಮೊದಲನೆಯದಾಗಿ, ಸುಳ್ಳು ಎಚ್ಚರಿಕೆಗಳು ಸಂಭವಿಸಿದವು, ಮತ್ತು ಎರಡನೆಯದಾಗಿ, ಇದು ಬಿಸಾಡಬಹುದಾದದು, ಮತ್ತು ಕಾರ್ಯಾಚರಣೆಯ ನಂತರ ಸ್ಪ್ರಿಂಗ್ ಅನ್ನು ಚಾರ್ಜ್ ಮಾಡಲು ಹಸ್ತಚಾಲಿತ ಕ್ರಮಗಳು ಬೇಕಾಗುತ್ತವೆ.

  • ಎರಡನೆಯದಾಗಿ, ಕೇವಲ ಒಬ್ಬ ಮಾಸ್ಟರ್ ಅನ್ನು ಹೊಂದಿರುವುದು ಶಾರ್ಡಿಂಗ್ ಸಮಸ್ಯೆಗೆ ಕಾರಣವಾಯಿತು. ನಾವು ಹಲವಾರು ಸ್ವತಂತ್ರ ಕ್ಲಸ್ಟರ್‌ಗಳನ್ನು "1 ಮಾಸ್ಟರ್ ಮತ್ತು ಎನ್ ಸ್ಲೇವ್ಸ್" ಅನ್ನು ರಚಿಸಬೇಕಾಗಿತ್ತು, ನಂತರ ಈ ಯಂತ್ರಗಳ ನಡುವೆ ಡೇಟಾಬೇಸ್‌ಗಳನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ವಿತರಿಸಿ ಮತ್ತು ನಾಳೆ ಡೇಟಾಬೇಸ್‌ಗಳಲ್ಲಿ ಒಂದನ್ನು ಪ್ರತ್ಯೇಕ ನಿದರ್ಶನಕ್ಕೆ ಸ್ಥಳಾಂತರಿಸುವಷ್ಟು ಊದಿಕೊಳ್ಳುವುದಿಲ್ಲ ಎಂದು ಭಾವಿಸುತ್ತೇವೆ.

ಆಯ್ಕೆಗಳು ಯಾವುವು?

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

ಬಳಕೆಯ ವಿಶೇಷತೆಗಳು

ರೆಡಿಸ್‌ನೊಂದಿಗೆ ನಾವು ಐತಿಹಾಸಿಕವಾಗಿ ಯಾವ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಿದ್ದೇವೆ ಮತ್ತು ನಾವು ಯಾವ ಕಾರ್ಯವನ್ನು ಬಳಸಿದ್ದೇವೆ ಎಂಬುದನ್ನು ನೋಡೋಣ:

  • 2GIS | ನಂತಹ ರಿಮೋಟ್ ಸೇವೆಗಳಿಗೆ ವಿನಂತಿಗಳ ಮೊದಲು ಸಂಗ್ರಹ ಗೋಲಾಂಗ್

    MGET MSET ಹೊಂದಿಸಿ "DB ಆಯ್ಕೆಮಾಡಿ"

  • MYSQL ಮೊದಲು ಸಂಗ್ರಹ | PHP

    ಹೊಂದಿಸಿ MGET MSET ಸ್ಕ್ಯಾನ್ "ಪ್ಯಾಟರ್ನ್ ಮೂಲಕ ಕೀ" "DB ಆಯ್ಕೆ ಮಾಡಿ"

  • ಅವಧಿಗಳು ಮತ್ತು ಚಾಲಕ ನಿರ್ದೇಶಾಂಕಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವ ಸೇವೆಗಾಗಿ ಮುಖ್ಯ ಸಂಗ್ರಹಣೆ | ಗೋಲಾಂಗ್

    ಹೊಂದಿಸಿ MGET MSET "DB ಆಯ್ಕೆಮಾಡಿ" "ಜಿಯೋ ಕೀ ಸೇರಿಸಿ" "GEO KEY ಪಡೆಯಿರಿ" ಸ್ಕ್ಯಾನ್ ಮಾಡಿ

ನೀವು ನೋಡುವಂತೆ, ಹೆಚ್ಚಿನ ಗಣಿತಶಾಸ್ತ್ರವಿಲ್ಲ. ಹಾಗಾದರೆ ಕಷ್ಟವೇನು? ಪ್ರತಿಯೊಂದು ವಿಧಾನವನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ನೋಡೋಣ.

ವಿಧಾನ
ವಿವರಣೆ
ರೆಡಿಸ್-ಕ್ಲಸ್ಟರ್‌ನ ವೈಶಿಷ್ಟ್ಯಗಳು
ನಿರ್ಧಾರವನ್ನು

ಸೆಟ್ ಪಡೆಯಿರಿ
ಕೀಲಿಯನ್ನು ಬರೆಯಿರಿ/ಓದಿರಿ

MGET MSET
ಬಹು ಕೀಲಿಗಳನ್ನು ಬರೆಯಿರಿ/ಓದಿ
ಕೀಲಿಗಳು ವಿವಿಧ ನೋಡ್‌ಗಳಲ್ಲಿರುತ್ತವೆ. ರೆಡಿಮೇಡ್ ಲೈಬ್ರರಿಗಳು ಒಂದು ನೋಡ್‌ನಲ್ಲಿ ಮಾತ್ರ ಬಹು-ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಮಾಡಬಹುದು
MGET ಅನ್ನು N GET ಕಾರ್ಯಾಚರಣೆಗಳ ಪೈಪ್‌ಲೈನ್‌ನೊಂದಿಗೆ ಬದಲಾಯಿಸಿ

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

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

ಜಿಒಒ
ಜಿಯೋಕಿಯೊಂದಿಗೆ ಕಾರ್ಯಾಚರಣೆಗಳು
ಜಿಯೋಕಿಯು ಚೂರುಚೂರಾಗಿಲ್ಲ

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

ರೆಡಿಸ್ ವಿರುದ್ಧ ರೆಡಿಸ್-ಕ್ಲಸ್ಟರ್

ಕ್ಲಸ್ಟರ್‌ಗೆ ಬದಲಾಯಿಸುವಾಗ ನಾವು ಏನು ಕಳೆದುಕೊಳ್ಳುತ್ತೇವೆ ಮತ್ತು ನಾವು ಏನು ಪಡೆಯುತ್ತೇವೆ?

  • ಅನಾನುಕೂಲಗಳು: ನಾವು ಹಲವಾರು ಡೇಟಾಬೇಸ್‌ಗಳ ಕಾರ್ಯವನ್ನು ಕಳೆದುಕೊಳ್ಳುತ್ತೇವೆ.
    • ನಾವು ಒಂದು ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ತಾರ್ಕಿಕವಾಗಿ ಸಂಬಂಧವಿಲ್ಲದ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸಲು ಬಯಸಿದರೆ, ನಾವು ಪೂರ್ವಪ್ರತ್ಯಯಗಳ ರೂಪದಲ್ಲಿ ಊರುಗೋಲುಗಳನ್ನು ಮಾಡಬೇಕಾಗುತ್ತದೆ.
    • SCAN, DBSIZE, CLEAR DB, ಇತ್ಯಾದಿಗಳಂತಹ ಎಲ್ಲಾ "ಬೇಸ್" ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ನಾವು ಕಳೆದುಕೊಳ್ಳುತ್ತೇವೆ.
    • ಬಹು-ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಹೆಚ್ಚು ಕಷ್ಟಕರವಾಗಿದೆ ಏಕೆಂದರೆ ಇದು ಹಲವಾರು ನೋಡ್‌ಗಳಿಗೆ ಪ್ರವೇಶದ ಅಗತ್ಯವಿರುತ್ತದೆ.
  • ಪ್ಲಸಸ್:
    • ಮಾಸ್ಟರ್ ವೈಫಲ್ಯದ ರೂಪದಲ್ಲಿ ತಪ್ಪು ಸಹಿಷ್ಣುತೆ.
    • ರೆಡಿಸ್ ಬದಿಯಲ್ಲಿ ಶಾರ್ಡಿಂಗ್.
    • ನೋಡ್‌ಗಳ ನಡುವೆ ಪರಮಾಣು ಮತ್ತು ಅಲಭ್ಯತೆಯಿಲ್ಲದೆ ಡೇಟಾವನ್ನು ವರ್ಗಾಯಿಸಿ.
    • ಅಲಭ್ಯತೆಯಿಲ್ಲದೆ ಸಾಮರ್ಥ್ಯ ಮತ್ತು ಲೋಡ್‌ಗಳನ್ನು ಸೇರಿಸಿ ಮತ್ತು ಮರುಹಂಚಿಕೆ ಮಾಡಿ.

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

ಸರಿಸಲು ತಯಾರಿ

ಚಲಿಸುವ ಅವಶ್ಯಕತೆಗಳೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸೋಣ:

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

ಕ್ಲಸ್ಟರ್ ನಿರ್ವಹಣೆ

ಚಲಿಸುವ ಮೊದಲು, ನಾವು ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಬೆಂಬಲಿಸಬಹುದೇ ಎಂದು ನಾವು ಯೋಚಿಸಬೇಕು:

  • ಪಟ್ಟಿಯಲ್ಲಿ. CPU ಲೋಡ್, ಮೆಮೊರಿ ಬಳಕೆ, ಕ್ಲೈಂಟ್‌ಗಳ ಸಂಖ್ಯೆ, GET, SET, AUTH ಕಾರ್ಯಾಚರಣೆಗಳು ಇತ್ಯಾದಿಗಳನ್ನು ಗ್ರಾಫ್ ಮಾಡಲು ನಾವು Prometheus ಮತ್ತು Grafana ಅನ್ನು ಬಳಸುತ್ತೇವೆ.
  • ಪರಿಣಿತಿ. ನಾಳೆ ನಿಮ್ಮ ಜವಾಬ್ದಾರಿಯ ಅಡಿಯಲ್ಲಿ ನೀವು ಒಂದು ದೊಡ್ಡ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಹೊಂದಿರುತ್ತೀರಿ ಎಂದು ಕಲ್ಪಿಸಿಕೊಳ್ಳಿ. ಅದು ಒಡೆದರೆ, ನೀವು ಹೊರತುಪಡಿಸಿ ಯಾರೂ ಅದನ್ನು ಸರಿಪಡಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ಅವನು ನಿಧಾನಗೊಳಿಸಲು ಪ್ರಾರಂಭಿಸಿದರೆ, ಎಲ್ಲರೂ ನಿಮ್ಮ ಕಡೆಗೆ ಓಡುತ್ತಾರೆ. ನೀವು ಸಂಪನ್ಮೂಲಗಳನ್ನು ಸೇರಿಸಲು ಅಥವಾ ಲೋಡ್ ಅನ್ನು ಮರುಹಂಚಿಕೆ ಮಾಡಲು ಬಯಸಿದರೆ, ನಿಮ್ಮ ಬಳಿಗೆ ಹಿಂತಿರುಗಿ. 25 ಕ್ಕೆ ಬೂದು ಬಣ್ಣಕ್ಕೆ ತಿರುಗದಿರಲು, ಈ ಪ್ರಕರಣಗಳಿಗೆ ಒದಗಿಸಲು ಮತ್ತು ಕೆಲವು ಕ್ರಿಯೆಗಳ ಅಡಿಯಲ್ಲಿ ತಂತ್ರಜ್ಞಾನವು ಹೇಗೆ ವರ್ತಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಮುಂಚಿತವಾಗಿ ಪರಿಶೀಲಿಸಲು ಸಲಹೆ ನೀಡಲಾಗುತ್ತದೆ. "ಪರಿಣಿತಿ" ವಿಭಾಗದಲ್ಲಿ ಇದರ ಬಗ್ಗೆ ಹೆಚ್ಚು ವಿವರವಾಗಿ ಮಾತನಾಡೋಣ.
  • ಮಾನಿಟರಿಂಗ್ ಮತ್ತು ಎಚ್ಚರಿಕೆಗಳು. ಕ್ಲಸ್ಟರ್ ಮುರಿದಾಗ, ನೀವು ಅದರ ಬಗ್ಗೆ ಮೊದಲು ತಿಳಿದುಕೊಳ್ಳಲು ಬಯಸುತ್ತೀರಿ. ಇಲ್ಲಿ ನಾವು ಎಲ್ಲಾ ನೋಡ್‌ಗಳು ಕ್ಲಸ್ಟರ್‌ನ ಸ್ಥಿತಿಯ ಬಗ್ಗೆ ಒಂದೇ ಮಾಹಿತಿಯನ್ನು ಹಿಂದಿರುಗಿಸುವ ಅಧಿಸೂಚನೆಗೆ ನಮ್ಮನ್ನು ಸೀಮಿತಗೊಳಿಸಿದ್ದೇವೆ (ಹೌದು, ಇದು ವಿಭಿನ್ನವಾಗಿ ನಡೆಯುತ್ತದೆ). ಮತ್ತು ರೆಡಿಸ್ ಕ್ಲೈಂಟ್ ಸೇವೆಗಳಿಂದ ಎಚ್ಚರಿಕೆಗಳ ಮೂಲಕ ಇತರ ಸಮಸ್ಯೆಗಳನ್ನು ಹೆಚ್ಚು ತ್ವರಿತವಾಗಿ ಗಮನಿಸಬಹುದು.

ಸ್ಥಳಾಂತರ

ನಾವು ಹೇಗೆ ಚಲಿಸುತ್ತೇವೆ:

  • ಮೊದಲನೆಯದಾಗಿ, ಕ್ಲಸ್ಟರ್ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ನೀವು ಗ್ರಂಥಾಲಯವನ್ನು ಸಿದ್ಧಪಡಿಸಬೇಕು. ನಾವು ಗೋ ಆವೃತ್ತಿಗೆ ಗೋ-ರೆಡಿಸ್ ಅನ್ನು ಆಧಾರವಾಗಿ ತೆಗೆದುಕೊಂಡಿದ್ದೇವೆ ಮತ್ತು ಅದನ್ನು ನಮಗೆ ಸರಿಹೊಂದುವಂತೆ ಸ್ವಲ್ಪ ಬದಲಾಯಿಸಿದ್ದೇವೆ. ನಾವು ಪೈಪ್‌ಲೈನ್‌ಗಳ ಮೂಲಕ ಬಹು-ವಿಧಾನಗಳನ್ನು ಜಾರಿಗೊಳಿಸಿದ್ದೇವೆ ಮತ್ತು ವಿನಂತಿಗಳನ್ನು ಪುನರಾವರ್ತಿಸುವ ನಿಯಮಗಳನ್ನು ಸ್ವಲ್ಪಮಟ್ಟಿಗೆ ಸರಿಪಡಿಸಿದ್ದೇವೆ. PHP ಆವೃತ್ತಿಯು ಹೆಚ್ಚಿನ ಸಮಸ್ಯೆಗಳನ್ನು ಹೊಂದಿತ್ತು, ಆದರೆ ನಾವು ಅಂತಿಮವಾಗಿ php-redis ನಲ್ಲಿ ನೆಲೆಸಿದ್ದೇವೆ. ಅವರು ಇತ್ತೀಚೆಗೆ ಕ್ಲಸ್ಟರ್ ಬೆಂಬಲವನ್ನು ಪರಿಚಯಿಸಿದರು ಮತ್ತು ಇದು ನಮ್ಮ ಅಭಿಪ್ರಾಯದಲ್ಲಿ ಉತ್ತಮವಾಗಿ ಕಾಣುತ್ತದೆ.
  • ಮುಂದೆ ನೀವು ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಸ್ವತಃ ನಿಯೋಜಿಸಬೇಕಾಗಿದೆ. ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್ ಅನ್ನು ಆಧರಿಸಿ ಇದನ್ನು ಅಕ್ಷರಶಃ ಎರಡು ಆಜ್ಞೆಗಳಲ್ಲಿ ಮಾಡಲಾಗುತ್ತದೆ. ನಾವು ಸೆಟ್ಟಿಂಗ್ ಅನ್ನು ಕೆಳಗೆ ಹೆಚ್ಚು ವಿವರವಾಗಿ ಚರ್ಚಿಸುತ್ತೇವೆ.
  • ಕ್ರಮೇಣ ಚಲಿಸಲು ನಾವು ಡ್ರೈ ಮೋಡ್ ಅನ್ನು ಬಳಸುತ್ತೇವೆ. ನಾವು ಒಂದೇ ಇಂಟರ್ಫೇಸ್‌ನೊಂದಿಗೆ ಲೈಬ್ರರಿಯ ಎರಡು ಆವೃತ್ತಿಗಳನ್ನು ಹೊಂದಿರುವುದರಿಂದ (ಒಂದು ಸಾಮಾನ್ಯ ಆವೃತ್ತಿಗೆ, ಇನ್ನೊಂದು ಕ್ಲಸ್ಟರ್‌ಗೆ), ಪ್ರತ್ಯೇಕ ಆವೃತ್ತಿಯೊಂದಿಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಮತ್ತು ಕ್ಲಸ್ಟರ್‌ಗೆ ಎಲ್ಲಾ ವಿನಂತಿಗಳನ್ನು ಸಮಾನಾಂತರವಾಗಿ ನಕಲು ಮಾಡುವ ಹೊದಿಕೆಯನ್ನು ರಚಿಸಲು ಏನೂ ವೆಚ್ಚವಾಗುವುದಿಲ್ಲ, ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ಹೋಲಿಸಿ ಮತ್ತು ಲಾಗ್‌ಗಳಲ್ಲಿ ವ್ಯತ್ಯಾಸಗಳನ್ನು ಬರೆಯಿರಿ (ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ ನ್ಯೂರೆಲಿಕ್‌ನಲ್ಲಿ). ಹೀಗಾಗಿ, ರೋಲ್‌ಔಟ್ ಸಮಯದಲ್ಲಿ ಕ್ಲಸ್ಟರ್ ಆವೃತ್ತಿಯು ಮುರಿದುಹೋದರೂ, ನಮ್ಮ ಉತ್ಪಾದನೆಯು ಪರಿಣಾಮ ಬೀರುವುದಿಲ್ಲ.
  • ಡ್ರೈ ಮೋಡ್‌ನಲ್ಲಿ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಹೊರತಂದ ನಂತರ, ನಾವು ಪ್ರತಿಕ್ರಿಯೆಯ ವ್ಯತ್ಯಾಸಗಳ ಗ್ರಾಫ್ ಅನ್ನು ಶಾಂತವಾಗಿ ನೋಡಬಹುದು. ದೋಷದ ಪ್ರಮಾಣವು ನಿಧಾನವಾಗಿ ಆದರೆ ಖಚಿತವಾಗಿ ಕೆಲವು ಸಣ್ಣ ಸ್ಥಿರತೆಯ ಕಡೆಗೆ ಚಲಿಸಿದರೆ, ಎಲ್ಲವೂ ಉತ್ತಮವಾಗಿರುತ್ತದೆ. ಇನ್ನೂ ಏಕೆ ಭಿನ್ನಾಭಿಪ್ರಾಯಗಳಿವೆ? ಪ್ರತ್ಯೇಕ ಆವೃತ್ತಿಯಲ್ಲಿ ರೆಕಾರ್ಡಿಂಗ್ ಕ್ಲಸ್ಟರ್‌ಗಿಂತ ಸ್ವಲ್ಪ ಮುಂಚಿತವಾಗಿ ಸಂಭವಿಸುತ್ತದೆ ಮತ್ತು ಮೈಕ್ರೊಲ್ಯಾಗ್‌ನಿಂದಾಗಿ, ಡೇಟಾ ಬೇರೆಯಾಗಬಹುದು. ವ್ಯತ್ಯಾಸದ ಲಾಗ್‌ಗಳನ್ನು ನೋಡುವುದು ಮಾತ್ರ ಉಳಿದಿದೆ, ಮತ್ತು ಅವೆಲ್ಲವನ್ನೂ ದಾಖಲೆಯ ಪರಮಾಣು ಅಲ್ಲದ ಮೂಲಕ ವಿವರಿಸಿದರೆ, ನಾವು ಮುಂದುವರಿಯಬಹುದು.
  • ಈಗ ನೀವು ಡ್ರೈ ಮೋಡ್ ಅನ್ನು ವಿರುದ್ಧ ದಿಕ್ಕಿನಲ್ಲಿ ಬದಲಾಯಿಸಬಹುದು. ನಾವು ಕ್ಲಸ್ಟರ್‌ನಿಂದ ಬರೆಯುತ್ತೇವೆ ಮತ್ತು ಓದುತ್ತೇವೆ ಮತ್ತು ಅದನ್ನು ಪ್ರತ್ಯೇಕ ಆವೃತ್ತಿಗೆ ನಕಲು ಮಾಡುತ್ತೇವೆ. ಯಾವುದಕ್ಕಾಗಿ? ಮುಂದಿನ ವಾರದಲ್ಲಿ ನಾನು ಕ್ಲಸ್ಟರ್‌ನ ಕೆಲಸವನ್ನು ವೀಕ್ಷಿಸಲು ಬಯಸುತ್ತೇನೆ. ಪೀಕ್ ಲೋಡ್‌ನಲ್ಲಿ ಸಮಸ್ಯೆಗಳಿವೆ ಎಂದು ಇದ್ದಕ್ಕಿದ್ದಂತೆ ತಿರುಗಿದರೆ ಅಥವಾ ನಾವು ಏನನ್ನಾದರೂ ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳದಿದ್ದರೆ, ನಾವು ಯಾವಾಗಲೂ ಹಳೆಯ ಕೋಡ್‌ಗೆ ತುರ್ತು ರೋಲ್‌ಬ್ಯಾಕ್ ಮತ್ತು ಡ್ರೈ-ಮೋಡ್‌ಗೆ ಪ್ರಸ್ತುತ ಡೇಟಾಗೆ ಧನ್ಯವಾದಗಳು.
  • ಡ್ರೈ-ಮೋಡ್ ಅನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಲು ಮತ್ತು ಪ್ರತ್ಯೇಕ ಆವೃತ್ತಿಯನ್ನು ಕೆಡವಲು ಮಾತ್ರ ಉಳಿದಿದೆ.

ಪರಿಣತಿ

ಮೊದಲಿಗೆ, ಕ್ಲಸ್ಟರ್ ವಿನ್ಯಾಸದ ಬಗ್ಗೆ ಸಂಕ್ಷಿಪ್ತವಾಗಿ.

ಮೊದಲನೆಯದಾಗಿ, ರೆಡಿಸ್ ಒಂದು ಪ್ರಮುಖ ಮೌಲ್ಯದ ಅಂಗಡಿಯಾಗಿದೆ. ಅನಿಯಂತ್ರಿತ ತಂತಿಗಳನ್ನು ಕೀಲಿಗಳಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ. ಸಂಖ್ಯೆಗಳು, ತಂತಿಗಳು ಮತ್ತು ಸಂಪೂರ್ಣ ರಚನೆಗಳನ್ನು ಮೌಲ್ಯಗಳಾಗಿ ಬಳಸಬಹುದು. ನಂತರದವುಗಳಲ್ಲಿ ಹೆಚ್ಚಿನವುಗಳಿವೆ, ಆದರೆ ಸಾಮಾನ್ಯ ರಚನೆಯನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಇದು ನಮಗೆ ಮುಖ್ಯವಲ್ಲ.
ಕೀಗಳ ನಂತರ ಅಮೂರ್ತತೆಯ ಮುಂದಿನ ಹಂತವೆಂದರೆ ಸ್ಲಾಟ್‌ಗಳು (SLOTS). ಪ್ರತಿ ಕೀಲಿಯು 16 ಸ್ಲಾಟ್‌ಗಳಲ್ಲಿ ಒಂದಕ್ಕೆ ಸೇರಿದೆ. ಪ್ರತಿ ಸ್ಲಾಟ್ ಒಳಗೆ ಯಾವುದೇ ಸಂಖ್ಯೆಯ ಕೀಗಳು ಇರಬಹುದು. ಹೀಗಾಗಿ, ಎಲ್ಲಾ ಕೀಲಿಗಳನ್ನು 383 ಡಿಸ್ಜಾಯಿಂಟ್ ಸೆಟ್‌ಗಳಾಗಿ ವಿಂಗಡಿಸಲಾಗಿದೆ.
ರೆಡಿಸ್‌ನಿಂದ ರೆಡಿಸ್-ಕ್ಲಸ್ಟರ್‌ಗೆ ಸ್ಥಳಾಂತರಗೊಳ್ಳುವ ಬಗ್ಗೆ

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

ಎಲ್ಲಾ ಕೀಗಳನ್ನು ಸ್ಲಾಟ್‌ಗಳ ನಡುವೆ ವಿತರಿಸಿದ ನಂತರ ಮತ್ತು ಸ್ಲಾಟ್‌ಗಳು ಮಾಸ್ಟರ್ ನೋಡ್‌ಗಳ ನಡುವೆ ಚದುರಿದ ನಂತರ, ಪ್ರತಿ ಮಾಸ್ಟರ್ ನೋಡ್‌ಗೆ ಅನಿಯಂತ್ರಿತ ಸಂಖ್ಯೆಯ ಸ್ಲೇವ್ ನೋಡ್‌ಗಳನ್ನು ಸೇರಿಸಬಹುದು. ಅಂತಹ ಪ್ರತಿಯೊಂದು ಮಾಸ್ಟರ್-ಸ್ಲೇವ್ ಲಿಂಕ್‌ನಲ್ಲಿ, ಸಾಮಾನ್ಯ ಪ್ರತಿಕೃತಿಯು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಓದುವ ವಿನಂತಿಗಳನ್ನು ಅಳೆಯಲು ಮತ್ತು ಮಾಸ್ಟರ್ ವೈಫಲ್ಯದ ಸಂದರ್ಭದಲ್ಲಿ ವಿಫಲಗೊಳ್ಳಲು ಗುಲಾಮರ ಅಗತ್ಯವಿದೆ.
ರೆಡಿಸ್‌ನಿಂದ ರೆಡಿಸ್-ಕ್ಲಸ್ಟರ್‌ಗೆ ಸ್ಥಳಾಂತರಗೊಳ್ಳುವ ಬಗ್ಗೆ

ಈಗ ಕಾರ್ಯಾಚರಣೆಗಳ ಬಗ್ಗೆ ಮಾತನಾಡೋಣ, ಅದನ್ನು ಮಾಡಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ.

ನಾವು Redis-CLI ಮೂಲಕ ಸಿಸ್ಟಮ್ ಅನ್ನು ಪ್ರವೇಶಿಸುತ್ತೇವೆ. ರೆಡಿಸ್ ಒಂದೇ ಪ್ರವೇಶ ಬಿಂದುವನ್ನು ಹೊಂದಿಲ್ಲದ ಕಾರಣ, ನೀವು ಯಾವುದೇ ನೋಡ್‌ಗಳಲ್ಲಿ ಈ ಕೆಳಗಿನ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಮಾಡಬಹುದು. ಪ್ರತಿ ಹಂತದಲ್ಲಿ ನಾನು ಲೋಡ್ ಅಡಿಯಲ್ಲಿ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ನಿರ್ವಹಿಸುವ ಸಾಧ್ಯತೆಯನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಗಮನ ಸೆಳೆಯುತ್ತೇನೆ.

  • ನಮಗೆ ಅಗತ್ಯವಿರುವ ಮೊದಲ ಮತ್ತು ಪ್ರಮುಖ ವಿಷಯವೆಂದರೆ ಕ್ಲಸ್ಟರ್ ನೋಡ್ಗಳ ಕಾರ್ಯಾಚರಣೆ. ಇದು ಕ್ಲಸ್ಟರ್‌ನ ಸ್ಥಿತಿಯನ್ನು ಹಿಂದಿರುಗಿಸುತ್ತದೆ, ನೋಡ್‌ಗಳ ಪಟ್ಟಿ, ಅವುಗಳ ಪಾತ್ರಗಳು, ಸ್ಲಾಟ್ ವಿತರಣೆ ಇತ್ಯಾದಿಗಳನ್ನು ತೋರಿಸುತ್ತದೆ. ಕ್ಲಸ್ಟರ್ ಮಾಹಿತಿ ಮತ್ತು ಕ್ಲಸ್ಟರ್ ಸ್ಲಾಟ್‌ಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಹೆಚ್ಚಿನ ಮಾಹಿತಿಯನ್ನು ಪಡೆಯಬಹುದು.
  • ನೋಡ್‌ಗಳನ್ನು ಸೇರಿಸಲು ಮತ್ತು ತೆಗೆದುಹಾಕಲು ಸಾಧ್ಯವಾಗುವುದು ಒಳ್ಳೆಯದು. ಈ ಉದ್ದೇಶಕ್ಕಾಗಿ ಕ್ಲಸ್ಟರ್ ಭೇಟಿ ಮತ್ತು ಕ್ಲಸ್ಟರ್ ಮರೆತು ಕಾರ್ಯಾಚರಣೆಗಳು ಇವೆ. ಕ್ಲಸ್ಟರ್ ಮರೆತು ಪ್ರತಿಯೊಂದು ನೋಡ್‌ಗೆ, ಮಾಸ್ಟರ್‌ಗಳು ಮತ್ತು ಪ್ರತಿಕೃತಿಗಳಿಗೆ ಅನ್ವಯಿಸಬೇಕು ಎಂಬುದನ್ನು ದಯವಿಟ್ಟು ಗಮನಿಸಿ. ಮತ್ತು ಕ್ಲಸ್ಟರ್ ಭೇಟಿಯನ್ನು ಒಂದು ನೋಡ್‌ನಲ್ಲಿ ಮಾತ್ರ ಕರೆಯಬೇಕಾಗುತ್ತದೆ. ಈ ವ್ಯತ್ಯಾಸವು ಗೊಂದಲವನ್ನು ಉಂಟುಮಾಡಬಹುದು, ಆದ್ದರಿಂದ ನೀವು ನಿಮ್ಮ ಕ್ಲಸ್ಟರ್‌ನೊಂದಿಗೆ ಲೈವ್ ಮಾಡುವ ಮೊದಲು ಅದರ ಬಗ್ಗೆ ತಿಳಿದುಕೊಳ್ಳುವುದು ಉತ್ತಮವಾಗಿದೆ. ನೋಡ್ ಅನ್ನು ಸೇರಿಸುವುದು ಯುದ್ಧದಲ್ಲಿ ಸುರಕ್ಷಿತವಾಗಿ ಮಾಡಲಾಗುತ್ತದೆ ಮತ್ತು ಕ್ಲಸ್ಟರ್ನ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಯಾವುದೇ ರೀತಿಯಲ್ಲಿ ಪರಿಣಾಮ ಬೀರುವುದಿಲ್ಲ (ಇದು ತಾರ್ಕಿಕವಾಗಿದೆ). ನೀವು ಕ್ಲಸ್ಟರ್‌ನಿಂದ ನೋಡ್ ಅನ್ನು ತೆಗೆದುಹಾಕಲು ಹೋದರೆ, ಅದರಲ್ಲಿ ಯಾವುದೇ ಸ್ಲಾಟ್‌ಗಳು ಉಳಿದಿಲ್ಲ ಎಂದು ನೀವು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಬೇಕು (ಇಲ್ಲದಿದ್ದರೆ ನೀವು ಈ ನೋಡ್‌ನಲ್ಲಿರುವ ಎಲ್ಲಾ ಕೀಗಳಿಗೆ ಪ್ರವೇಶವನ್ನು ಕಳೆದುಕೊಳ್ಳುವ ಅಪಾಯವಿದೆ). ಅಲ್ಲದೆ, ಗುಲಾಮರನ್ನು ಹೊಂದಿರುವ ಮಾಸ್ಟರ್ ಅನ್ನು ಅಳಿಸಬೇಡಿ, ಇಲ್ಲದಿದ್ದರೆ ಹೊಸ ಯಜಮಾನನಿಗೆ ಅನಗತ್ಯವಾದ ಮತವನ್ನು ನಡೆಸಲಾಗುತ್ತದೆ. ನೋಡ್‌ಗಳು ಇನ್ನು ಮುಂದೆ ಸ್ಲಾಟ್‌ಗಳನ್ನು ಹೊಂದಿಲ್ಲದಿದ್ದರೆ, ಇದು ಒಂದು ಸಣ್ಣ ಸಮಸ್ಯೆಯಾಗಿದೆ, ಆದರೆ ನಾವು ಮೊದಲು ಗುಲಾಮರನ್ನು ಅಳಿಸಬಹುದಾದರೆ ನಮಗೆ ಹೆಚ್ಚುವರಿ ಆಯ್ಕೆಗಳು ಏಕೆ ಬೇಕು.
  • ನೀವು ಮಾಸ್ಟರ್ ಮತ್ತು ಸ್ಲೇವ್ ಸ್ಥಾನಗಳನ್ನು ಬಲವಂತವಾಗಿ ಸ್ವ್ಯಾಪ್ ಮಾಡಬೇಕಾದರೆ, ಕ್ಲಸ್ಟರ್ ಫೇಲ್ಓವರ್ ಆಜ್ಞೆಯು ಮಾಡುತ್ತದೆ. ಯುದ್ಧದಲ್ಲಿ ಅದನ್ನು ಕರೆಯುವಾಗ, ಕಾರ್ಯಾಚರಣೆಯ ಸಮಯದಲ್ಲಿ ಮಾಸ್ಟರ್ ಲಭ್ಯವಿರುವುದಿಲ್ಲ ಎಂದು ನೀವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು. ವಿಶಿಷ್ಟವಾಗಿ ಸ್ವಿಚ್ ಒಂದು ಸೆಕೆಂಡಿಗಿಂತ ಕಡಿಮೆ ಸಮಯದಲ್ಲಿ ಸಂಭವಿಸುತ್ತದೆ, ಆದರೆ ಪರಮಾಣು ಅಲ್ಲ. ಈ ಸಮಯದಲ್ಲಿ ಮಾಸ್ಟರ್‌ಗೆ ಕೆಲವು ವಿನಂತಿಗಳು ವಿಫಲಗೊಳ್ಳುತ್ತವೆ ಎಂದು ನೀವು ನಿರೀಕ್ಷಿಸಬಹುದು.
  • ಕ್ಲಸ್ಟರ್‌ನಿಂದ ನೋಡ್ ಅನ್ನು ತೆಗೆದುಹಾಕುವ ಮೊದಲು, ಅದರ ಮೇಲೆ ಯಾವುದೇ ಸ್ಲಾಟ್‌ಗಳು ಇರಬಾರದು. ಕ್ಲಸ್ಟರ್ ರಿಶಾರ್ಡ್ ಆಜ್ಞೆಯನ್ನು ಬಳಸಿಕೊಂಡು ಅವುಗಳನ್ನು ಮರುಹಂಚಿಕೆ ಮಾಡುವುದು ಉತ್ತಮ. ಸ್ಲಾಟ್‌ಗಳನ್ನು ಒಬ್ಬ ಮಾಸ್ಟರ್‌ನಿಂದ ಇನ್ನೊಂದಕ್ಕೆ ವರ್ಗಾಯಿಸಲಾಗುತ್ತದೆ. ಸಂಪೂರ್ಣ ಕಾರ್ಯಾಚರಣೆಯು ಹಲವಾರು ನಿಮಿಷಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಬಹುದು, ಇದು ವರ್ಗಾವಣೆಯಾಗುವ ಡೇಟಾದ ಪರಿಮಾಣವನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ, ಆದರೆ ವರ್ಗಾವಣೆ ಪ್ರಕ್ರಿಯೆಯು ಸುರಕ್ಷಿತವಾಗಿದೆ ಮತ್ತು ಕ್ಲಸ್ಟರ್ನ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಯಾವುದೇ ರೀತಿಯಲ್ಲಿ ಪರಿಣಾಮ ಬೀರುವುದಿಲ್ಲ. ಹೀಗಾಗಿ, ಎಲ್ಲಾ ಡೇಟಾವನ್ನು ಒಂದು ನೋಡ್‌ನಿಂದ ಇನ್ನೊಂದಕ್ಕೆ ನೇರವಾಗಿ ಲೋಡ್‌ನಲ್ಲಿ ವರ್ಗಾಯಿಸಬಹುದು ಮತ್ತು ಅದರ ಲಭ್ಯತೆಯ ಬಗ್ಗೆ ಚಿಂತಿಸದೆ. ಆದಾಗ್ಯೂ, ಸೂಕ್ಷ್ಮತೆಗಳೂ ಇವೆ. ಮೊದಲನೆಯದಾಗಿ, ಡೇಟಾ ವರ್ಗಾವಣೆಯು ಸ್ವೀಕರಿಸುವವರ ಮತ್ತು ಕಳುಹಿಸುವವರ ನೋಡ್‌ಗಳ ಮೇಲೆ ಒಂದು ನಿರ್ದಿಷ್ಟ ಲೋಡ್‌ನೊಂದಿಗೆ ಸಂಬಂಧಿಸಿದೆ. ಸ್ವೀಕರಿಸುವವರ ನೋಡ್ ಈಗಾಗಲೇ ಪ್ರೊಸೆಸರ್‌ನಲ್ಲಿ ಹೆಚ್ಚು ಲೋಡ್ ಆಗಿದ್ದರೆ, ಹೊಸ ಡೇಟಾವನ್ನು ಸ್ವೀಕರಿಸುವುದರೊಂದಿಗೆ ನೀವು ಅದನ್ನು ಲೋಡ್ ಮಾಡಬಾರದು. ಎರಡನೆಯದಾಗಿ, ಕಳುಹಿಸುವ ಮಾಸ್ಟರ್‌ನಲ್ಲಿ ಒಂದೇ ಒಂದು ಸ್ಲಾಟ್ ಉಳಿದಿಲ್ಲದ ತಕ್ಷಣ, ಅದರ ಎಲ್ಲಾ ಗುಲಾಮರು ತಕ್ಷಣವೇ ಈ ಸ್ಲಾಟ್‌ಗಳನ್ನು ವರ್ಗಾಯಿಸಿದ ಮಾಸ್ಟರ್‌ಗೆ ಹೋಗುತ್ತಾರೆ. ಮತ್ತು ಸಮಸ್ಯೆಯೆಂದರೆ ಈ ಎಲ್ಲಾ ಗುಲಾಮರು ಡೇಟಾವನ್ನು ಏಕಕಾಲದಲ್ಲಿ ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡಲು ಬಯಸುತ್ತಾರೆ. ಮತ್ತು ಸಂಪೂರ್ಣ ಸಿಂಕ್ರೊನೈಸೇಶನ್ ಬದಲಿಗೆ ಭಾಗಶಃ ಆಗಿದ್ದರೆ ನೀವು ಅದೃಷ್ಟಶಾಲಿಯಾಗುತ್ತೀರಿ. ಇದನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳಿ ಮತ್ತು ಸ್ಲಾಟ್‌ಗಳನ್ನು ವರ್ಗಾಯಿಸುವ ಮತ್ತು ಗುಲಾಮರನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುವ/ವರ್ಗಾವಣೆ ಮಾಡುವ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಸಂಯೋಜಿಸಿ. ಅಥವಾ ನೀವು ಸುರಕ್ಷತೆಯ ಸಾಕಷ್ಟು ಅಂಚು ಹೊಂದಿರುವಿರಿ ಎಂದು ಭಾವಿಸುತ್ತೇವೆ.
  • ವರ್ಗಾವಣೆಯ ಸಮಯದಲ್ಲಿ, ನೀವು ಎಲ್ಲೋ ನಿಮ್ಮ ಸ್ಲಾಟ್‌ಗಳನ್ನು ಕಳೆದುಕೊಂಡಿದ್ದೀರಿ ಎಂದು ನೀವು ಕಂಡುಕೊಂಡರೆ ನೀವು ಏನು ಮಾಡಬೇಕು? ಈ ಸಮಸ್ಯೆಯು ನಿಮ್ಮ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುವುದಿಲ್ಲ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ, ಆದರೆ ಅದು ಇದ್ದರೆ, ಕ್ಲಸ್ಟರ್ ಫಿಕ್ಸ್ ಕಾರ್ಯಾಚರಣೆ ಇದೆ. ಕನಿಷ್ಠ, ಅವಳು ಯಾದೃಚ್ಛಿಕ ಕ್ರಮದಲ್ಲಿ ನೋಡ್‌ಗಳಾದ್ಯಂತ ಸ್ಲಾಟ್‌ಗಳನ್ನು ಚದುರಿಸುತ್ತಾಳೆ. ಕ್ಲಸ್ಟರ್‌ನಿಂದ ವಿತರಿಸಿದ ಸ್ಲಾಟ್‌ಗಳೊಂದಿಗೆ ನೋಡ್ ಅನ್ನು ಮೊದಲು ತೆಗೆದುಹಾಕುವ ಮೂಲಕ ಅದರ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಪರಿಶೀಲಿಸಲು ನಾನು ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ. ಹಂಚಿಕೆಯಾಗದ ಸ್ಲಾಟ್‌ಗಳಲ್ಲಿನ ಡೇಟಾ ಈಗಾಗಲೇ ಲಭ್ಯವಿಲ್ಲದ ಕಾರಣ, ಈ ಸ್ಲಾಟ್‌ಗಳ ಲಭ್ಯತೆಯ ಸಮಸ್ಯೆಗಳ ಬಗ್ಗೆ ಚಿಂತಿಸುವುದು ತುಂಬಾ ತಡವಾಗಿದೆ. ಪ್ರತಿಯಾಗಿ, ಕಾರ್ಯಾಚರಣೆಯು ವಿತರಿಸಿದ ಸ್ಲಾಟ್‌ಗಳ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುವುದಿಲ್ಲ.
  • ಮತ್ತೊಂದು ಉಪಯುಕ್ತ ಕಾರ್ಯಾಚರಣೆ ಮಾನಿಟರ್. ನೋಡ್‌ಗೆ ಹೋಗುವ ವಿನಂತಿಗಳ ಸಂಪೂರ್ಣ ಪಟ್ಟಿಯನ್ನು ನೈಜ ಸಮಯದಲ್ಲಿ ನೋಡಲು ಇದು ನಿಮ್ಮನ್ನು ಅನುಮತಿಸುತ್ತದೆ. ಇದಲ್ಲದೆ, ನೀವು ಅದನ್ನು ಗ್ರೆಪ್ ಮಾಡಬಹುದು ಮತ್ತು ಅಗತ್ಯ ದಟ್ಟಣೆ ಇದೆಯೇ ಎಂದು ಕಂಡುಹಿಡಿಯಬಹುದು.

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

ಸಂರಚನೆ

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

  • ಕಾಲಾವಧಿ 0
    ನಿಷ್ಕ್ರಿಯ ಸಂಪರ್ಕಗಳನ್ನು ಮುಚ್ಚಿದ ಸಮಯ (ಸೆಕೆಂಡುಗಳಲ್ಲಿ). 0 - ಮುಚ್ಚಬೇಡಿ
    ನಮ್ಮ ಪ್ರತಿಯೊಂದು ಗ್ರಂಥಾಲಯವು ಸಂಪರ್ಕಗಳನ್ನು ಸರಿಯಾಗಿ ಮುಚ್ಚಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ. ಈ ಸೆಟ್ಟಿಂಗ್ ಅನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುವುದರಿಂದ, ನಾವು ಕ್ಲೈಂಟ್‌ಗಳ ಸಂಖ್ಯೆಯ ಮಿತಿಯನ್ನು ಹೊಡೆಯುವ ಅಪಾಯವಿದೆ. ಮತ್ತೊಂದೆಡೆ, ಅಂತಹ ಸಮಸ್ಯೆ ಇದ್ದರೆ, ಕಳೆದುಹೋದ ಸಂಪರ್ಕಗಳ ಸ್ವಯಂಚಾಲಿತ ಮುಕ್ತಾಯವು ಅದನ್ನು ಮರೆಮಾಚುತ್ತದೆ ಮತ್ತು ನಾವು ಗಮನಿಸದೇ ಇರಬಹುದು. ಹೆಚ್ಚುವರಿಯಾಗಿ, ನಿರಂತರ ಸಂಪರ್ಕಗಳನ್ನು ಬಳಸುವಾಗ ನೀವು ಈ ಸೆಟ್ಟಿಂಗ್ ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಬಾರದು.
  • xy ಅನ್ನು ಉಳಿಸಿ & ಅನುಬಂಧವಾಗಿ ಮಾತ್ರ ಹೌದು
    RDB ಸ್ನ್ಯಾಪ್‌ಶಾಟ್ ಅನ್ನು ಉಳಿಸಲಾಗುತ್ತಿದೆ.
    ನಾವು RDB/AOF ಸಮಸ್ಯೆಗಳನ್ನು ಕೆಳಗೆ ವಿವರವಾಗಿ ಚರ್ಚಿಸುತ್ತೇವೆ.
  • ಸ್ಟಾಪ್-ರೈಟ್ಸ್-ಆನ್-ಬಿಜಿಸೇವ್-ಎರರ್ ಇಲ್ಲ & ಸ್ಲೇವ್-ಸರ್ವ್-ಸ್ಟೇಲ್-ಡೇಟಾ ಹೌದು
    ಸಕ್ರಿಯಗೊಳಿಸಿದರೆ, RDB ಸ್ನ್ಯಾಪ್‌ಶಾಟ್ ಮುರಿದರೆ, ಬದಲಾವಣೆ ವಿನಂತಿಗಳನ್ನು ಸ್ವೀಕರಿಸುವುದನ್ನು ಮಾಸ್ಟರ್ ನಿಲ್ಲಿಸುತ್ತಾರೆ. ಯಜಮಾನನೊಂದಿಗಿನ ಸಂಪರ್ಕವು ಕಳೆದುಹೋದರೆ, ಗುಲಾಮನು ವಿನಂತಿಗಳಿಗೆ ಪ್ರತಿಕ್ರಿಯಿಸುವುದನ್ನು ಮುಂದುವರಿಸಬಹುದು (ಹೌದು). ಅಥವಾ ಪ್ರತಿಕ್ರಿಯಿಸುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ (ಇಲ್ಲ)
    ರೆಡಿಸ್ ಕುಂಬಳಕಾಯಿಯಾಗಿ ಬದಲಾಗುವ ಪರಿಸ್ಥಿತಿಯಿಂದ ನಮಗೆ ಸಂತೋಷವಿಲ್ಲ.
  • ರೆಪ್ಲ್-ಪಿಂಗ್-ಸ್ಲೇವ್-ಅವಧಿ 5
    ಈ ಅವಧಿಯ ನಂತರ, ಮಾಸ್ಟರ್ ಮುರಿದುಹೋಗಿದೆ ಎಂದು ನಾವು ಚಿಂತೆ ಮಾಡಲು ಪ್ರಾರಂಭಿಸುತ್ತೇವೆ ಮತ್ತು ವೈಫಲ್ಯದ ಕಾರ್ಯವಿಧಾನವನ್ನು ಕೈಗೊಳ್ಳುವ ಸಮಯ ಇದು.
    ತಪ್ಪು ಧನಾತ್ಮಕ ಮತ್ತು ವೈಫಲ್ಯವನ್ನು ಪ್ರಚೋದಿಸುವ ನಡುವಿನ ಸಮತೋಲನವನ್ನು ನೀವು ಹಸ್ತಚಾಲಿತವಾಗಿ ಕಂಡುಹಿಡಿಯಬೇಕು. ನಮ್ಮ ಅಭ್ಯಾಸದಲ್ಲಿ ಇದು 5 ಸೆಕೆಂಡುಗಳು.
  • repl-backlog-size 1024mb & epl-backlog-ttl 0
    ವಿಫಲವಾದ ಪ್ರತಿಕೃತಿಗಾಗಿ ನಾವು ಬಫರ್‌ನಲ್ಲಿ ನಿಖರವಾಗಿ ಇಷ್ಟು ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸಬಹುದು. ಬಫರ್ ಖಾಲಿಯಾದರೆ, ನೀವು ಸಂಪೂರ್ಣವಾಗಿ ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡಬೇಕಾಗುತ್ತದೆ.
    ಹೆಚ್ಚಿನ ಮೌಲ್ಯವನ್ನು ಹೊಂದಿಸುವುದು ಉತ್ತಮ ಎಂದು ಅಭ್ಯಾಸವು ಸೂಚಿಸುತ್ತದೆ. ಪ್ರತಿಕೃತಿಯು ವಿಳಂಬವಾಗಲು ಸಾಕಷ್ಟು ಕಾರಣಗಳಿವೆ. ಅದು ಮಂದಗತಿಯಲ್ಲಿದ್ದರೆ, ನಿಮ್ಮ ಮಾಸ್ಟರ್ ಈಗಾಗಲೇ ನಿಭಾಯಿಸಲು ಹೆಣಗಾಡುತ್ತಿದ್ದಾರೆ ಮತ್ತು ಪೂರ್ಣ ಸಿಂಕ್ರೊನೈಸೇಶನ್ ಕೊನೆಯ ಒಣಹುಲ್ಲಿನಾಗಿರುತ್ತದೆ.
  • ಗರಿಷ್ಠ ಗ್ರಾಹಕರು 10000
    ಒಂದು-ಬಾರಿ ಕ್ಲೈಂಟ್‌ಗಳ ಗರಿಷ್ಠ ಸಂಖ್ಯೆ.
    ನಮ್ಮ ಅನುಭವದಲ್ಲಿ, ಹೆಚ್ಚಿನ ಮೌಲ್ಯವನ್ನು ಹೊಂದಿಸುವುದು ಉತ್ತಮ. ರೆಡಿಸ್ 10k ಸಂಪರ್ಕಗಳನ್ನು ಉತ್ತಮವಾಗಿ ನಿರ್ವಹಿಸುತ್ತದೆ. ಸಿಸ್ಟಂನಲ್ಲಿ ಸಾಕಷ್ಟು ಸಾಕೆಟ್‌ಗಳಿವೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ.
  • maxmemory-policy volatile-ttl
    ಲಭ್ಯವಿರುವ ಮೆಮೊರಿ ಮಿತಿಯನ್ನು ತಲುಪಿದಾಗ ಕೀಗಳನ್ನು ಅಳಿಸುವ ನಿಯಮ.
    ಇಲ್ಲಿ ಮುಖ್ಯವಾದುದು ನಿಯಮವಲ್ಲ, ಆದರೆ ಇದು ಹೇಗೆ ಸಂಭವಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು. ಮೆಮೊರಿ ಮಿತಿಯನ್ನು ತಲುಪಿದಾಗ ಸಾಮಾನ್ಯವಾಗಿ ಕೆಲಸ ಮಾಡುವ ಸಾಮರ್ಥ್ಯಕ್ಕಾಗಿ ರೆಡಿಸ್ ಅನ್ನು ಪ್ರಶಂಸಿಸಬಹುದು.

RDB ಮತ್ತು AOF ಸಮಸ್ಯೆಗಳು

Redis ಸ್ವತಃ RAM ನಲ್ಲಿ ಎಲ್ಲಾ ಮಾಹಿತಿಯನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆಯಾದರೂ, ಡಿಸ್ಕ್ಗೆ ಡೇಟಾವನ್ನು ಉಳಿಸುವ ಕಾರ್ಯವಿಧಾನವೂ ಇದೆ. ಹೆಚ್ಚು ನಿಖರವಾಗಿ, ಮೂರು ಕಾರ್ಯವಿಧಾನಗಳು:

  • RDB-ಸ್ನ್ಯಾಪ್‌ಶಾಟ್ - ಎಲ್ಲಾ ಡೇಟಾದ ಸಂಪೂರ್ಣ ಸ್ನ್ಯಾಪ್‌ಶಾಟ್. SAVE XY ಕಾನ್ಫಿಗರೇಶನ್ ಬಳಸಿ ಹೊಂದಿಸಿ ಮತ್ತು "ಕನಿಷ್ಠ Y ಕೀಗಳು ಬದಲಾಗಿದ್ದರೆ ಪ್ರತಿ X ಸೆಕೆಂಡಿಗೆ ಎಲ್ಲಾ ಡೇಟಾದ ಪೂರ್ಣ ಸ್ನ್ಯಾಪ್‌ಶಾಟ್ ಅನ್ನು ಉಳಿಸಿ" ಎಂದು ಓದುತ್ತದೆ.
  • ಅನುಬಂಧ-ಮಾತ್ರ ಫೈಲ್ - ಅವುಗಳನ್ನು ನಿರ್ವಹಿಸಿದ ಕ್ರಮದಲ್ಲಿ ಕಾರ್ಯಾಚರಣೆಗಳ ಪಟ್ಟಿ. ಪ್ರತಿ X ಸೆಕೆಂಡುಗಳು ಅಥವಾ ಪ್ರತಿ Y ಕಾರ್ಯಾಚರಣೆಗಳಿಗೆ ಹೊಸ ಒಳಬರುವ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಸೇರಿಸುತ್ತದೆ.
  • RDB ಮತ್ತು AOF ಹಿಂದಿನ ಎರಡು ಸಂಯೋಜನೆಯಾಗಿದೆ.

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

ಮೊದಲಿಗೆ, RDB ಸ್ನ್ಯಾಪ್‌ಶಾಟ್ ಅನ್ನು ಉಳಿಸಲು FORK ಗೆ ಕರೆ ಮಾಡುವ ಅಗತ್ಯವಿದೆ. ಸಾಕಷ್ಟು ಡೇಟಾ ಇದ್ದರೆ, ಇದು ಎಲ್ಲಾ ರೆಡಿಸ್ ಅನ್ನು ಕೆಲವು ಮಿಲಿಸೆಕೆಂಡ್‌ಗಳಿಂದ ಸೆಕೆಂಡ್‌ವರೆಗೆ ಸ್ಥಗಿತಗೊಳಿಸಬಹುದು. ಹೆಚ್ಚುವರಿಯಾಗಿ, ಅಂತಹ ಸ್ನ್ಯಾಪ್‌ಶಾಟ್‌ಗಾಗಿ ಸಿಸ್ಟಮ್ ಮೆಮೊರಿಯನ್ನು ನಿಯೋಜಿಸಬೇಕಾಗಿದೆ, ಇದು ತಾರ್ಕಿಕ ಯಂತ್ರದಲ್ಲಿ RAM ನ ಎರಡು ಪೂರೈಕೆಯನ್ನು ಇರಿಸಿಕೊಳ್ಳುವ ಅಗತ್ಯಕ್ಕೆ ಕಾರಣವಾಗುತ್ತದೆ: ರೆಡಿಸ್‌ಗಾಗಿ 8 GB ಅನ್ನು ನಿಗದಿಪಡಿಸಿದರೆ, ನಂತರ 16 GB ವರ್ಚುವಲ್ ಗಣಕದಲ್ಲಿ ಲಭ್ಯವಿರಬೇಕು ಇದು.

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

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

ತೀರ್ಮಾನಕ್ಕೆ

ಕೊನೆಯಲ್ಲಿ, ರೆಡಿಸ್-ಕ್ಲಸ್ಟರ್ ಅದರ ಬಗ್ಗೆ ಕೇಳದವರಿಗೆ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದರ ಕುರಿತು ಸಾಮಾನ್ಯ ಕಲ್ಪನೆಯನ್ನು ನೀಡಲು ನನಗೆ ಸಾಧ್ಯವಾಯಿತು ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ ಮತ್ತು ಅದನ್ನು ಬಳಸುತ್ತಿರುವವರಿಗೆ ಕೆಲವು ಸ್ಪಷ್ಟವಲ್ಲದ ಅಂಶಗಳತ್ತ ಗಮನ ಸೆಳೆದಿದ್ದೇನೆ. ದೀರ್ಘಕಾಲದವರೆಗೆ.
ನಿಮ್ಮ ಸಮಯಕ್ಕೆ ಧನ್ಯವಾದಗಳು ಮತ್ತು ಯಾವಾಗಲೂ, ವಿಷಯದ ಕುರಿತು ಕಾಮೆಂಟ್‌ಗಳಿಗೆ ಸ್ವಾಗತ.

ಮೂಲ: www.habr.com

ಕಾಮೆಂಟ್ ಅನ್ನು ಸೇರಿಸಿ