Không có câu trả lời nào ở đây giúp tôi, nhưng cuối cùng tôi đã có MySQL 5.6 để hoạt động.
BA tùy chọn để sửa lỗi MySQL 5.6:
-
(đã xác nhận) Chỉnh sửa
/etc/my.cnf(tạo nếu không tồn tại) và thêm:[mysqld] innodb_file_per_table = OFF
và khởi động lại MySQL. Sau đó, để điều này hoạt động, bạn sẽ cần phải kết xuất cơ sở dữ liệu của mình vào tệp SQL (mysqldump), sau đó thả và tạo lại cơ sở dữ liệu, sau đó tải lại dữ liệu.
-
Thay đổi giá trị ulimit mặc định của OSX (do người dùng Github đề xuất sodabrew ): https://superuser.com/questions/261023/how-to-change-default-ulimit-values-in-mac-os-x-10-6
-
Thêm tùy chọn sau vào phần [mysqld] của my.cnf:
table_open_cache = 250. Theo mặc định, nó được đặt thành 2000, cao hơn ulimit mặc định của OSX. Giải pháp này cũng không được khuyến khích, vì nó làm ảnh hưởng đến hiệu suất của MySQL của bạn - nó buộc MySQL phải mở lại các bảng thường xuyên, nếu bạn có hơn 250 bảng:https://mariadb.com/kb/en/optimizing-table_open_cache/
Tại sao lỗi này lại xảy ra?
Vì tùy chọn MySQL 5.6 innodb_file_per_table được BẬT theo mặc định, có nghĩa là dữ liệu của mỗi bảng được lưu trữ trong tệp riêng của nó. Giới hạn mặc định của OSX về số lượng tệp đang mở là 256 cho mỗi quá trình. Thông thường đây không phải là vấn đề, nhưng trong trường hợp của tôi, tôi đang chạy các bài kiểm tra đơn vị song song, tạo 8 cơ sở dữ liệu với 405 bảng mỗi cơ sở. OSX có giới hạn về số lần xử lý tệp đang mở trên mỗi quá trình. Câu trả lời StackOverflow này gợi ý rằng giới hạn này là 256, điều này giải thích hoàn hảo cho vấn đề của tôi:trước MySQL 5.6, tất cả dữ liệu từ tất cả 8 cơ sở dữ liệu này đều nằm trong MỘT tệp.
Cảm ơn đồng nghiệp của tôi Thomas L., người đã tìm thấy báo cáo lỗi MySQL gợi ý giải pháp này!
