🥇ಫೇಲ್ಓವರ್ ಕ್ಲಸ್ಟರ್ PostgreSQL + Patroni. ಅನುಷ್ಠಾನದ ಅನುಭವ

PostgreSQL ದೋಷ ಸಹಿಷ್ಣುತೆಯ ಸಮಸ್ಯೆಯನ್ನು ನಾವು ಹೇಗೆ ಸಂಪರ್ಕಿಸಿದ್ದೇವೆ, ಅದು ನಮಗೆ ಏಕೆ ಮುಖ್ಯವಾಯಿತು ಮತ್ತು ಕೊನೆಯಲ್ಲಿ ಏನಾಯಿತು ಎಂದು ಈ ಲೇಖನದಲ್ಲಿ ನಾನು ನಿಮಗೆ ಹೇಳುತ್ತೇನೆ.

ನಾವು ಹೆಚ್ಚು ಲೋಡ್ ಮಾಡಲಾದ ಸೇವೆಯನ್ನು ಹೊಂದಿದ್ದೇವೆ: ವಿಶ್ವಾದ್ಯಂತ 2,5 ಮಿಲಿಯನ್ ಬಳಕೆದಾರರು, ಪ್ರತಿದಿನ 50K+ ಸಕ್ರಿಯ ಬಳಕೆದಾರರು. ಸರ್ವರ್‌ಗಳು ಐರ್ಲೆಂಡ್‌ನ ಒಂದು ಪ್ರದೇಶದಲ್ಲಿ ಅಮೆಜಾನ್‌ನಲ್ಲಿವೆ: 100+ ವಿಭಿನ್ನ ಸರ್ವರ್‌ಗಳು ನಿರಂತರವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿವೆ, ಅವುಗಳಲ್ಲಿ ಸುಮಾರು 50 ಡೇಟಾಬೇಸ್‌ಗಳೊಂದಿಗೆ.

ಸಂಪೂರ್ಣ ಬ್ಯಾಕೆಂಡ್ ಕ್ಲೈಂಟ್‌ನೊಂದಿಗೆ ನಿರಂತರ ವೆಬ್‌ಸಾಕೆಟ್ ಸಂಪರ್ಕವನ್ನು ನಿರ್ವಹಿಸುವ ದೊಡ್ಡ ಏಕಶಿಲೆಯ ಸ್ಥಿತಿಯ ಜಾವಾ ಅಪ್ಲಿಕೇಶನ್ ಆಗಿದೆ. ಹಲವಾರು ಬಳಕೆದಾರರು ಒಂದೇ ಬೋರ್ಡ್‌ನಲ್ಲಿ ಏಕಕಾಲದಲ್ಲಿ ಕೆಲಸ ಮಾಡಿದಾಗ, ಅವರೆಲ್ಲರೂ ನೈಜ ಸಮಯದಲ್ಲಿ ಬದಲಾವಣೆಗಳನ್ನು ನೋಡುತ್ತಾರೆ, ಏಕೆಂದರೆ ನಾವು ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಪ್ರತಿ ಬದಲಾವಣೆಯನ್ನು ದಾಖಲಿಸುತ್ತೇವೆ. ನಾವು ನಮ್ಮ ಡೇಟಾಬೇಸ್‌ಗಳಿಗೆ ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಸರಿಸುಮಾರು 10K ವಿನಂತಿಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ. ರೆಡಿಸ್‌ನಲ್ಲಿ ಗರಿಷ್ಠ ಲೋಡ್‌ನಲ್ಲಿ ನಾವು ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 80-100K ವಿನಂತಿಗಳನ್ನು ಬರೆಯುತ್ತೇವೆ.

ನಾವು Redis ನಿಂದ PostgreSQL ಗೆ ಏಕೆ ಬದಲಾಯಿಸಿದ್ದೇವೆ

ಆರಂಭದಲ್ಲಿ, ನಮ್ಮ ಸೇವೆಯು ಸರ್ವರ್‌ನ RAM ನಲ್ಲಿ ಎಲ್ಲಾ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸುವ ಪ್ರಮುಖ-ಮೌಲ್ಯದ ಸಂಗ್ರಹಣೆಯಾದ Redis ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಿದೆ.

ರೆಡಿಸ್‌ನ ಸಾಧಕ:

ಹೆಚ್ಚಿನ ಪ್ರತಿಕ್ರಿಯೆ ವೇಗ, ಏಕೆಂದರೆ ಎಲ್ಲವನ್ನೂ ಮೆಮೊರಿಯಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗಿದೆ;
ಅನುಕೂಲಕರ ಬ್ಯಾಕಪ್ ಮತ್ತು ಪ್ರತಿಕೃತಿ.

ನಮಗೆ ರೆಡಿಸ್‌ನ ಅನಾನುಕೂಲಗಳು:

ಯಾವುದೇ ನೈಜ ವಹಿವಾಟುಗಳಿಲ್ಲ. ನಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಮಟ್ಟದಲ್ಲಿ ನಾವು ಅವರನ್ನು ಅನುಕರಿಸಲು ಪ್ರಯತ್ನಿಸಿದ್ದೇವೆ. ದುರದೃಷ್ಟವಶಾತ್, ಇದು ಯಾವಾಗಲೂ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ ಮತ್ತು ಬಹಳ ಸಂಕೀರ್ಣವಾದ ಕೋಡ್ ಬರೆಯುವ ಅಗತ್ಯವಿದೆ.
ಡೇಟಾದ ಪ್ರಮಾಣವು ಮೆಮೊರಿಯ ಪ್ರಮಾಣದಿಂದ ಸೀಮಿತವಾಗಿದೆ. ಡೇಟಾದ ಪ್ರಮಾಣವು ಹೆಚ್ಚಾದಂತೆ, ಮೆಮೊರಿಯು ಬೆಳೆಯುತ್ತದೆ ಮತ್ತು ಕೊನೆಯಲ್ಲಿ, ನಾವು ಆಯ್ದ ನಿದರ್ಶನದ ಗುಣಲಕ್ಷಣಗಳಿಗೆ ಓಡುತ್ತೇವೆ, ಇದು AWS ನಲ್ಲಿ ನಿದರ್ಶನ ಪ್ರಕಾರವನ್ನು ಬದಲಾಯಿಸಲು ನಮ್ಮ ಸೇವೆಯನ್ನು ನಿಲ್ಲಿಸುವ ಅಗತ್ಯವಿದೆ.
ಕಡಿಮೆ ಸುಪ್ತ ಮಟ್ಟವನ್ನು ನಿರಂತರವಾಗಿ ನಿರ್ವಹಿಸುವುದು ಅವಶ್ಯಕ, ಏಕೆಂದರೆ ನಾವು ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ವಿನಂತಿಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ. ನಮಗೆ ಸೂಕ್ತವಾದ ಲೇಟೆನ್ಸಿ ಮಟ್ಟವು 17-20 ms ಆಗಿದೆ. 30-40 ms ಮಟ್ಟದಲ್ಲಿ, ನಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ವಿನಂತಿಗಳು ಮತ್ತು ಸೇವೆಯ ಅವನತಿಗೆ ನಾವು ದೀರ್ಘ ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ಪಡೆಯುತ್ತೇವೆ. ದುರದೃಷ್ಟವಶಾತ್, ಇದು ಸೆಪ್ಟೆಂಬರ್ 2018 ರಲ್ಲಿ ನಮಗೆ ಸಂಭವಿಸಿತು, ಕೆಲವು ಕಾರಣಗಳಿಗಾಗಿ ರೆಡಿಸ್‌ನೊಂದಿಗಿನ ಒಂದು ನಿದರ್ಶನವು ಸಾಮಾನ್ಯಕ್ಕಿಂತ 2 ಪಟ್ಟು ಹೆಚ್ಚಿನ ಸುಪ್ತತೆಯನ್ನು ಪಡೆದಾಗ. ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು, ನಾವು ನಿಗದಿತ ನಿರ್ವಹಣೆಗಾಗಿ ಕೆಲಸದ ದಿನದ ಮಧ್ಯದಲ್ಲಿ ಸೇವೆಯನ್ನು ನಿಲ್ಲಿಸಿದ್ದೇವೆ ಮತ್ತು ಸಮಸ್ಯಾತ್ಮಕ ರೆಡಿಸ್ ನಿದರ್ಶನವನ್ನು ಬದಲಾಯಿಸಿದ್ದೇವೆ.
ಕೋಡ್‌ನಲ್ಲಿ ಸಣ್ಣ ದೋಷಗಳಿದ್ದರೂ ಸಹ ಅಸಮಂಜಸವಾದ ಡೇಟಾವನ್ನು ಪಡೆಯುವುದು ಸುಲಭ ಮತ್ತು ಆ ಡೇಟಾವನ್ನು ಸರಿಪಡಿಸಲು ಕೋಡ್ ಬರೆಯಲು ಸಾಕಷ್ಟು ಸಮಯವನ್ನು ಕಳೆಯುತ್ತದೆ.

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

ನಾವು ಈಗ 1,5 ವರ್ಷಗಳಿಂದ ಹೊಸ ಡೇಟಾಬೇಸ್‌ಗೆ ಹೋಗುತ್ತಿದ್ದೇವೆ ಮತ್ತು ಡೇಟಾದ ಒಂದು ಸಣ್ಣ ಭಾಗವನ್ನು ಮಾತ್ರ ವರ್ಗಾಯಿಸಿದ್ದೇವೆ, ಆದ್ದರಿಂದ ಈಗ ನಾವು Redis ಮತ್ತು PostgreSQL ನೊಂದಿಗೆ ಏಕಕಾಲದಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದ್ದೇವೆ. ಡೇಟಾಬೇಸ್‌ಗಳ ನಡುವೆ ಡೇಟಾವನ್ನು ಚಲಿಸುವ ಮತ್ತು ಬದಲಾಯಿಸುವ ಹಂತಗಳ ಕುರಿತು ಹೆಚ್ಚಿನ ಮಾಹಿತಿಯನ್ನು ಬರೆಯಲಾಗಿದೆ ನನ್ನ ಸಹೋದ್ಯೋಗಿಯಿಂದ ಲೇಖನ.

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

PgBouncer ಅನ್ನು ಅಳವಡಿಸಲಾಗುತ್ತಿದೆ

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

ಸಂಪರ್ಕ ನಿರ್ವಾಹಕಕ್ಕಾಗಿ ನಾವು ಎರಡು ಆಯ್ಕೆಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ: Pgpool ಮತ್ತು PgBouncer. ಆದರೆ ಮೊದಲನೆಯದು ಡೇಟಾಬೇಸ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವ ವಹಿವಾಟಿನ ಮೋಡ್ ಅನ್ನು ಬೆಂಬಲಿಸುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ನಾವು PgBouncer ಅನ್ನು ಆರಿಸಿದ್ದೇವೆ.

ನಾವು ಈ ಕೆಳಗಿನ ಕೆಲಸದ ಯೋಜನೆಯನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಿದ್ದೇವೆ: ನಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಒಂದು PgBouncer ಅನ್ನು ಪ್ರವೇಶಿಸುತ್ತದೆ, ಅದರ ಹಿಂದೆ PostgreSQL ಮಾಸ್ಟರ್‌ಗಳು ಇರುತ್ತಾರೆ ಮತ್ತು ಪ್ರತಿ ಮಾಸ್ಟರ್‌ನ ಹಿಂದೆ ಅಸಮಕಾಲಿಕ ಪ್ರತಿಕೃತಿಯೊಂದಿಗೆ ಒಂದು ಪ್ರತಿಕೃತಿ ಇರುತ್ತದೆ.

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

PgBouncer ತಪ್ಪು ಸಹಿಷ್ಣುತೆ

PgBouncer ನಿದರ್ಶನವು ಸಾಯುವವರೆಗೂ ಈ ಯೋಜನೆಯು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ನಾವು AWS ನಲ್ಲಿದ್ದೇವೆ, ಅಲ್ಲಿ ಎಲ್ಲಾ ನಿದರ್ಶನಗಳು ನಿಯತಕಾಲಿಕವಾಗಿ ಸಾಯುವ ಹಾರ್ಡ್‌ವೇರ್‌ನಲ್ಲಿ ಪ್ರಾರಂಭಿಸಲ್ಪಡುತ್ತವೆ. ಅಂತಹ ಸಂದರ್ಭಗಳಲ್ಲಿ, ನಿದರ್ಶನವು ಹೊಸ ಯಂತ್ರಾಂಶಕ್ಕೆ ಚಲಿಸುತ್ತದೆ ಮತ್ತು ಮತ್ತೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಇದು PgBouncer ನೊಂದಿಗೆ ಸಂಭವಿಸಿತು, ಆದರೆ ಅದು ಅಲಭ್ಯವಾಯಿತು. ಈ ಕುಸಿತದ ಫಲಿತಾಂಶವೆಂದರೆ ನಮ್ಮ ಸೇವೆಯು 25 ನಿಮಿಷಗಳವರೆಗೆ ಲಭ್ಯವಿಲ್ಲ. ಅಂತಹ ಸಂದರ್ಭಗಳಲ್ಲಿ, ಆ ಸಮಯದಲ್ಲಿ ನಾವು ಕಾರ್ಯಗತಗೊಳಿಸದ ಬಳಕೆದಾರರ ಬದಿಯಲ್ಲಿ ಪುನರಾವರ್ತನೆಯನ್ನು ಬಳಸಲು AWS ಶಿಫಾರಸು ಮಾಡುತ್ತದೆ.

ಅದರ ನಂತರ, PgBouncer ಮತ್ತು PostgreSQL ಕ್ಲಸ್ಟರ್‌ಗಳ ದೋಷ ಸಹಿಷ್ಣುತೆಯ ಬಗ್ಗೆ ನಾವು ಗಂಭೀರವಾಗಿ ಯೋಚಿಸಿದ್ದೇವೆ, ಏಕೆಂದರೆ ನಮ್ಮ AWS ಖಾತೆಯಲ್ಲಿ ಯಾವುದೇ ಉದಾಹರಣೆಯೊಂದಿಗೆ ಇದೇ ರೀತಿಯ ಪರಿಸ್ಥಿತಿಯು ಮತ್ತೆ ಸಂಭವಿಸಬಹುದು.

ನಾವು PgBouncer ದೋಷ ಸಹಿಷ್ಣುತೆಯ ಯೋಜನೆಯನ್ನು ಈ ಕೆಳಗಿನಂತೆ ನಿರ್ಮಿಸಿದ್ದೇವೆ: ಎಲ್ಲಾ ಅಪ್ಲಿಕೇಶನ್ ಸರ್ವರ್‌ಗಳು ನೆಟ್‌ವರ್ಕ್ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ ಅನ್ನು ಪ್ರವೇಶಿಸುತ್ತವೆ, ಅದರ ಹಿಂದೆ ಎರಡು PgBouncers ಇವೆ. ಪ್ರತಿಯೊಂದು PgBouncers ಪ್ರತಿ ಚೂರುಗಳ ಅದೇ ಮಾಸ್ಟರ್ PostgreSQL ಅನ್ನು ನೋಡುತ್ತಾರೆ. AWS ನಿದರ್ಶನದ ಕ್ರ್ಯಾಶ್‌ನೊಂದಿಗಿನ ಪರಿಸ್ಥಿತಿಯು ಪುನರಾವರ್ತನೆಯಾದರೆ, ಎಲ್ಲಾ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಮತ್ತೊಂದು PgBouncer ಮೂಲಕ ಮರುನಿರ್ದೇಶಿಸಲಾಗುತ್ತದೆ. ನೆಟ್‌ವರ್ಕ್ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ ದೋಷ ಸಹಿಷ್ಣುತೆಯನ್ನು AWS ಒದಗಿಸಿದೆ.

ಈ ಯೋಜನೆಯು ಹೊಸ PgBouncer ಸರ್ವರ್‌ಗಳನ್ನು ಸುಲಭವಾಗಿ ಸೇರಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ.

PostgreSQL Failover ಕ್ಲಸ್ಟರ್ ಅನ್ನು ರಚಿಸಲಾಗುತ್ತಿದೆ

ಈ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುವಾಗ, ನಾವು ವಿಭಿನ್ನ ಆಯ್ಕೆಗಳನ್ನು ಪರಿಗಣಿಸಿದ್ದೇವೆ: ಸ್ವಯಂ-ಲಿಖಿತ ವಿಫಲತೆ, repmgr, AWS RDS, Patroni.

ಸ್ವ-ಬರೆದ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳು

ಅವರು ಮಾಸ್ಟರ್‌ನ ಕೆಲಸವನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಬಹುದು ಮತ್ತು ಅದು ವಿಫಲವಾದರೆ, ಮಾಸ್ಟರ್‌ಗೆ ಪ್ರತಿಕೃತಿಯನ್ನು ಪ್ರಚಾರ ಮಾಡಿ ಮತ್ತು PgBouncer ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ನವೀಕರಿಸಬಹುದು.

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

ಕಾನ್ಸ್:

ಮಾಸ್ಟರ್ ಸಾಯದೇ ಇರಬಹುದು; ಬದಲಿಗೆ, ನೆಟ್‌ವರ್ಕ್ ವೈಫಲ್ಯವಿರಬಹುದು. ಫೇಲ್ಓವರ್, ಇದರ ಅರಿವಿಲ್ಲದೆ, ಮಾಸ್ಟರ್ಗೆ ಪ್ರತಿಕೃತಿಯನ್ನು ಉತ್ತೇಜಿಸುತ್ತದೆ ಮತ್ತು ಹಳೆಯ ಮಾಸ್ಟರ್ ಕೆಲಸ ಮಾಡುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತಾನೆ. ಪರಿಣಾಮವಾಗಿ, ನಾವು ಮಾಸ್ಟರ್ ಪಾತ್ರದಲ್ಲಿ ಎರಡು ಸರ್ವರ್‌ಗಳನ್ನು ಪಡೆಯುತ್ತೇವೆ ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಯಾವುದು ಇತ್ತೀಚಿನ ಪ್ರಸ್ತುತ ಡೇಟಾವನ್ನು ಹೊಂದಿದೆ ಎಂದು ತಿಳಿಯುವುದಿಲ್ಲ. ಈ ಪರಿಸ್ಥಿತಿಯನ್ನು ಸ್ಪ್ಲಿಟ್-ಮೆದುಳು ಎಂದೂ ಕರೆಯುತ್ತಾರೆ;
ನಾವು ಯಾವುದೇ ಪ್ರತಿಕ್ರಿಯೆ ನೀಡದೆ ಉಳಿದೆವು. ನಮ್ಮ ಕಾನ್ಫಿಗರೇಶನ್‌ನಲ್ಲಿ ಮಾಸ್ಟರ್ ಮತ್ತು ಒಂದು ಪ್ರತಿರೂಪವಿದೆ, ಪ್ರತಿಕೃತಿಯನ್ನು ಬದಲಾಯಿಸಿದ ನಂತರ ಮಾಸ್ಟರ್‌ಗೆ ಬಡ್ತಿ ನೀಡಲಾಗುತ್ತದೆ ಮತ್ತು ನಮ್ಮಲ್ಲಿ ಇನ್ನು ಮುಂದೆ ಪ್ರತಿಕೃತಿಗಳಿಲ್ಲ, ಆದ್ದರಿಂದ ನಾವು ಹೊಸ ಪ್ರತಿಕೃತಿಯನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ಸೇರಿಸಬೇಕು;
ನಮಗೆ ವೈಫಲ್ಯದ ಕಾರ್ಯಾಚರಣೆಯ ಹೆಚ್ಚುವರಿ ಮೇಲ್ವಿಚಾರಣೆಯ ಅಗತ್ಯವಿದೆ, ಮತ್ತು ನಾವು 12 PostgreSQL ಚೂರುಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಅಂದರೆ ನಾವು 12 ಕ್ಲಸ್ಟರ್‌ಗಳನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಬೇಕಾಗುತ್ತದೆ. ಚೂರುಗಳ ಸಂಖ್ಯೆಯನ್ನು ಹೆಚ್ಚಿಸುವಾಗ, ವಿಫಲತೆಯನ್ನು ನವೀಕರಿಸಲು ಸಹ ನೀವು ನೆನಪಿನಲ್ಲಿಟ್ಟುಕೊಳ್ಳಬೇಕು.

ಸ್ವಯಂ-ಲಿಖಿತ ವೈಫಲ್ಯವು ತುಂಬಾ ಜಟಿಲವಾಗಿದೆ ಮತ್ತು ಕ್ಷುಲ್ಲಕವಲ್ಲದ ಬೆಂಬಲದ ಅಗತ್ಯವಿದೆ. ಒಂದು PostgreSQL ಕ್ಲಸ್ಟರ್‌ನೊಂದಿಗೆ, ಇದು ಸರಳವಾದ ಆಯ್ಕೆಯಾಗಿದೆ, ಆದರೆ ಇದು ಅಳೆಯುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಇದು ನಮಗೆ ಸೂಕ್ತವಲ್ಲ.

Repmgr

PostgreSQL ಕ್ಲಸ್ಟರ್‌ಗಳಿಗಾಗಿ ರೆಪ್ಲಿಕೇಶನ್ ಮ್ಯಾನೇಜರ್, ಇದು PostgreSQL ಕ್ಲಸ್ಟರ್‌ನ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ನಿರ್ವಹಿಸಬಹುದು. ಅದೇ ಸಮಯದಲ್ಲಿ, ಇದು ಪೆಟ್ಟಿಗೆಯ ಹೊರಗೆ ಸ್ವಯಂಚಾಲಿತ ವಿಫಲತೆಯನ್ನು ಹೊಂದಿಲ್ಲ, ಆದ್ದರಿಂದ ಕೆಲಸ ಮಾಡಲು ನೀವು ಸಿದ್ಧ ಪರಿಹಾರದ ಮೇಲೆ ನಿಮ್ಮ ಸ್ವಂತ "ಹೊದಿಕೆ" ಅನ್ನು ಬರೆಯಬೇಕಾಗುತ್ತದೆ. ಆದ್ದರಿಂದ ಎಲ್ಲವೂ ಸ್ವಯಂ-ಲಿಖಿತ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳಿಗಿಂತ ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾಗಬಹುದು, ಅದಕ್ಕಾಗಿಯೇ ನಾವು Repmgr ಅನ್ನು ಪ್ರಯತ್ನಿಸಲಿಲ್ಲ.

AWS RDS

ಇದು ನಮಗೆ ಅಗತ್ಯವಿರುವ ಎಲ್ಲವನ್ನೂ ಬೆಂಬಲಿಸುತ್ತದೆ, ಬ್ಯಾಕ್‌ಅಪ್‌ಗಳನ್ನು ಮಾಡಬಹುದು ಮತ್ತು ಸಂಪರ್ಕಗಳ ಪೂಲ್ ಅನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ. ಇದು ಸ್ವಯಂಚಾಲಿತ ಸ್ವಿಚಿಂಗ್ ಅನ್ನು ಹೊಂದಿದೆ: ಮಾಸ್ಟರ್ ಸತ್ತಾಗ, ಪ್ರತಿಕೃತಿಯು ಹೊಸ ಮಾಸ್ಟರ್ ಆಗುತ್ತದೆ, ಮತ್ತು AWS DNS ದಾಖಲೆಯನ್ನು ಹೊಸ ಮಾಸ್ಟರ್‌ಗೆ ಬದಲಾಯಿಸುತ್ತದೆ, ಆದರೆ ಪ್ರತಿಕೃತಿಗಳನ್ನು ವಿವಿಧ AZ ಗಳಲ್ಲಿ ಇರಿಸಬಹುದು.

ಅನಾನುಕೂಲಗಳು ಉತ್ತಮ ಸೆಟ್ಟಿಂಗ್‌ಗಳ ಕೊರತೆಯನ್ನು ಒಳಗೊಂಡಿವೆ. ಉತ್ತಮ-ಶ್ರುತಿಗೆ ಉದಾಹರಣೆಯಾಗಿ: ನಮ್ಮ ನಿದರ್ಶನಗಳು tcp ಸಂಪರ್ಕಗಳಿಗೆ ನಿರ್ಬಂಧಗಳನ್ನು ಹೊಂದಿವೆ, ದುರದೃಷ್ಟವಶಾತ್, RDS ನಲ್ಲಿ ಇದನ್ನು ಮಾಡಲಾಗುವುದಿಲ್ಲ:

net.ipv4.tcp_keepalive_time=10
net.ipv4.tcp_keepalive_intvl=1
net.ipv4.tcp_keepalive_probes=5
net.ipv4.tcp_retries2=3

ಹೆಚ್ಚುವರಿಯಾಗಿ, AWS RDS ಸಾಮಾನ್ಯ ನಿದರ್ಶನ ಬೆಲೆಗಿಂತ ಎರಡು ಪಟ್ಟು ದುಬಾರಿಯಾಗಿದೆ, ಇದು ಈ ಪರಿಹಾರವನ್ನು ತ್ಯಜಿಸಲು ಮುಖ್ಯ ಕಾರಣವಾಗಿದೆ.

ಪತ್ರೋನಿ

Github ನಲ್ಲಿ ಉತ್ತಮ ದಾಖಲಾತಿ, ಸ್ವಯಂಚಾಲಿತ ವಿಫಲತೆ ಮತ್ತು ಮೂಲ ಕೋಡ್‌ನೊಂದಿಗೆ PostgreSQL ಅನ್ನು ನಿರ್ವಹಿಸಲು ಇದು ಪೈಥಾನ್ ಟೆಂಪ್ಲೇಟ್ ಆಗಿದೆ.

ಪಾಟ್ರೋನಿಯ ಸಾಧಕ:

ಪ್ರತಿಯೊಂದು ಕಾನ್ಫಿಗರೇಶನ್ ಪ್ಯಾರಾಮೀಟರ್ ಅನ್ನು ವಿವರಿಸಲಾಗಿದೆ, ಅದು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿದೆ;
ಸ್ವಯಂಚಾಲಿತ ವಿಫಲತೆ ಬಾಕ್ಸ್ ಹೊರಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ;
ಪೈಥಾನ್‌ನಲ್ಲಿ ಬರೆಯಲಾಗಿದೆ, ಮತ್ತು ನಾವೇ ಪೈಥಾನ್‌ನಲ್ಲಿ ಬಹಳಷ್ಟು ಬರೆಯುವುದರಿಂದ, ಸಮಸ್ಯೆಗಳನ್ನು ಎದುರಿಸಲು ನಮಗೆ ಸುಲಭವಾಗುತ್ತದೆ ಮತ್ತು ಬಹುಶಃ ಯೋಜನೆಯ ಅಭಿವೃದ್ಧಿಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ;
PostgreSQL ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ನಿಯಂತ್ರಿಸುತ್ತದೆ, ಕ್ಲಸ್ಟರ್‌ನ ಎಲ್ಲಾ ನೋಡ್‌ಗಳಲ್ಲಿ ಏಕಕಾಲದಲ್ಲಿ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಬದಲಾಯಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ, ಮತ್ತು ಹೊಸ ಸಂರಚನೆಯನ್ನು ಅನ್ವಯಿಸಲು ಕ್ಲಸ್ಟರ್‌ನ ಮರುಪ್ರಾರಂಭದ ಅಗತ್ಯವಿದ್ದರೆ, ಇದನ್ನು ಮತ್ತೆ Patroni ಬಳಸಿ ಮಾಡಬಹುದು.

ಕಾನ್ಸ್:

PgBouncer ನೊಂದಿಗೆ ಸರಿಯಾಗಿ ಕೆಲಸ ಮಾಡುವುದು ಹೇಗೆ ಎಂಬುದು ದಸ್ತಾವೇಜನ್ನು ಸ್ಪಷ್ಟವಾಗಿಲ್ಲ. ಇದನ್ನು ಮೈನಸ್ ಎಂದು ಕರೆಯುವುದು ಕಷ್ಟವಾದರೂ, PostgreSQL ಅನ್ನು ನಿರ್ವಹಿಸುವುದು Patroni ಕಾರ್ಯವಾಗಿದೆ, ಮತ್ತು Patroni ಗೆ ಸಂಪರ್ಕಗಳು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ ಎಂಬುದು ಈಗಾಗಲೇ ನಮ್ಮ ಸಮಸ್ಯೆಯಾಗಿದೆ;
ದೊಡ್ಡ ಪ್ರಮಾಣದಲ್ಲಿ ಪತ್ರೋನಿ ಅನುಷ್ಠಾನಕ್ಕೆ ಕೆಲವು ಉದಾಹರಣೆಗಳಿವೆ, ಆದರೆ ಮೊದಲಿನಿಂದಲೂ ಅನುಷ್ಠಾನಕ್ಕೆ ಹಲವು ಉದಾಹರಣೆಗಳಿವೆ.

ಪರಿಣಾಮವಾಗಿ, ನಾವು ವಿಫಲವಾದ ಕ್ಲಸ್ಟರ್ ರಚಿಸಲು Patroni ಆಯ್ಕೆ.

ಪಾಟ್ರೋನಿ ಅನುಷ್ಠಾನ ಪ್ರಕ್ರಿಯೆ

Patroni ಮೊದಲು, ನಾವು ಒಂದು ಮಾಸ್ಟರ್‌ನಲ್ಲಿ 12 PostgreSQL ಚೂರುಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ ಮತ್ತು ಅಸಮಕಾಲಿಕ ಪ್ರತಿಕೃತಿಯೊಂದಿಗೆ ಒಂದು ಪ್ರತಿಕೃತಿ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಅಪ್ಲಿಕೇಶನ್ ಸರ್ವರ್‌ಗಳು ನೆಟ್‌ವರ್ಕ್ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ ಮೂಲಕ ಡೇಟಾಬೇಸ್‌ಗಳನ್ನು ಪ್ರವೇಶಿಸಿದವು, ಅದರ ಹಿಂದೆ PgBouncer ನೊಂದಿಗೆ ಎರಡು ನಿದರ್ಶನಗಳಿವೆ ಮತ್ತು ಅವುಗಳ ಹಿಂದೆ ಎಲ್ಲಾ PostgreSQL ಸರ್ವರ್‌ಗಳು ಇದ್ದವು.

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

ಪತ್ರೋನಿ ಕಾನ್ಸುಲ್ ಜೊತೆ ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತಾರೆ

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

ಪತ್ರೋನಿಯನ್ನು ಕಾನ್ಸುಲ್‌ಗೆ ಸಂಪರ್ಕಿಸಲು, ನಾವು ಕಾನ್ಸುಲ್‌ನೊಂದಿಗೆ ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತೇವೆ ಮತ್ತು ಸಂಪರ್ಕ ರೇಖಾಚಿತ್ರವನ್ನು ಅವಲಂಬಿಸಿ ನೀವು ಹೋಸ್ಟ್ ಅನ್ನು http ಅಥವಾ https ಸ್ವರೂಪದಲ್ಲಿ ನಿರ್ದಿಷ್ಟಪಡಿಸಬೇಕು ಎಂದು ಹೇಳುವ ಅಧಿಕೃತ ದಸ್ತಾವೇಜನ್ನು ಅಧ್ಯಯನ ಮಾಡಿ, ಐಚ್ಛಿಕವಾಗಿ:

host: the host:port for the Consul endpoint, in format: http(s)://host:port
scheme: (optional) http or https, defaults to http

ಇದು ಸರಳವಾಗಿ ಕಾಣುತ್ತದೆ, ಆದರೆ ಇಲ್ಲಿಯೇ ಮೋಸಗಳು ಪ್ರಾರಂಭವಾಗುತ್ತವೆ. ಕಾನ್ಸುಲ್ ಜೊತೆಗೆ ನಾವು https ಮೂಲಕ ಸುರಕ್ಷಿತ ಸಂಪರ್ಕದ ಮೂಲಕ ಕೆಲಸ ಮಾಡುತ್ತೇವೆ ಮತ್ತು ನಮ್ಮ ಸಂಪರ್ಕ ಸಂರಚನೆಯು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ:

consul:
  host: https://server.production.consul:8080 
  verify: true
  cacert: {{ consul_cacert }}
  cert: {{ consul_cert }}
  key: {{ consul_key }}

ಆದರೆ ಅದು ಆ ರೀತಿ ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ. ಪ್ರಾರಂಭದಲ್ಲಿ, ಪತ್ರೋನಿಯು ಕಾನ್ಸುಲ್‌ಗೆ ಸಂಪರ್ಕಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ ಏಕೆಂದರೆ ಅದು ಇನ್ನೂ http ಮೂಲಕ ಹೋಗಲು ಪ್ರಯತ್ನಿಸುತ್ತದೆ.

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

consul:
  host: server.production.consul:8080
  scheme: https
  verify: true
  cacert: {{ consul_cacert }}
  cert: {{ consul_cert }}
  key: {{ consul_key }}

ಕಾನ್ಸಲ್-ಟೆಂಪ್ಲೇಟ್

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

ಪರಿಹಾರದ ಹುಡುಕಾಟದಲ್ಲಿ, ನಾವು ಲೇಖನವನ್ನು ಕಂಡುಕೊಂಡಿದ್ದೇವೆ (ದುರದೃಷ್ಟವಶಾತ್, ನನಗೆ ಹೆಸರು ನೆನಪಿಲ್ಲ), ಅಲ್ಲಿ ಕಾನ್ಸುಲ್-ಟೆಂಪ್ಲೇಟ್ PgBouncer ಮತ್ತು Patroni ಅನ್ನು ಸಂಯೋಜಿಸಲು ಬಹಳ ಸಹಾಯಕವಾಗಿದೆ ಎಂದು ಬರೆಯಲಾಗಿದೆ. ಇದು ಕಾನ್ಸಲ್-ಟೆಂಪ್ಲೇಟ್ನ ಕೆಲಸವನ್ನು ಅಧ್ಯಯನ ಮಾಡಲು ನಮ್ಮನ್ನು ಪ್ರೇರೇಪಿಸಿತು.

ಕಾನ್ಸುಲ್-ಟೆಂಪ್ಲೇಟ್ ಕಾನ್ಸುಲ್‌ನಲ್ಲಿ ಪೋಸ್ಟ್‌ಗ್ರೆಎಸ್‌ಕ್ಯುಎಲ್ ಕ್ಲಸ್ಟರ್‌ನ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ನಿರಂತರವಾಗಿ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುತ್ತದೆ ಎಂದು ಅದು ಬದಲಾಯಿತು. ನಾಯಕ ಬದಲಾದಾಗ, ಅದು PgBouncer ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ನವೀಕರಿಸುತ್ತದೆ ಮತ್ತು ಅದನ್ನು ಮರುಲೋಡ್ ಮಾಡಲು ಆಜ್ಞೆಯನ್ನು ಕಳುಹಿಸುತ್ತದೆ.

ಟೆಂಪ್ಲೇಟ್‌ನ ದೊಡ್ಡ ಪ್ರಯೋಜನವೆಂದರೆ ಅದನ್ನು ಕೋಡ್ ಆಗಿ ಸಂಗ್ರಹಿಸಲಾಗಿದೆ, ಆದ್ದರಿಂದ ಹೊಸ ಚೂರುಗಳನ್ನು ಸೇರಿಸುವಾಗ, ಹೊಸ ಬದ್ಧತೆಯನ್ನು ಮಾಡಲು ಮತ್ತು ಟೆಂಪ್ಲೇಟ್ ಅನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ನವೀಕರಿಸಲು ಸಾಕು, ಮೂಲಸೌಕರ್ಯವನ್ನು ಕೋಡ್ ತತ್ವವಾಗಿ ಬೆಂಬಲಿಸುತ್ತದೆ.

ಪತ್ರೋನಿಯೊಂದಿಗೆ ಹೊಸ ವಾಸ್ತುಶಿಲ್ಪ

ಪರಿಣಾಮವಾಗಿ, ನಾವು ಈ ಕೆಳಗಿನ ಕೆಲಸದ ಯೋಜನೆಯನ್ನು ಸ್ವೀಕರಿಸಿದ್ದೇವೆ:

ಎಲ್ಲಾ ಅಪ್ಲಿಕೇಶನ್ ಸರ್ವರ್‌ಗಳು ಬ್ಯಾಲೆನ್ಸರ್ ಅನ್ನು ಪ್ರವೇಶಿಸುತ್ತವೆ → ಅದರ ಹಿಂದೆ PgBouncer ನ ಎರಡು ನಿದರ್ಶನಗಳಿವೆ → ಪ್ರತಿ ನಿದರ್ಶನದಲ್ಲಿ ಕಾನ್ಸಲ್-ಟೆಂಪ್ಲೇಟ್ ಚಾಲನೆಯಲ್ಲಿದೆ, ಇದು ಪ್ರತಿ Patroni ಕ್ಲಸ್ಟರ್‌ನ ಸ್ಥಿತಿಯನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುತ್ತದೆ ಮತ್ತು PgBouncer ಸಂರಚನೆಯ ಪ್ರಸ್ತುತತೆಯನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುತ್ತದೆ, ಇದು ಪ್ರಸ್ತುತ ನಾಯಕನಿಗೆ ವಿನಂತಿಗಳನ್ನು ನಿರ್ದೇಶಿಸುತ್ತದೆ. ಪ್ರತಿ ಕ್ಲಸ್ಟರ್‌ನ.

ಹಸ್ತಚಾಲಿತ ಪರೀಕ್ಷೆ

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

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

ಹೆಚ್ಚಿನ ಹೊರೆಯಲ್ಲಿ ಬದುಕುವುದು ಮತ್ತು ಕನಿಷ್ಠ ಅಲಭ್ಯತೆಯನ್ನು ಹೇಗೆ ನಿರ್ವಹಿಸುವುದು?

ಎಲ್ಲವೂ ಸಂಪೂರ್ಣವಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ! ಆದರೆ ಹೊಸ ಪ್ರಶ್ನೆಗಳು ಉದ್ಭವಿಸುತ್ತವೆ: ಹೆಚ್ಚಿನ ಹೊರೆಯಲ್ಲಿ ಅದು ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ? ಉತ್ಪಾದನೆಯಲ್ಲಿ ಎಲ್ಲವನ್ನೂ ತ್ವರಿತವಾಗಿ ಮತ್ತು ಸುರಕ್ಷಿತವಾಗಿ ಹೊರಹಾಕುವುದು ಹೇಗೆ?

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

ಎರಡೂ ಕಾರ್ಯಗಳು ಮಹತ್ವಾಕಾಂಕ್ಷೆಯಂತೆ ಕಾಣುತ್ತವೆ, ಆದರೆ ನಾವು PostgreSQL 9.6 ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಬಹುಶಃ ನಾವು ಈಗಿನಿಂದಲೇ 11.2 ಗೆ ನವೀಕರಿಸಬಹುದೇ?

ನಾವು ಇದನ್ನು 2 ಹಂತಗಳಲ್ಲಿ ಮಾಡಲು ನಿರ್ಧರಿಸುತ್ತೇವೆ: ಮೊದಲು ಆವೃತ್ತಿಯನ್ನು 11.2 ಗೆ ನವೀಕರಿಸಿ, ನಂತರ Patroni ಅನ್ನು ಪ್ರಾರಂಭಿಸಿ.

PostgreSQL ನವೀಕರಣ

PostgreSQL ಆವೃತ್ತಿಯನ್ನು ತ್ವರಿತವಾಗಿ ನವೀಕರಿಸಲು, ನೀವು ಆಯ್ಕೆಯನ್ನು ಬಳಸಬೇಕು -k, ಇದರಲ್ಲಿ ಹಾರ್ಡ್ ಲಿಂಕ್ ಅನ್ನು ಡಿಸ್ಕ್ನಲ್ಲಿ ರಚಿಸಲಾಗಿದೆ ಮತ್ತು ನಿಮ್ಮ ಡೇಟಾವನ್ನು ನಕಲಿಸುವ ಅಗತ್ಯವಿಲ್ಲ. 300-400 GB ಡೇಟಾಬೇಸ್‌ಗಳಲ್ಲಿ, ನವೀಕರಣವು 1 ಸೆಕೆಂಡ್ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ.

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

/usr/lib/postgresql/11/bin/pg_upgrade 
<b>--link </b>
--old-datadir='' --new-datadir='' 
 --old-bindir=''  --new-bindir='' 
 --old-options=' -c config_file=' 
 --new-options=' -c config_file='

ನವೀಕರಣವನ್ನು ಪ್ರಾರಂಭಿಸುವ ಮೊದಲು, ನೀವು ಅದನ್ನು ನಿಯತಾಂಕದೊಂದಿಗೆ ನಿರ್ವಹಿಸಬೇಕು ಎಂದು ಇಲ್ಲಿ ಗಮನಿಸುವುದು ಮುಖ್ಯ --ಪರಿಶೀಲಿಸಿಅಪ್ಗ್ರೇಡ್ ಸಾಧ್ಯ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು. ನವೀಕರಣದ ಸಮಯದಲ್ಲಿ ನಮ್ಮ ಸ್ಕ್ರಿಪ್ಟ್ ಸಂರಚನೆಗಳನ್ನು ಸಹ ಬದಲಾಯಿಸುತ್ತದೆ. ನಮ್ಮ ಸ್ಕ್ರಿಪ್ಟ್ 30 ಸೆಕೆಂಡುಗಳಲ್ಲಿ ಪೂರ್ಣಗೊಂಡಿದೆ, ಇದು ಅತ್ಯುತ್ತಮ ಫಲಿತಾಂಶವಾಗಿದೆ.

ಪತ್ರೋನಿಯ ಉಡಾವಣೆ

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

ನಾವು ರೆಡಿಮೇಡ್ PostgreSQL ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ Patroni ಅನ್ನು ಸ್ಥಾಪಿಸಲು ಪ್ರಾರಂಭಿಸಿದಾಗ ಮತ್ತು ಅದನ್ನು ಪ್ರಾರಂಭಿಸಿದಾಗ, ನಾವು ಹೊಸ ಸಮಸ್ಯೆಯನ್ನು ಎದುರಿಸಿದ್ದೇವೆ: ಎರಡೂ ಸರ್ವರ್‌ಗಳನ್ನು ಲೀಡರ್ ಆಗಿ ಪ್ರಾರಂಭಿಸಲಾಗಿದೆ. ಪ್ಯಾಟ್ರೋನಿಗೆ ಕ್ಲಸ್ಟರ್‌ನ ಆರಂಭಿಕ ಸ್ಥಿತಿಯ ಬಗ್ಗೆ ಏನೂ ತಿಳಿದಿಲ್ಲ ಮತ್ತು ಎರಡೂ ಸರ್ವರ್‌ಗಳನ್ನು ಒಂದೇ ಹೆಸರಿನೊಂದಿಗೆ ಎರಡು ಪ್ರತ್ಯೇಕ ಕ್ಲಸ್ಟರ್‌ಗಳಾಗಿ ಚಲಾಯಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತದೆ. ಈ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು, ನೀವು ಸ್ಲೇವ್‌ನಲ್ಲಿನ ಡೇಟಾ ಡೈರೆಕ್ಟರಿಯನ್ನು ಅಳಿಸಬೇಕಾಗುತ್ತದೆ:

rm -rf /var/lib/postgresql/

ಇದನ್ನು ಗುಲಾಮರ ಮೇಲೆ ಮಾತ್ರ ಮಾಡಬೇಕು!

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

ನಾವು ಎದುರಿಸಿದ ಮತ್ತೊಂದು ತೊಂದರೆ ಏನೆಂದರೆ ಎಲ್ಲಾ PostgreSQL ಕ್ಲಸ್ಟರ್‌ಗಳನ್ನು ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಮುಖ್ಯ ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ. ಪ್ರತಿ ಕ್ಲಸ್ಟರ್‌ಗೆ ಇನ್ನೊಂದರ ಬಗ್ಗೆ ಏನೂ ತಿಳಿದಿಲ್ಲದಿದ್ದಾಗ, ಇದು ಸಾಮಾನ್ಯವಾಗಿದೆ. ಆದರೆ ನೀವು ಪತ್ರೋನಿಯನ್ನು ಬಳಸಲು ಬಯಸಿದಾಗ, ಎಲ್ಲಾ ಕ್ಲಸ್ಟರ್‌ಗಳು ವಿಶಿಷ್ಟವಾದ ಹೆಸರನ್ನು ಹೊಂದಿರಬೇಕು. PostgreSQL ಕಾನ್ಫಿಗರೇಶನ್‌ನಲ್ಲಿ ಕ್ಲಸ್ಟರ್ ಹೆಸರನ್ನು ಬದಲಾಯಿಸುವುದು ಪರಿಹಾರವಾಗಿದೆ.

ಲೋಡ್ ಪರೀಕ್ಷೆ

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

ಉತ್ಪಾದನೆಗೆ ಪತ್ರೋನಿ ಪ್ರಾರಂಭ

ಪರಿಣಾಮವಾಗಿ, ನಾವು ಈ ಕೆಳಗಿನ ಯೋಜನೆಯೊಂದಿಗೆ ಬಂದಿದ್ದೇವೆ:

PgBouncer ಸರ್ವರ್‌ಗೆ ಕಾನ್ಸುಲ್-ಟೆಂಪ್ಲೇಟ್ ಅನ್ನು ನಿಯೋಜಿಸಿ ಮತ್ತು ಪ್ರಾರಂಭಿಸಿ;
PostgreSQL ಆವೃತ್ತಿ 11.2 ಗೆ ನವೀಕರಣಗಳು;
ಕ್ಲಸ್ಟರ್ ಹೆಸರನ್ನು ಬದಲಾಯಿಸುವುದು;
ಪ್ಯಾಟ್ರೋನಿ ಕ್ಲಸ್ಟರ್‌ನ ಪ್ರಾರಂಭ.

ಅದೇ ಸಮಯದಲ್ಲಿ, ನಮ್ಮ ಯೋಜನೆಯು ಯಾವುದೇ ಸಮಯದಲ್ಲಿ ಮೊದಲ ಹಂತವನ್ನು ಮಾಡಲು ನಮಗೆ ಅನುಮತಿಸುತ್ತದೆ; ನಾವು ಪ್ರತಿ PgBouncer ಅನ್ನು ಕೆಲಸದಿಂದ ಒಂದೊಂದಾಗಿ ತೆಗೆದುಹಾಕಬಹುದು ಮತ್ತು ಅದರ ಮೇಲೆ ಕಾನ್ಸುಲ್-ಟೆಂಪ್ಲೇಟ್ ಅನ್ನು ನಿಯೋಜಿಸಬಹುದು ಮತ್ತು ಪ್ರಾರಂಭಿಸಬಹುದು. ನಾವು ಮಾಡಿದ್ದು ಅದನ್ನೇ.

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

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

ನಾವು ನಮ್ಮ ಸೇವೆಯನ್ನು ಮರುಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ, ಎಲ್ಲವೂ ಕಾರ್ಯನಿರ್ವಹಿಸಬೇಕು, ಬಳಕೆದಾರರು ಕೆಲಸ ಮಾಡುವುದನ್ನು ಮುಂದುವರೆಸಿದರು, ಆದರೆ ಗ್ರಾಫ್‌ಗಳಲ್ಲಿ ನಾವು ಕಾನ್ಸುಲ್ ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಅಸಹಜವಾಗಿ ಹೆಚ್ಚಿನ ಲೋಡ್ ಅನ್ನು ಗಮನಿಸಿದ್ದೇವೆ.

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

ಪ್ಯಾಟ್ರೋನಿ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಮರುಪ್ರಾರಂಭಿಸಿ

ಆದಾಗ್ಯೂ, ನಾವು ಅನುಮಾನಿಸದ ಹೊಸ ಸಮಸ್ಯೆ ನಮಗೆ ಸಿಕ್ಕಿತು. ಕಾನ್ಸುಲ್ ಅನ್ನು ನವೀಕರಿಸುವಾಗ, ಕಾನ್ಸುಲ್ ರಜೆ ಆಜ್ಞೆಯನ್ನು ಬಳಸಿಕೊಂಡು ನಾವು ಕಾನ್ಸುಲ್ ನೋಡ್ ಅನ್ನು ಕ್ಲಸ್ಟರ್‌ನಿಂದ ಸರಳವಾಗಿ ತೆಗೆದುಹಾಕುತ್ತೇವೆ → ಪ್ಯಾಟ್ರೋನಿ ಮತ್ತೊಂದು ಕಾನ್ಸುಲ್ ಸರ್ವರ್‌ಗೆ ಸಂಪರ್ಕಿಸುತ್ತದೆ → ಎಲ್ಲವೂ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಆದರೆ ನಾವು ಕಾನ್ಸುಲ್ ಕ್ಲಸ್ಟರ್‌ನ ಕೊನೆಯ ನಿದರ್ಶನಕ್ಕೆ ಬಂದಾಗ ಮತ್ತು ಅದಕ್ಕೆ ಕಾನ್ಸುಲ್ ರಜೆ ಆಜ್ಞೆಯನ್ನು ಕಳುಹಿಸಿದಾಗ, ಎಲ್ಲಾ ಪತ್ರೋನಿ ಕ್ಲಸ್ಟರ್‌ಗಳು ಸರಳವಾಗಿ ಪುನರಾರಂಭಗೊಂಡವು ಮತ್ತು ಲಾಗ್‌ಗಳಲ್ಲಿ ನಾವು ಈ ಕೆಳಗಿನ ದೋಷವನ್ನು ನೋಡಿದ್ದೇವೆ:

ERROR: get_cluster
Traceback (most recent call last):
...
RetryFailedError: 'Exceeded retry deadline'
ERROR: Error communicating with DCS
<b>LOG: database system is shut down</b>

ಪ್ಯಾಟ್ರೋನಿ ಕ್ಲಸ್ಟರ್ ತನ್ನ ಕ್ಲಸ್ಟರ್ ಬಗ್ಗೆ ಮಾಹಿತಿಯನ್ನು ಪಡೆಯಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ ಮತ್ತು ಮರುಪ್ರಾರಂಭಿಸಲಾಯಿತು.

ಪರಿಹಾರವನ್ನು ಕಂಡುಹಿಡಿಯಲು, ನಾವು ಗಿಥಬ್‌ನಲ್ಲಿನ ಸಮಸ್ಯೆಯ ಮೂಲಕ ಪ್ಯಾಟ್ರೋನಿಯ ಲೇಖಕರನ್ನು ಸಂಪರ್ಕಿಸಿದ್ದೇವೆ. ಅವರು ನಮ್ಮ ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್‌ಗಳಿಗೆ ಸುಧಾರಣೆಗಳನ್ನು ಸೂಚಿಸಿದ್ದಾರೆ:

consul:
 consul.checks: []
bootstrap:
 dcs:
   retry_timeout: 8

ನಾವು ಪರೀಕ್ಷಾ ಪರಿಸರದಲ್ಲಿ ಸಮಸ್ಯೆಯನ್ನು ಪುನರಾವರ್ತಿಸಲು ಸಾಧ್ಯವಾಯಿತು ಮತ್ತು ಅಲ್ಲಿ ಈ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಪರೀಕ್ಷಿಸಿದ್ದೇವೆ, ಆದರೆ ದುರದೃಷ್ಟವಶಾತ್ ಅವು ಕೆಲಸ ಮಾಡಲಿಲ್ಲ.

ಸಮಸ್ಯೆ ಇನ್ನೂ ಬಗೆಹರಿಯದೆ ಉಳಿದಿದೆ. ನಾವು ಈ ಕೆಳಗಿನ ಪರಿಹಾರಗಳನ್ನು ಪ್ರಯತ್ನಿಸಲು ಯೋಜಿಸುತ್ತೇವೆ:

ಪಾಟ್ರೋನಿ ಕ್ಲಸ್ಟರ್‌ನ ಪ್ರತಿ ನಿದರ್ಶನದಲ್ಲಿ ಕಾನ್ಸಲ್-ಏಜೆಂಟ್ ಅನ್ನು ಬಳಸಿ;
ಕೋಡ್‌ನಲ್ಲಿನ ಸಮಸ್ಯೆಯನ್ನು ಸರಿಪಡಿಸಿ.

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

ಅದೃಷ್ಟವಶಾತ್, ನಾವು ಯಾವುದೇ ಹೆಚ್ಚಿನ ದೋಷಗಳನ್ನು ಎದುರಿಸಲಿಲ್ಲ.

ಪತ್ರೋನಿ ಬಳಸುವ ಫಲಿತಾಂಶಗಳು

ಪತ್ರೋನಿಯ ಯಶಸ್ವಿ ಉಡಾವಣೆಯ ನಂತರ, ನಾವು ಪ್ರತಿ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಹೆಚ್ಚುವರಿ ಪ್ರತಿಕೃತಿಯನ್ನು ಸೇರಿಸಿದ್ದೇವೆ. ಈಗ ಪ್ರತಿ ಕ್ಲಸ್ಟರ್ ಒಂದು ಕೋರಮ್ನ ಹೋಲಿಕೆಯನ್ನು ಹೊಂದಿದೆ: ಒಂದು ನಾಯಕ ಮತ್ತು ಎರಡು ಪ್ರತಿಕೃತಿಗಳು, ಸ್ವಿಚ್ ಮಾಡುವಾಗ ಸ್ಪ್ಲಿಟ್-ಮೆದುಳಿನ ವಿರುದ್ಧ ರಕ್ಷಿಸಲು.

ಪತ್ರೋನಿ ಮೂರು ತಿಂಗಳಿಗಿಂತ ಹೆಚ್ಚು ಕಾಲ ಉತ್ಪಾದನೆಯಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದಾರೆ. ಈ ಸಮಯದಲ್ಲಿ, ಅವರು ಈಗಾಗಲೇ ನಮಗೆ ಸಹಾಯ ಮಾಡಲು ನಿರ್ವಹಿಸುತ್ತಿದ್ದರು. ಇತ್ತೀಚೆಗೆ, ಕ್ಲಸ್ಟರ್‌ಗಳಲ್ಲಿ ಒಂದಾದ ನಾಯಕ AWS ನಲ್ಲಿ ನಿಧನರಾದರು, ಸ್ವಯಂಚಾಲಿತ ವೈಫಲ್ಯವು ಕೆಲಸ ಮಾಡಿದೆ ಮತ್ತು ಬಳಕೆದಾರರು ಕೆಲಸ ಮಾಡುವುದನ್ನು ಮುಂದುವರೆಸಿದರು. ಪತ್ರೋನಿ ತನ್ನ ಮುಖ್ಯ ಕಾರ್ಯವನ್ನು ಪೂರೈಸಿದೆ.

Patroni ಬಳಸುವ ಸಂಕ್ಷಿಪ್ತ ಸಾರಾಂಶ:

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

ಮೂಲ: www.habr.com

ಫೇಲ್ಓವರ್ ಕ್ಲಸ್ಟರ್ PostgreSQL + Patroni. ಅನುಷ್ಠಾನದ ಅನುಭವ