2008-11-28 13 views
11

Đây là kịch bản. 2 máy chủ web ở hai vị trí riêng biệt có hai cơ sở dữ liệu mysql với các bảng giống hệt nhau. Dữ liệu trong các bảng cũng được dự kiến ​​là giống hệt nhau trong thời gian thực.Cách tốt nhất để đồng bộ hóa hai chiều dữ liệu động trong thời gian thực bằng cách sử dụng mysql

Đây là vấn đề. nếu người dùng ở một trong hai vị trí đồng thời nhập một bản ghi mới vào các bảng giống nhau, như được minh họa trong hai bảng đầu tiên bên dưới, trong đó bản ghi thứ ba trong mỗi bảng đã được nhập đồng thời bởi những người khác nhau. Dữ liệu trong các bảng không còn giống nhau nữa. Cách tốt nhất để duy trì rằng dữ liệu vẫn giống hệt nhau trong thời gian thực như được minh họa trong bảng thứ ba bên dưới bất kể bản cập nhật diễn ra ở đâu? Bằng cách đó trong hình minh họa bên dưới thay vì kết thúc với 3 hàng trong mỗi bảng, các bản ghi mới được nhân bản hai chiều và chúng được chèn vào cả hai bảng để tạo 2 bảng giống hệt nhau với 4 cột lần này?

Server A in Location A 
============== 

Table Names 
| ID| NAME | 
|-----------| 
| 1 | Tom | 
| 2 | Scott | 
|-----------| 
| 3 | John | 
|-----------| 

Server B in Location B 
============== 
Table Names 
| ID| NAME | 
|-----------| 
| 1 | Tom | 
| 2 | Scott | 
|-----------| 
| 3 | Peter | 
|-----------| 


Expected Scenario 
=========== 
Table Names 
| ID| NAME | 
|-----------| 
| 1 | Tom | 
| 2 | Scott | 
| 3 | Peter | 
| 4 | John | 
|-----------| 

Trả lời

11

Không có nhiều hiệu suất để đạt được từ việc sao chép cơ sở dữ liệu của bạn trên hai chủ. Tuy nhiên có một chút hư hỏng của chuyển đổi dự phòng nếu bạn mã ứng dụng của bạn chính xác.

Thiết lập Master-Master cơ bản giống như thiết lập Slave-Master, nhưng có cả Slaves bắt đầu và thay đổi quan trọng đối với tệp cấu hình của bạn trên mỗi hộp.

Thạc sĩ MySQL 1:

auto_increment_increment = 2 
auto_increment_offset = 1 

Thạc sĩ MySQL 2:

auto_increment_increment = 2 
auto_increment_offset = 2 

Hai thông số đảm bảo rằng khi hai máy chủ đang chiến đấu trên một khóa chính đối với một số lý do, họ không lặp lại và giết nhân rộng. Thay vì tăng thêm 1, bất kỳ trường tự động tăng nào theo mặc định sẽ tăng thêm 2. Trên một hộp, nó sẽ bắt đầu được bù trừ từ 1 và chạy chuỗi 1 3 5 7 9 11 13 vv. Trên hộp thứ hai, nó sẽ bắt đầu bù trừ ở 2 và chạy dọc theo 2 4 6 8 10 12 vv Từ thử nghiệm hiện tại, tăng tự động xuất hiện để lấy số miễn phí tiếp theo, không phải số còn lại trước đó. Ví dụ.Nếu máy chủ 1 chèn 3 bản ghi đầu tiên (1 3 và 5), khi Máy chủ 2 chèn số thứ tư, nó sẽ được cung cấp khóa 6 (không phải 2, không được sử dụng).

Khi bạn đã thiết lập điều đó, hãy khởi động cả hai thiết bị đó dưới dạng Slaves. Sau đó, để kiểm tra cả hai đang hoạt động ok, kết nối với cả hai máy và thực hiện lệnh SHOW SLAVE STATUS và bạn nên lưu ý rằng cả hai Slave_IO_RunningSlave_SQL_Running cả hai đều phải nói “CÓ” trên mỗi hộp.

Sau đó, tất nhiên, tạo một vài bản ghi trong bảng và đảm bảo một hộp chỉ chèn các khóa chính được đánh số lẻ và số còn lại chỉ tăng số chẵn.

Sau đó thực hiện tất cả các thử nghiệm để đảm bảo rằng bạn có thể thực hiện tất cả các ứng dụng tiêu chuẩn trên mỗi hộp với nó sao chép sang hộp kia.

Nó tương đối đơn giản khi nó diễn ra. Nhưng như đã được đề cập, MySQL không khuyến khích nó và khuyên bạn nên đảm bảo rằng bạn quan tâm đến chức năng này khi viết mã ứng dụng của bạn.

Chỉnh sửa: Tôi cho rằng về mặt lý thuyết có thể thêm nhiều bậc thầy hơn nếu bạn đảm bảo rằng các khoảng bù là chính xác và cứ như vậy. Bạn có thể thực tế hơn, thêm một số nô lệ bổ sung.

+0

Đối với dự phòng, hai chủ nhân phải là đủ. Để cân bằng tải, thì có thể sử dụng các thiết lập master-slave riêng lẻ trên cả hai vị trí. Nhưng sử dụng một tổng thể với một nô lệ bên ngoài, mà bạn có thể tự chuyển sang trong trường hợp thất bại, là một lựa chọn khác. – jishi

+0

cũng có, đảm bảo các máy chủ có giá trị khác nhau cho server-id và lặp-cùng-server-id được thiết lập mặc định của nó là 0. Điều này có thể có mặt ở đó đã có, nhưng nó sẽ lặp và gặp lỗi nếu không. – benlumley

+0

tôi thích ý tưởng có các máy chủ tự động tăng thêm 2 sau đó viết một plugin tùy chỉnh để theo dõi chèn/chỉnh sửa và plugin sẽ xử lý phần còn lại. vì vậy nếu máy chủ 1 chèn (1,3,5) các plugin có thể chọn nó và xuất khẩu sang máy chủ 2 bằng cách sử dụng cùng một id & ngược lại do đó không có xung đột. –

0

Cách duy nhất để đảm bảo bảng của bạn được đồng bộ hóa là thiết lập bản sao 2 chiều giữa các cơ sở dữ liệu.

Nhưng, MySQL chỉ cho phép sao chép một chiều, vì vậy bạn không thể chỉ giải quyết vấn đề của mình trong cấu hình này.

Để rõ ràng, bạn có thể "thiết lập" bản sao 2 chiều nhưng MySQL AB discourages this.

1

Điều quan trọng là các UID đều giống nhau không? Hoặc bạn có thể giải trí về việc có một bảng hoặc cột ánh xạ UID từ xa đến UID cục bộ và viết mã đồng bộ tùy chỉnh cho các đối tượng mà bạn muốn sao chép trên đó không cần ánh xạ UID cần thiết cho các cột khóa ngoài không?

+0

Có, điều quan trọng là UID giống nhau trên cả hai máy chủ. họ không phải làm theo trình tự mặc dù, họ chỉ cần được tương tự và duy nhất trong cả hai máy chủ. Dù sao cũng cảm ơn bạn. tôi có một ý tưởng khá hay về những gì tôi sẽ làm. –

2

MySQL không hỗ trợ sao chép đồng bộ, tuy nhiên, thậm chí nếu có, bạn có thể không muốn sử dụng nó (không thể thực hiện lần truy cập chờ đợi cho máy chủ khác đồng bộ hóa trên mọi giao dịch).

Bạn sẽ phải xem xét các giải pháp kiến ​​trúc phù hợp hơn - có các sản phẩm của bên thứ ba sẽ hợp nhất và giải quyết xung đột theo cách được xác định trước - đây là cách duy nhất thực sự.

Mong kiến ​​trúc của bạn hoạt động theo cách này là ngây thơ - không có "sửa lỗi dễ dàng" cho bất kỳ cơ sở dữ liệu nào, không chỉ MySQL.

+0

nó không chờ đợi như bạn mô tả - như trên, thực sự hai trường hợp chủ nô lệ của nó – benlumley

+0

Tôi có nghĩa là trong tình huống giả định, nơi MySQL hỗ trợ nhân rộng đồng bộ. – MarkR

Các vấn đề liên quan