Chào mn, em là code c#, dân ngoại đạo cũng có hiểu biết 1 chút về server. Em có đọc qua một số bài viết về cấu trúc server master slave. Theo em hiểu là có 1 con master, 1 con slave con slave sẽ lắng nghe log từ con master để cập nhật vào db. Có 1 số câu hỏi thắc mắc mong đc các bác giải đáp a. 1. Độ trễ giữa khi sync sang con slave liệu khoảng bn? Nếu em dùng con master để ghi, con slave để đọc thì dữ liệu lấy từ slave có thể k đc mới nhất đúng k ạ 2. Nếu con master có vấn đề, thì dùng con slave để chạy thay thế. Sau đó cài lại hoặc fix con master, backup data import sang master => Vấn đề khi backup là phải off hẳn slave, ko cho write để đảm bảo dữ liệu k bị lỗi trong quá trình backup, data của cty em khá nặng khoảng 100gb, backup rất mất nhiều thời gian. => TH vẫn bị ảnh hưởng đến user đồng bộ data rất nhiều và bên em k muốn như thế. Theo em hiểu là như vậy. Mong đc giải đáp. Thank các bác nhiều.
Em có thể dùng Master to master. Nhưng giải pháp MySQL Cluster sẽ là tốt nhất. Search trên google sẽ cho e kết quả.
100G thì dùng mysqldump chắc backup mất 5s giây chứ mấy :/ data mình 50TB mà backup cũng xíu là xong à
Mình vừa search ra bài viết này dựa trên từ khóa "cấu trúc server master slave" của bạn thì ra bài viết sau để trả lời câu hỏi của bạn Code: https://kipalog.com/posts/Master---Slave--Giai-phap-giam-tai-request--an-toan-du-lieu-mysql 1/ Độ trễ đó sẽ phụ thuộc vào cấu hình delay giữa các lần đọc log của slave. Thiết lặp phần này mình nghĩ bạn có thể test hoặc thử tìm hiểu thêm cách câu hình. Nếu slave để đọc thì chắc chắn không mới nhất rồi, nhưng cũng không đến nỗi nào nếu delay giữa các lần đọc log ngắn (5' chẳng hạn). Nhưng tại sao lại làm như vậy nhỉ replication chỉ là phương án dự backup cho trường hợp 1 trong 2 server bị lỗi, mà xác suất là giờ đây là 50% rồi thì nên đọc và ghi trên master luôn đi. 2/ Trường hợp có vấn đề xảy ra: 2.1/ Master die: Thì slave sẽ chạy chính, cấu hình chuyển thanh master và 1 con khác vào thay thế. Sẽ không có dữ liệu nào bị sót hết vì nó đọc log của master nên sẽ có hết dữ liệu từ master lúc trút hơi thở cuối cùng. 2.2/ Slaver die: Die thì nhét thằng khác vào thay vị trí slave là xong. Nếu log đã bị xóa rồi thì backup từ master sang slave, và nó tiếp tục công việc đọc log của master. Dùng mysqldump thì không cần phải turn off con nào cả. Trừ khi ngay từ đầu đã không cấu hình "tự động bàn giao nhiệm vụ cho slave khi master die", và trường hợp khi cấu hình tay bắt buộc phải restart lại mysql thì nó mysql chỉ die tạm thời trong quá trình restart service. --- Double Post Merged, Jun 23, 2021, Original Post Date: Jun 23, 2021 --- À, nếu 100GB mà bác sợ server treo thì có thể dump ra theo từng table, table nào mấy chục triệu rows thì backup nó vài triệu mỗi lần cho nhẹ.
Cái này phụ thuộc vào máy chủ e nhé. Máy chủ 500$ nó sẽ khác bọt nhiều đó. Và máy chủ đó chỉ có 1 nhiệm vụ là cài mysql thôi.
Thank anh, em sẽ nghiên cứu thêm --- Double Post Merged, Jun 23, 2021, Original Post Date: Jun 23, 2021 --- Thank bác đã thông não. em sẽ cài thử test trực tiếp các th xem kq thế nào. Một lần nữa cảm ơn bác nhiều.
chip mạnh cũng đâu thể vượt được tốc độ đọc-ghi của ssd, tốc độ nhanh nhất hiện tại cũng chỉ tầm 4Gb, đó là lý tưởng thôi.
Theo kinh nghiệm của tớ vài lần deloy Master/Slaver cho mysql thì thấy rất không ổn. Thi thoảng có vấn đề trục trặc giữa Master/Slaver dẫn đến tình trạng data mất đồng bộ rất khó fix - hầu như trên slaver phải xóa đi import lại. Theo mình chỉ nên dùng mô hình này để backup data thì hợp hơn. Master/Master còn rắc rối hơn nữa.
