MySQL "Table is marked as crashed" ದೋಷ ಮತ್ತು phpMyAdmin ಬಳಸಿ ಟೇಬಲ್ ರಿಪೇರ್

MySQL "Table is marked as crashed" ದೋಷ ಎಂದರೆ, ಸಾಮಾನ್ಯವಾಗಿ MyISAM ಸ್ಟೋರೇಜ್ ಎಂಜಿನ್ ಬಳಸಿ ನಿರ್ಮಿಸಿದ ಟೇಬಲ್ ಹಾಳಾಗಿರುವುದು ಮತ್ತು MySQL ಆ ಟೇಬಲ್‌ನನ್ನು ಸುರಕ್ಷಿತವಾಗಿ ಓದಲು ಸಾಧ್ಯವಾಗುತ್ತಿಲ್ಲ ಎಂಬುದನ್ನು ಸೂಚಿಸುತ್ತದೆ. ಈ ಸಮಸ್ಯೆಗೆ ತಕ್ಷಣದ ಪರಿಹಾರವೆಂದರೆ, ಡೇಟಾಬೇಸ್ ಬ್ಯಾಕಪ್ ತೆಗೆದು, phpMyAdmin ಮೂಲಕ ಆ ಟೇಬಲ್ ಅನ್ನು ಆಯ್ಕೆ ಮಾಡಿ ಟೇಬಲ್ ರಿಪೇರ್ ಕಾರ್ಯವನ್ನು ನಡೆಸುವುದು. ಆದರೆ ಈ ದೋಷ ಕೆಲವೊಮ್ಮೆ ಒಂದು ಕ್ಲಿಕ್‌ನಿಂದ ಪರಿಹರಿಸಬಹುದಾದ ಸರಳ ಸೂಚನೆ ಅಲ್ಲ; ಅಪ್ರತೀಕ್ಷಿತವಾಗಿ ಸರ್ವರ್‌ ಆಫ್ ಆಗುವುದು, ಡಿಸ್ಕ್ ತುಂಬುವುದು, ತಪ್ಪು SQL ಕ್ವೆರಿಗಳು, ಅತಿ ಹೆಚ್ಚಿನ ಬರಹ ಟ್ರಾಫಿಕ್ ಅಥವಾ ಹಳೆಯ MySQL ಸೆಟ್ಟಿಂಗ್‌ಗಳು ಕಾರಣವಾಗಬಹುದು. ಈ ಮಾರ್ಗದರ್ಶಿಯಲ್ಲಿ ದೋಷದ ಮೂಲ ಕಾರಣಗಳು, phpMyAdmin ಬಳಸಿ ಸುರಕ್ಷಿತ ರಿಪೇರ್ ಕ್ರಮಗಳು, ರಿಪೇರ್‌ ಮಾಡುವ ಮೊದಲು ಬ್ಯಾಕಪ್‌ ಪರೀಕ್ಷಿಸುವುದು ಮತ್ತು ದೋಷವನ್ನು ಇನ್ನುಮುಂದೆ ತಡೆಯುವ ಶಾಶ್ವತ ವಿಧಾನಗಳನ್ನೂ ವಿವರವಾಗಿ ಹಂತ ಹಂತವಾಗಿ ನೋಡಬಹುದು.

ನಿಮ್ಮ ವೆಬ್‌ಸೈಟ್ WordPress, OpenCart, ಸ್ವಂತ PHP ಸಾಫ್ಟ್ವೇರ್ ಅಥವಾ ಫೋರಂ ಸಿಸ್ಟಮ್ ಆಗಿರಬಹುದು. MySQL ಟೇಬಲ್ ಹಾಳಾಗಿದ್ದರೆ, ನಿಮ್ಮ ವೀಕ್ಷಕರು ವೈಟ್‌ ಸ್ಕ್ರೀನ್, 500 ದೋಷ, ಕನೆಕ್ಷನ್ ಟೈಮ್‌ಔಟ್ ಅಥವಾ ಆಡಳಿತ ಪ್ಯಾನಲಿನಲ್ಲಿ ಅನಿರೀಕ್ಷಿತ ಡೇಟಾಬೇಸ್ ದೋಷಗಳನ್ನು ಕಾಣಬಹುದು. ವಿಶೇಷವಾಗಿ ಇ-ಕಾಮರ್ಸ್‌ ಸೈಟ್‌ಗಳಲ್ಲಿ ಆರ್ಡರ್, ಪ್ರೊಡಕ್ಟ್, ಸೆಷನ್ ಅಥವಾ ಕಾರ್ಟ್ ಟೇಬಲ್‌ಗಳು ಹಾಳಾಗಿದ್ದರೆ, ಕೆಲವೇ ನಿಮಿಷಗಳ ಅಡಚಣೆ ಕೂಡ ಆದಾಯದ ನಷ್ಟಕ್ಕೆ ಕಾರಣವಾಗಬಹುದು. ಆದ್ದರಿಂದ, ಟೇಬಲ್ ರಿಪೇರ್ ಮಾಡುವಾಗ ಡೇಟಾ ಸುರಕ್ಷತೆ ಮತ್ತು ದೋಷದ ಮೂಲವನ್ನು ಪತ್ತೆಹಚ್ಚುವುದೂ ಮುಖ್ಯ. ವಿಶ್ವಾಸಾರ್ಹ ಹೋಸ್ಟಿಂಗ್‌ ಸೌಲಭ್ಯ, ನಿಯಮಿತ ಬ್ಯಾಕಪ್‌ ಮತ್ತು ಸರಿಯಾದ ಡೇಟಾಬೇಸ್ ಎಂಜಿನ್‌ ಆಯ್ಕೆ ಈ ರೀತಿಯ ಅಪಾಯಗಳನ್ನು ಬಹುಮಾನವಾಗಿ ಕಡಿಮೆ ಮಾಡುತ್ತದೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ ನಿರ್ವಹಣೆಯೂ, ಮಾನಿಟರಿಂಗ್‌ ಮಾಡಬಹುದಾದ ಇನ್‌ಫ್ರಾ ಬೇಕಾದರೆ Hostragons ವೆಬ್ ಹೋಸ್ಟಿಂಗ್ ಅಥವಾ ಹೆಚ್ಚಿನ ರಿಸೋರ್ಸ್ ಬೇಕಾದ ಪ್ರಾಜೆಕ್ಟ್‌ಗಳಿಗೆ Hostragons VPS ಸರ್ವರ್ ಆಯ್ಕೆ ಮಾಡಬಹುದು.

Table is marked as crashed ದೋಷ ಎಂದರೇನು?

Table is marked as crashed ದೋಷ ಎಂದರೆ, MySQL ಸರ್ವರ್ ಒಂದು ಟೇಬಲ್‌ನ್ನು ಹಾಳಾಗಿದೆ ಎಂದು ಗುರುತಿಸಿ, ಆ ಟೇಬಲ್‌ ಮೇಲೆ ಓದು/ಬರೆಯುವ ಕಾರ್ಯದಲ್ಲಿ ಸಮಸ್ಯೆ ಎದುರಿಸುತ್ತಿದೆ ಎಂದು ಸೂಚಿಸುತ್ತದೆ. ಈ ದೋಷ ಸಂದೇಶ ಸಾಮಾನ್ಯವಾಗಿ ಇಂತಹ ರೂಪದಲ್ಲಿ ಬರುತ್ತದೆ: Table './veritabani/tablo_adi' is marked as crashed and should be repaired ಅಥವಾ Incorrect key file for table. ಈ ಸಂದೇಶ, ಟೇಬಲ್ ಫೈಲ್, ಇಂಡೆಕ್ಸ್ ಅಥವಾ ಟೇಬಲ್ ಇಂಟೆಗ್ರಿಟಿಯಲ್ಲಿ ಸಮಸ್ಯೆ ಇದೆ ಎಂದು ಸೂಚಿಸುತ್ತದೆ.

ಈ ದೋಷ ಬಹಳಷ್ಟು MyISAM ಟೇಬಲ್‌ಗಳಲ್ಲಿ ಕಾಣಿಸುತ್ತದೆ. MyISAM ಒಂದು ಹಳೆಯ ಮತ್ತು ವೇಗದ ಓದು ಕೇಂದ್ರಿತ ಸ್ಟೋರೇಜ್ ಎಂಜಿನ್ ಆಗಿದೆ; ಆದರೆ ಇದರಲ್ಲಿ InnoDB ಎಂಜಿನ್‌ನಷ್ಟು ಕ್ರ್ಯಾಶ್ ರಿಕವರಿ ಸಾಮರ್ಥ್ಯ ಇಲ್ಲ. ಸರ್ವರ್ ಅಪ್ರತೀಕ್ಷಿತವಾಗಿ ಆಫ್ ಆಗುವುದರಿಂದ, ಡಿಸ್ಕ್‌ ಬರಹ ಕಾರ್ಯ ಮಧ್ಯದಲ್ಲಿ ನಿಲ್ಲುವುದರಿಂದ ಅಥವಾ MySQL ಸೇವೆ ಸರಿಯಾಗಿ ಶಟ್‌ಡೌನ್ ಆಗದೆ ಮುಗಿಯುವುದರಿಂದ MyISAM ಟೇಬಲ್‌ಗಳು ಸುಲಭವಾಗಿ ಹಾಳಾಗಬಹುದು. InnoDB ಎಂಜಿನ್‌ transaction log ಮತ್ತು crash recovery ಯಲ್ಲಿ ಹೆಚ್ಚು ಬಲವಾಗಿದೆ; ಆದರೆ InnoDB ಟೇಬಲ್‌ಗಳಲ್ಲಿಯೂ ಯಾವಾಗಲೂ ಸಮಸ್ಯೆ ಬರುವುದಿಲ್ಲ ಎಂದರ್ಥವಲ್ಲ. InnoDB ಟೇಬಲ್‌ಗಳಲ್ಲಿ ಹೆಚ್ಚು ಟೇಬಲ್ ಸ್ಪೇಸ್, ಡಿಸ್ಕ್, transaction log ಅಥವಾ data dictionary ಸಮಸ್ಯೆಗಳಾಗಿ ಕಾಣಬಹುದು.

ಸಾಮಾನ್ಯ ಕಾರಣಗಳು

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

• ಅಪ್ರತೀಕ್ಷಿತ ಸರ್ವರ್‌ ಆಫ್ ಆಗುವುದು: ವಿದ್ಯುತ್ ಕಡಿತ, hardware reset ಅಥವಾ OS crash ಸಮಯದಲ್ಲಿ MySQL ಟೇಬಲ್‌ಗೆ ಬರೆಯುತ್ತಿದ್ದರೆ ಟೇಬಲ್ ಹಾಳಾಗಬಹುದು.
• ಡಿಸ್ಕ್‌ ಸ್ಪೇಸ್‌ ತುಂಬುವುದು: MySQL temp files, index ಅಥವಾ ಟೇಬಲ್ update ಬರೆಯಲು ಸಾಧ್ಯವಾಗದೆ data integrity ಹಾಳಾಗಬಹುದು. ಡಿಸ್ಕ್‌ ಉಪಯೋಗ 90% ದಾಟಿದರೆ ಅಪಾಯ ಹೆಚ್ಚಾಗಿ ಬರುತ್ತದೆ.
• MySQL ಸೇವೆ ಜೋರಾಗಿ ನಿಲ್ಲಿಸುವುದು: kill -9 ಮೊದಲಾದ ಕಮಾಂಡ್‌ಗಳ ಮೂಲಕ ಬಲಾತ್ಕಾರವಾಗಿ ನಿಲ್ಲಿಸಿದರೆ, ವಿಶೇಷವಾಗಿ MyISAM ಟೇಬಲ್‌ಗಳ ಬರಹ ಸಮಯದಲ್ಲಿ ಸಮಸ್ಯೆ ತಲೆಎತ್ತಬಹುದು.
• ಅತಿ ಹೆಚ್ಚು ಬರಹ ಟ್ರಾಫಿಕ್: ಲಾಗ್, ಕೌಂಟರ್, ಸೆಷನ್ ಅಥವಾ ಸರ್ಚ್ ಟೇಬಲ್‌ಗಳು MyISAM ಬಳಸಿದ್ದರೆ ಹೆಚ್ಚು ಅಪಾಯ.
• ತಪ್ಪು ಪ್ಲಗಿನ್ ಅಥವಾ ಥೀಮ್: WordPress ಮೊದಲಾದ ಸಿಸ್ಟಮ್‌ಗಳಲ್ಲಿ ತಪ್ಪಾಗಿ ಬರೆಯಲಾದ ಪ್ಲಗಿನ್‌ಗಳು ಅತಿ ಹೆಚ್ಚು SQL ಕ್ವೆರಿಗಳನ್ನು ಉಂಟುಮಾಡಿ ಟೇಬಲ್‌ ಲಾಕ್ ಆಗಬಹುದು.
• hardware ಅಥವಾ file system ದೋಷ: ಡಿಸ್ಕ್ bad sector, I/O error ಅಥವಾ file system corruption ಡೇಟಾಬೇಸ್‌ ಫೈಲ್‌ಗಳನ್ನು ಹಾಳು ಮಾಡಬಹುದು.
• ಹಳೆಯ MySQL ಆವೃತ್ತಿ: ಅಪ್‌ಡೇಟ್ ಆಗದ ಆವೃತ್ತಿಗಳಲ್ಲಿ ಪರಫಾರ್ಮೆನ್ಸ್, ಲಾಕ್ ಮತ್ತು ರಿಕವರಿ ಶಕ್ತಿಗಳು ಕಡಿಮೆ ಆಗಿರಬಹುದು.

ರಿಪೇರ್‌ಗೆ ಮೊದಲು ಮುಖ್ಯ ಸುರಕ್ಷತಾ ಕ್ರಮಗಳು

ಡೇಟಾಬೇಸ್‌ ರಿಪೇರ್ ಕಾರ್ಯ ಸಾಮಾನ್ಯವಾಗಿ ಸುರಕ್ಷಿತ; ಆದರೆ ಹಾಳಾದ ಟೇಬಲ್‌ನಲ್ಲಿ ಮಾಡುವ ಪ್ರತಿಯೊಂದು ಕಾರ್ಯವು data loss ಅಪಾಯವನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಹೋಗಲಾಡಿಸುವುದಿಲ್ಲ. ವಿಶೇಷವಾಗಿ live ಸೈಟ್‌ಗಳಲ್ಲಿ, ಪ್ರಾಥಮಿಕವಾಗಿಯೂ ಬ್ಯಾಕಪ್‌ ಮುಖ್ಯ.

1. ಪ್ರಸ್ತುತ ಡೇಟಾಬೇಸ್‌ ಬ್ಯಾಕಪ್ ತೆಗೆದುಕೊಳ್ಳಿ

phpMyAdmin ಮೂಲಕ ರಿಪೇರ್ ಆರಂಭಿಸುವ ಮೊದಲು, ಡೇಟಾಬೇಸ್‌ನ ತಕ್ಷಣದ ಬ್ಯಾಕಪ್ export ಮಾಡಬೇಕು. ಟೇಬಲ್‌ ಹಾಳಾಗಿದ್ದರೂ ಓದಬಹುದಾದ data ಯನ್ನು ಉಳಿಸುವುದು ಮುಖ್ಯ. phpMyAdmin ನಲ್ಲಿ ಡೇಟಾಬೇಸ್‌ ಆಯ್ಕೆ ಮಾಡಿ, Export ಟ್ಯಾಬ್ ಕ್ಲಿಕ್ ಮಾಡಿ, quick badalu custom ಆಯ್ಕೆ ಮಾಡಿ ಮತ್ತು SQL ಫಾರ್ಮ್ಯಾಟ್‌ ನಲ್ಲಿ export ಮಾಡಿ. ದೊಡ್ಡ ಡೇಟಾಬೇಸ್‌ಗಳಲ್ಲಿಯೂ export ಸಮಯದಲ್ಲಿ timeout ಆಗಬಹುದು; ಹೀಗೆ hosting control panel backup tool ಅಥವಾ SSH ಮೂಲಕ mysqldump ಹೆಚ್ಚು ವಿಶ್ವಾಸಾರ್ಹ. ನಿಯಮಿತ ಬ್ಯಾಕಪ್‌ ನೀತಿ ಇಲ್ಲದ ಪ್ರಾಜೆಕ್ಟ್‌ಗಳಿಗಾಗಿ ಹೋಸ್ಟಿಂಗ್ ಆಮ್ಲಜನಕ ಪರಿಹಾರಗಳು ನೋಡಿ.

2. ಯಾವ ಟೇಬಲ್ ಹಾಳಾಗಿದೆ ಎಂದು ಗುರುತಿಸಿ

ದೋಷ ಸಂದೇಶದಲ್ಲಿ ಸಾಮಾನ್ಯವಾಗಿ ಟೇಬಲ್ ಹೆಸರು ಬರುತ್ತದೆ. ಉದಾಹರಣೆಗೆ WordPress‌ ನಲ್ಲಿ wp_options, wp_posts, wp_comments ಅಥವಾ wp_actionscheduler_actions ಟೇಬಲ್‌ಗಳು. ಸ್ವಂತ ಸಾಫ್ಟ್ವೇರ್‌ಗಳಲ್ಲಿ ಟೇಬಲ್ ಹೆಸರು application logs, PHP error logs ಅಥವಾ MySQL error log ನಲ್ಲಿ ಕಾಣಬಹುದು. ತಪ್ಪು ಟೇಬಲ್‌ ಗುರುತಿಸಿದರೆ, ಅವಶ್ಯಕವಿಲ್ಲದ ಟೇಬಲ್‌ಗಳಲ್ಲಿ ರಿಪೇರ್‌ ಮಾಡಲಾಗಬಹುದು.

3. ಸೈಟ್ ಅನ್ನು ತಾತ್ಕಾಲಿಕವಾಗಿ maintenance mode ಗೆ ಹಾಕಿ

ರಿಪೇರ್ ಸಮಯದಲ್ಲಿ ಟೇಬಲ್‌ ಮೇಲೆ ಹೊಸ ಬರಹ ಕಾರ್ಯ ಬಂದರೆ, ಪ್ರಕ್ರಿಯೆ ವಿಫಲವಾಗಬಹುದು ಅಥವಾ data inconsistency ಆಗಬಹುದು. ಹೆಚ್ಚು ಟ್ರಾಫಿಕ್‌ ಇರುವ ಸೈಟ್‌ಗಳಲ್ಲಿ 2-5 ನಿಮಿಷ maintenance mode ಇದರಿಂದ ಕಾರ್ಯ ಹೆಚ್ಚು ಸುರಕ್ಷಿತ. WordPress‌ ನಲ್ಲಿ maintenance plugin, ಸ್ವಂತ ಸಾಫ್ಟ್ವೇರ್‌ಗಳಲ್ಲಿ ತಾತ್ಕಾಲಿಕ maintenance ಪೇಜ್ ಅಥವಾ web server redirect ಮೂಲಕ visitor activity ನಿಲ್ಲಿಸಬಹುದು. SSL certificate ಸೈಟ್‌ನಲ್ಲಿ ಸಕ್ರಿಯವಾಗಿರಬೇಕು; ಪ್ರಮಾಣಪತ್ರ ಸಮಸ್ಯೆ ಇದ್ದರೆ SSL ನ್ಯಾಯોચ್ಕಾರ ಆಯ್ಕೆ ಮಾಡಿ.

phpMyAdmin ಮೂಲಕ MySQL ಟೇಬಲ್ ಹೇಗೆ ರಿಪೇರ್ ಮಾಡುವುದು?

phpMyAdmin, command line ಪ್ರಯೋಗವಿಲ್ಲದ ಬಳಕೆದಾರರಿಗೆ MySQL ಟೇಬಲ್ ರಿಪೇರ್ ಸುಲಭವಾಗಿಸುತ್ತದೆ. ಕೆಳಗಿನ ಹಂತಗಳು cPanel, Plesk ಮತ್ತು ಇತರ hosting panels‌ ನಲ್ಲಿ ಸಾಮಾನ್ಯ.

ಹಂತ 1: Hosting panel ಮೂಲಕ phpMyAdmin ಪ್ರವೇಶಿಸಿ

Hosting control panel ಗೆ login ಮಾಡಿ, Databases ವಿಭಾಗದಲ್ಲಿ phpMyAdmin ಲಿಂಕ್‌ ತೆಗೆಯಿರಿ. ಒಂದಕ್ಕಿಂತ ಹೆಚ್ಚು hosting account ಅಥವಾ domain ಇದ್ದರೆ ಸರಿಯಾದ account ಆಯ್ಕೆ ಮಾಡಿರುವುದನ್ನು ಖಚಿತಪಡಿಸಿ. ತಪ್ಪು ಡೇಟಾಬೇಸ್‌ ಮೇಲೆ ಕಾರ್ಯ ಮಾಡಿದರೆ data ಗೆ ನಷ್ಟವಾಗದು, ಆದರೆ ಸಮಯ ವ್ಯರ್ಥವಾಗಬಹುದು ಮತ್ತು live site ಬದಲು test site ರಿಪೇರ್ ಆಗಬಹುದು. domain-hosting mismatch ಇದ್ದರೆ ಡೊಮೇನ್ ನಿರ್ವಹಣೆ ನೋಡಿ.

ಹಂತ 2: ಸರಿಯಾದ ಡೇಟಾಬೇಸ್‌ ಆಯ್ಕೆ ಮಾಡಿ

ಎಡ ಮೆನು ಮೂಲಕ ನಿಮ್ಮ ಸೈಟ್‌ ಬಳಸುವ ಡೇಟಾಬೇಸ್‌ ಆಯ್ಕೆ ಮಾಡಿ. WordPress‌ ನಲ್ಲಿ wp-config.php ನಲ್ಲಿ DB_NAME ಸಾಲು ನೋಡಿ. ಸ್ವಂತ PHP ಪ್ರಾಜೆಕ್ಟ್‌ಗಳಲ್ಲಿ config.php, .env ಅಥವಾ database.php ಫೈಲ್‌ಗಳಲ್ಲಿ database ಹೆಸರು ಇರಬಹುದು. ಒಂದೇ ಸರ್ವರ್‌ನಲ್ಲಿ ಹಲವು ಸೈಟ್‌ ಇದ್ದರೆ ಈ ಹಂತ ಬಹುಮಾನ.

ಹಂತ 3: ಹಾಳಾದ ಟೇಬಲ್‌ ಆಯ್ಕೆ ಮಾಡಿ

ಡೇಟಾಬೇಸ್‌ ತೆಗೆಯುತ್ತಿದ್ದಾಗ ಟೇಬಲ್‌ಗಳ ಪಟ್ಟಿ ಬರುತ್ತದೆ. ದೋಷ ಸಂದೇಶದಲ್ಲಿರುವ ಟೇಬಲ್‌ ಹುಡುಕಿ, ಅದರ ಬಲದಲ್ಲಿ ಇರುವ ಚಕ್‌ಬಾಕ್ಸ್‌ ಟಿಕ್ ಮಾಡಿ. ಒಂದಕ್ಕಿಂತ ಹೆಚ್ಚು ಟೇಬಲ್‌ಗಳಿಗೆ ಇದೇ ದೋಷ ಇದ್ದರೆ ಎಲ್ಲವನ್ನು ಆಯ್ಕೆ ಮಾಡಬಹುದು; ಆದರೆ ಮುಖ್ಯ ಟೇಬಲ್‌ ಮೊದಲು ರಿಪೇರ್ ಮಾಡುವುದೇ ಶ್ರೇಷ್ಠ. MyISAM ಟೇಬಲ್‌ ಎಂದು ಖಚಿತಪಡಿಸಲು Type ಅಥವಾ Engine ಕಾಲಮ್ ನೋಡಿ.

ಹಂತ 4: Tabloyu onar ಆಯ್ಕೆ ಮಾಡಿ

ಟೇಬಲ್‌ ಆಯ್ಕೆ ಮಾಡಿದ ನಂತರ ಪುಟದ ಕೆಳಗಿನ dropdown‌ ನಲ್ಲಿ Tabloyu onar (Repair table) ಆಯ್ಕೆ ಮಾಡಿ. phpMyAdmin ಹಿನ್ನಲೆಯಲ್ಲಿ ಸಾಮಾನ್ಯವಾಗಿ REPAIR TABLE tablo_adi ಕಮಾಂಡ್‌ ಅನ್ನು execute ಮಾಡುತ್ತದೆ. ಕಾರ್ಯ ಪೂರ್ಣಗೊಂಡಾಗ result OK, warning ಅಥವಾ error ಬರುತ್ತದೆ. OK ಎಂದರೆ ಯಶಸ್ವಿ. ದೊಡ್ಡ ಟೇಬಲ್‌ಗಳಲ್ಲಿ ಕಾರ್ಯಕ್ಕೆ ಕೆಲವೊಂದು ನಿಮಿಷಗಳು ಬೇಕಾಗಬಹುದು; ಈ ಸಮಯದಲ್ಲಿ ಪುಟ refresh ಮಾಡಬೇಡಿ ಅಥವಾ browser ಮುಚ್ಚಬೇಡಿ.

ಹಂತ 5: ಟೇಬಲ್‌ ಪರಿಶೀಲಿಸಿ ಮತ್ತು ಸೈಟ್‌ teste ಮಾಡಿ

ರಿಪೇರ್‌ ನಂತರ, ಅದೇ dropdown‌ ನಲ್ಲಿ Tabloyu kontrol et (Check table) ಪ್ರಯೋಗಿಸಿ. ನಂತರ ವೆಬ್‌ಸೈಟ್‌ home page, admin panel, search function, product list ಮತ್ತು user login teste ಮಾಡಿ. WordPress‌ ನಲ್ಲಿ permalinks save ಮಾಡಿ, cache clear ಮಾಡಿ ಮತ್ತು error log ಚೆಕ್‌ ಮಾಡಿ.

phpMyAdmin ರಿಪೇರ್ ಆಯ್ಕೆಗಳ ಅರ್ಥವೇನು?

phpMyAdmin ನಲ್ಲಿ ಟೇಬಲ್‌ ರಿಪೇರ್ ಮಾತ್ರವಲ್ಲ, ಟೇಬಲ್‌ maintenance ಗೆ ವಿವಿಧ ಆಯ್ಕೆಗಳಿವೆ. ಪ್ರತಿಯೊಂದು ಆಯ್ಕೆ ವಿಭಿನ್ನ ಉದ್ದೇಶಕ್ಕೆ; ತಪ್ಪು ನಿರೀಕ್ಷೆಯಿಂದ ಬಳಸಬಾರದು.

ಸಾರಾಂಶವಾಗಿ, Table is marked as crashed ದೋಷಕ್ಕೆ ಸರಿಯಾದ ಆಯ್ಕೆ Tabloyu onar (Repair) ಕಾರ್ಯ. Optimize ಮತ್ತು Analyze ಟೇಬಲ್‌ಗಳು ಉಪಯುಕ್ತ maintenance tools; ಆದರೆ ಹಾಳಾದ ಟೇಬಲ್‌ ಡೈರೆಕ್ಟ್‌ಾಗಿ ಸರಿಪಡಿಸಲು ಸಾಕಾಗದು.

InnoDB ಟೇಬಲ್‌ಗಳಲ್ಲಿ ಸಮಸ್ಯೆ ಯಾಕೆ ವಿಭಿನ್ನ?

phpMyAdmin ನಲ್ಲಿ InnoDB ಟೇಬಲ್‌ಗಳಿಗೆ Tabloyu onar (Repair) ಆಯ್ಕೆ ಎಲ್ಲ ಸಮಯದಲ್ಲಿ ನಿರೀಕ್ಷಿತ ರೀತಿಯಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ. ಕಾರಣ, InnoDB MyISAM ತರಹ ಸರಳ ಫೈಲ್‌ based repair logic ಬಳಸದಿರುವುದರಿಂದ. InnoDB transaction log, redo log, undo log ಮತ್ತು tablespace ರಚನೆ data integrity ಕಾಪಾಡುತ್ತದೆ. ಹೀಗಾಗಿ InnoDB ಸಮಸ್ಯೆಗಳಿಗೆ ಪರಿಹಾರ MySQL logs ಚೆಕ್‌ ಮಾಡುವುದು, ಡಿಸ್ಕ್‌ ಸ್ಥಿತಿ ವೀಕ್ಷಣೆ, ಬ್ಯಾಕಪ್‌ restore ಅಥವಾ advanced recovery modes ಬಳಸುವುದು.

MyISAM ಟೇಬಲ್‌ ದೋಷ ಸಂದೇಶ ಇದೆಯೆಂದರೆ phpMyAdmin ರಿಪೇರ್ ಬಹುಮಾನವಾಗಿ ಯಶಸ್ವಿ. ಆದರೆ InnoDB ಕಡೆ corrupt, tablespace, cannot open table ತರಹದ ಸಂದೇಶ ಬಂದರೆ, ಡೈರೆಕ್ಟ್‌ ರಿಪೇರ್‌ ಬದಲು ಮೊದಲು ಬ್ಯಾಕಪ್‌ ತೆಗೆದು, ಸರ್ವರ್‌ logs ಪರಿಶೀಲಿಸಿ, hosting support ಸಂಪರ್ಕಿಸಬೇಕು. ವಿಶೇಷವಾಗಿ ಇ-ಕಾಮರ್ಸ್‌ data ಇದ್ದರೆ random experiments ಬಿಟ್ಟು, professional intervention ಪಡೆದುಕೊಳ್ಳುವುದು ಶ್ರೇಷ್ಠ.

ರಿಪೇರ್ ವಿಫಲವಾದರೆ ಏನು ಮಾಡಬೇಕು?

phpMyAdmin ಮೂಲಕ ಟೇಬಲ್‌ ರಿಪೇರ್ ಕಾರ್ಯ ಎಲ್ಲಾ ಸಮಯದಲ್ಲಿ ಯಶಸ್ವಿಯಾಗುವುದಿಲ್ಲ. ದೊಡ್ಡ ಟೇಬಲ್‌ಗಳು, deep corruption, disk ದೋಷ ಅಥವಾ permission issue ಇದ್ದರೆ ಕಾರ್ಯ ಮಧ್ಯದಲ್ಲಿ ನಿಲ್ಲಬಹುದು. ಈ ಸಂದರ್ಭದಲ್ಲಿ ಈ ಕ್ರಮಗಳು ಪ್ರಯೋಗಿಸಬಹುದು:

• ಬ್ಯಾಕಪ್‌ನಿಂದ restore: ಭದ್ರವಾದ ವಿಧಾನ ಎಂದರೆ ದೋಷ ಬಾರದ ಹತ್ತಿರದ ದಿನದ backup restore ಮಾಡುವುದು. restore ಮೊದಲು ಹಾಳಾದ ಡೇಟಾಬೇಸ್‌ ಬೇರೆ ಫೈಲ್‌ಗಳಾಗಿ ಉಳಿಸಿ.
• SSH ಮೂಲಕ myisamchk: MyISAM ಟೇಬಲ್‌ಗಳಿಗೆ server access ಇದ್ದರೆ myisamchk tool ಬಳಸಬಹುದು. ಈ ಕಾರ್ಯ MySQL service ನಿಲ್ಲಿಸಿ ಅಥವಾ ಟೇಬಲ್‌ lock ಮಾಡಿ ಮಾಡಬೇಕು.
• REPAIR TABLE command: phpMyAdmin SQL ಟ್ಯಾಬ್‌ನಲ್ಲಿ REPAIR TABLE tablo_adi; command ಬಳಸಬಹುದು. ದೊಡ್ಡ ಟೇಬಲ್‌ಗಳಿಗೆ QUICK ಅಥವಾ EXTENDED option ಪ್ರಯೋಗಿಸಿ.
• Disk ಮತ್ತು inode check: ಡಿಸ್ಕ್ space ಅಥವಾ inode ತುಂಬಿದರೆ ರಿಪೇರ್ ವಿಫಲ. ಸಚ್ಛಾಕಾಗಿ temp, log ಮತ್ತು backup files delete ಮಾಡಿ.
• Server error logs ಪರಿಶೀಲನೆ: MySQL error log, web server log ಮತ್ತು PHP error log ಮೂಲ ಕಾರಣ ತಿಳಿಸಲು ಉಪಯುಕ್ತ.

Shared hosting‌ ಬಳಕೆದಾರರಿಗೆ SSH ಅಥವಾ service stop access ಇಲ್ಲ. ಈ ಸಂದರ್ಭದಲ್ಲಿ support‌ಗೆ error message, table name, approximate time ಮತ್ತು backup date ತಿಳಿಸುವುದು ಪರಿಹಾರವನ್ನು ವೇಗಗೊಳಿಸುತ್ತದೆ.

ದೋಷ ಪುನಃ ಬರದಂತೆ ಹೇಗೆ ತಡೆಯಬೇಕು?

ಒಮ್ಮೆ ರಿಪೇರ್‌ ಮಾಡಿದರೆ ತಾತ್ಕಾಲಿಕ ಪರಿಹಾರ; ಶಾಶ್ವತ ಪರಿಹಾರ infra ಮತ್ತು maintenance discipline. ಕೆಳಗಿನ ಕ್ರಮಗಳು MySQL ಟೇಬಲ್‌ corruption ಅಪಾಯವನ್ನು ಬಹುಮಾನವಾಗಿ ಕಡಿಮೆ ಮಾಡುತ್ತವೆ.

MyISAM ಟೇಬಲ್‌ಗಳನ್ನು InnoDBಗೆ ಪರಿವರ್ತನೆ ಮಾಡಿ

ಇತ್ತೀಚಿನ ವೆಬ್‌ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಲ್ಲಿ InnoDB ಹೆಚ್ಚು ಭದ್ರ ಮತ್ತು ಸ್ಥಿರ ಆಯ್ಕೆ. row-level locking, transaction support ಮತ್ತು crash recovery ಪ್ರಯೋಜನಗಳಿಂದ MyISAM‌ಗಿಂತ ಹೆಚ್ಚು writing traffic‌ಗೆ ಸರಿಹೊಂದುತ್ತದೆ. ಪರಿವರ್ತನೆ ALTER TABLE tablo_adi ENGINE=InnoDB; ಮೂಲಕ ಸುಲಭ, ಆದರೆ live site‌ನಲ್ಲಿ ಪ್ರಯೋಗಿಸುವ ಮೊದಲು staging‌ನಲ್ಲಿ teste ಮಾಡಿ ಮತ್ತು ಸಂಪೂರ್ಣ ಬ್ಯಾಕಪ್‌ ತೆಗೆದುಕೊಳ್ಳಿ. ಕೆಲವು ಹಳೆಯ ಸಾಫ್ಟ್‌ವೇರ್‌ಗಳು fulltext index ಅಥವಾ MyISAM peculiarities‌ಗೆ ಅವಲಂಬಿತವಾಗಿರಬಹುದು.

ನಿಯಮಿತ ಮತ್ತು restore ಮಾಡಬಹುದಾದ backup‌ಗಳು

ಬ್ಯಾಕಪ್‌ simple ಆಗಿ ತೆಗೆದುಕೊಂಡಿದ್ದೆಂದು ಅಲ್ಲ, restore ಮಾಡಬಹುದಾದದ್ದೂ ಆಗಿರಬೇಕು. ದೈನಂದಿನ backup‌ಗಳು, ವಾರದ full backup‌ಗಳು ಮತ್ತು update‌ಗಳ ಮೊದಲು manual backup‌ policy. ಕನಿಷ್ಠ 7 ದಿನದ backup‌ಗಳು ಬಹುತೇಕ ಸಣ್ಣ-ಮಧ್ಯಮ ಸೈಟ್‌ಗಳಿಗೆ ಸಾಕಷ್ಟು. ಇ-ಕಾಮರ್ಸ್‌ ಸೈಟ್‌ಗಳಲ್ಲಿ order loss ಕಡಿಮೆ ಮಾಡಲು frequent backup ಅಥವಾ binlog based recovery ಬೇಕಾಗಬಹುದು.

Disk ಮತ್ತು resources‌ನ್ನು ಮಾನಿಟರ್ ಮಾಡಿ

Disk usage 85-90% ದಾಟಿದಾಗ alert ಅಗತ್ಯ. MySQL temp tables, logs ಮತ್ತು index‌ಗಳಿಗೆ ಖಾಲಿ space ಬೇಕು. CPU, RAM ಮತ್ತು I/O wait time‌ಗಳನ್ನು regular check ಮಾಡಿ. resources‌ limitation‌ಗೆ ಸೈಟ್‌ repeatedly ಬಿದ್ದರೆ, data errors‌ಗೆ susceptibility ಹೆಚ್ಚುತ್ತದೆ. traffic‌ ಜಾಸ್ತಿ ಆಗಿದ್ದರೆ shared‌ package‌ದಿಂದ upgrade‌ ಮಾಡುವುದು ಸೂಕ್ತ; ಕೋಷ್ಟಕ ಹೋಸ್ಟಿಂಗ್ ಅಥವಾ ಅತಿದೊಡ್ಡ ಕಾರ್ಯಕ್ಷಮತೆಯ ಹೋಸ್ಟಿಂಗ್ ನೋಡಿ.

ಪ್ಲಗಿನ್, ಥೀಮ್ ಮತ್ತು ಸಾಫ್ಟ್ವೇರ್ update‌ಗಳು

ಹಳೆಯ ಸಾಫ್ಟ್ವೇರ್‌ಗಳೇ ಕೇವಲ security vulnerability ಅಲ್ಲ; inefficient queries‌ಗೆ ಕಾರಣ. WordPress‌ ನಲ್ಲಿ maintenance‌ ಸಮಯ unused plugins‌ remove ಮಾಡಿ, log tables‌ clean ಮಾಡಿ ಮತ್ತು unreliable plugins‌ನ್ನು ತಪ್ಪಿಸಿ. updates‌ ಮಾಡುವ ಮೊದಲು staging‌ನಲ್ಲಿ teste ಮಾಡಿ, live site‌ನಲ್ಲಿ unexpected table/index error‌ಗಳು ತಡೆಯಬಹುದು.

Server‌ನ್ನು ಸರಿಯಾಗಿ shutdown ಮಾಡಿ ಮತ್ತು maintenance plan‌ ಮಾಡಿ

VPS ಅಥವಾ dedicated server‌ನ್ನು ನಿರ್ವಹಿಸುತ್ತಿದ್ದರೆ MySQL service‌ನ್ನು forcibly kill ಮಾಡುವುದು ತಪ್ಪಿಸಿ. maintenance‌ ಮೊದಲು controlled shutdown, updates‌ low traffic‌ ಸಮಯದಲ್ಲಿ, reboot‌ ನಂತರ logs‌ check ಮಾಡುವುದು ಮುಖ್ಯ. disciplined maintenance‌ plans‌ ಹೆಚ್ಚು traffic‌ ಇರುವ database‌ಗಳಲ್ಲಿ corruption ಅಪಾಯವನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತವೆ.

WordPress‌ ಸೈಟ್‌ಗಳಿಗೆ ವಿಶೇಷ ಸೂಚನೆ

WordPress‌ ಸಾಮಾನ್ಯವಾಗಿ MySQL ದೋಷಗಳನ್ನು veritabanı bağlantısı kurulurken hata oluştu ಎಂಬ generic message ಮೂಲಕ ತೋರಿಸುತ್ತದೆ. ಆದರೆ error logs‌ನಲ್ಲಿ corrupt table‌ detail‌ಗಳು ಕಾಣಬಹುದು. WordPress‌ನಲ್ಲಿ ಸಾಮಾನ್ಯವಾಗಿ ಹಾಳಾಗುವ ಟೇಬಲ್‌ಗಳು wp_options, wp_posts, wp_postmeta, wp_comments ಮತ್ತು plugins‌ನ log/scheduler tables‌ ಆಗಿವೆ. wp_options ಹಾಳಾಗಿದ್ರೆ site settings‌ ಓದಲು ಸಾಧ್ಯವಿಲ್ಲ; wp_posts ಹಾಳಾಗಿದ್ರೆ content‌ list ಆಗುವುದಿಲ್ಲ; plugin log tables‌ ಹಾಳಾಗಿದ್ರೆ admin panel‌ slow ಆಗಬಹುದು.

WordPress‌ನಲ್ಲಿ built-in database repair feature ಇದೆ. wp-config.php‌ನಲ್ಲಿ define('WP_ALLOW_REPAIR', true); ಸೇರಿಸಿ, ನಂತರ /wp-admin/maint/repair.php‌ಗೆ ಹೋಗಿ repair‌ ಕಾರ್ಯ ನಡೆಸಬಹುದು. ಆದರೆ repair‌ ಮುಗಿದ ನಂತರ ಈ line‌ remove ಮಾಡಬೇಕು; ಇಲ್ಲವಾದರೆ repair page‌ anyone‌ access ಮಾಡಬಹುದು. phpMyAdmin ವಿಧಾನ ಹೆಚ್ಚು safe; ಯಾವ table‌ಗೆ repair ಮಾಡುತ್ತಿರುವುದು ಸ್ಪಷ್ಟ. WordPress‌ ಪ್ರಾಜೆಕ್ಟ್‌ಗಳಿಗೆ optimized infra ಬೇಕಾದರೆ WordPress ಹೋಸಟಿಂಗ್ ನೋಡಿ.

ಯಾವಾಗ professional support‌ ಬೇಕು?

ಪ್ರತಿ MySQL ದೋಷವನ್ನು ಸ್ವತಃ ಪರಿಹರಿಸೋದು ಸರಳವಲ್ಲ. ಕೆಳಗಿನ ಪರಿಸ್ಥಿತಿಗಳಲ್ಲಿ professional support‌ ಹೆಚ್ಚು safe:

• Corrupt table order, payment, membership ಅಥವಾ finance data ಹೊಂದಿದ್ದರೆ.
• Repair ಪ್ರಯತ್ನ ನಂತರ error ಮುಂದುವರೆದರೆ ಅಥವಾ table‌ visibility‌ ಇಲ್ಲದಿದ್ದರೆ.
• Database size ಹಲವು GB‌ ಇದ್ದರೆ ಮತ್ತು phpMyAdmin timeout ಆಗುತ್ತಿರದೆ.
• InnoDB tablespace ಅಥವಾ redo log errors‌ ಇದ್ದರೆ.
• Disk error, I/O error ಅಥವಾ file system warning ಇದ್ದರೆ.
• Latest clean backup‌ ಇಲ್ಲದಿದ್ದರೆ.

Support ticket‌ submit ಮಾಡುವಾಗ error message, affected database/table name, error‌ ಆರಂಭವಾದ ಸಮಯ, recent update/migration ಮತ್ತು backup date‌ ಕೊಡಬೇಕು. Info‌ ನೀಡಿದರೆ solution‌ ಹೆಚ್ಚು ವೆಗವಾಗಿ ಬರುತ್ತದೆ.

Quick checklist

ಅಪಾಯದ ಸಂದರ್ಭದಲ್ಲಿ ಈ ಕ್ರಮ ಅನುಸರಿಸಿ:

• Error message ಮೂಲಕ corrupt table ಗುರುತಿಸಿ.
• Current database backup‌ export ಮಾಡಿ.
• Site‌ maintenance mode‌ಗೆ ಹಾಕಿ.
• phpMyAdmin‌ನಲ್ಲಿ correct database‌ select ಮಾಡಿ.
• Relevant table‌ select ಮಾಡಿ, repair ಕಾರ್ಯ ನಡೆಸಿ.
• Table check ಮಾಡಿ ಮತ್ತು site‌ test ಮಾಡಿ.
• Disk, resource, backup ಮತ್ತು table engine‌ಗಳ ಮೂಲಕ recurrence‌ ಅನ್ನು ತಡೆಯಿರಿ.

ಪ್ರಶ್ನೆಗಳು & ಉತ್ತರಗಳು

MySQL Table is marked as crashed ದೋಷ data loss ಆಗುತ್ತಾ?

ಯಾವಾಗಲೂ data loss ಆಗುವುದಿಲ್ಲ. ಬಹುಮಟ್ಟಿಗೆ MyISAM tables‌ phpMyAdmin repair‌ ಮೂಲಕ restore ಮಾಡಬಹುದು. ಆದರೆ severe corruption ಇದ್ದರೆ records ಹಾನಿಯಾಗಬಹುದು. ಹೀಗಾಗಿ repair‌ ಮೊದಲು backup‌ ತೆಗೆದುಕೊಳ್ಳುವುದು ಮುಖ್ಯ.

phpMyAdmin ಮೂಲಕ table repair‌ safe ಆಗಿದೆನಾ?

ಸಾಮಾನ್ಯವಾಗಿ safe; ಆದರೆ live database‌ನಲ್ಲಿ maintenance‌ risk ಇದೆ. repair‌ ಮೊದಲು backup, correct table select ಮತ್ತು site‌ maintenance mode‌ safe. ದೊಡ್ಡ ಅಥವಾ critical tables‌ಗೆ professional support‌ ಉತ್ತಮ.

InnoDB tables‌ಗೆ repair‌ ಪ್ರಯೋಗಿಸಬಹುದಾ?

InnoDB tables‌ traditional REPAIR TABLE‌ ಮೂಲಕ repair ಆಗುವುದಿಲ್ಲ. InnoDB errors‌ನಲ್ಲಿ MySQL logs‌ check, disk‌ inspect ಮತ್ತು backup‌ restore‌ ಹೆಚ್ಚಿನ safe. random repair‌ data loss ಅಪಾಯ ಹೆಚ್ಚಿಸುತ್ತದೆ.

ಈ ದೋಷ ಯಾಕೆ ಪುನಃ ಪುನಃ ಬರುತ್ತದೆ?

Recurring error‌ underlying cause‌ unresolved. disk‌ fullness, abrupt shutdowns, heavy write traffic, bad plugins, old MySQL version ಅಥವಾ MyISAM continued usage‌ ಸಾಮಾನ್ಯ root causes. root cause‌ solution‌ permanent fix‌ಗೆ ಅಗತ್ಯ.

Repair‌ ಮಾಡುವ ಮೊದಲು hosting‌ support‌ ಸಂಪರ್ಕಿಸಬೇಕಾ?

Simple MyISAM table‌ errors‌ backup ತೆಗೆದು phpMyAdmin repair‌ ಮಾಡಬಹುದು. ಆದರೆ table‌ critical data‌ ಹೊಂದಿದ್ದರೆ, backup ಇಲ್ಲದಿದ್ದರೆ, database ದೊಡ್ಡದಿದ್ದರೆ ಅಥವಾ InnoDB errors‌ ಇದ್ದರೆ hosting support‌ safe.

ನಿರ್ಣಯ

MySQL "Table is marked as crashed" ದೋಷ ವಿಶೇಷವಾಗಿ MyISAM tables‌ನಲ್ಲಿ ಕಾಣುವ ಮತ್ತು ಹೆಚ್ಚಿನ ಸಂದರ್ಭಗಳಲ್ಲಿ phpMyAdmin ಮೂಲಕ ಪರಿಹರಿಸಬಹುದಾದ database corruption warning. ಸರಿಯಾದ ವಿಧಾನ ಎಂದರೆ ಮೊದಲು backup‌ export ಮಾಡುವುದು, corrupt table‌ ಗುರುತಿಸುವುದು, phpMyAdmin‌ನಲ್ಲಿ repair‌ ನಡೆಸುವುದು ಮತ್ತು root cause‌ fix ಮಾಡುವುದು. regular backup, adequate server resources, InnoDB usage ಮತ್ತು updated software infra‌ ಈ ದೋಷ ಪುನಃ ಬರದಂತೆ ತಡೆಯುತ್ತದೆ. ನಿಮ್ಮ ಸೈಟ್‌ನಲ್ಲಿ ಇಂತಹ errors‌ ಪುನಃಪುನಃ ಬರುತ್ತಿದ್ದರೆ infra‌ review ಮಾಡಿ, ಹೋಸ್ಟಿಂಗ್‌ ಪರಿಹಾರಗಳನ್ನು Hostragons kaynakları ಮೂಲಕ ಪರಿಶೀಲಿಸಿ ಅಥವಾ support‌ guidance‌ ಪಡೆದುಕೊಳ್ಳಿ.