Mysql
 sql >> Cơ Sở Dữ Liệu >  >> RDS >> Mysql

Các phương pháp hay nhất về sao chép MySQL

MySQL Replication là giải pháp phổ biến nhất và được sử dụng rộng rãi với tính khả dụng cao của các tổ chức lớn như Github, Twitter và Facebook. Mặc dù dễ thiết lập nhưng có những thách thức phải đối mặt khi sử dụng giải pháp này từ bảo trì, bao gồm nâng cấp phần mềm, dữ liệu trôi dạt hoặc không nhất quán dữ liệu trên các nút bản sao, thay đổi cấu trúc liên kết, chuyển đổi dự phòng và phục hồi. Khi MySQL phát hành phiên bản 5.6, nó đã mang lại một số cải tiến đáng kể, đặc biệt là nhân rộng bao gồm ID giao dịch toàn cầu (GTID), tổng kiểm tra sự kiện, nô lệ đa luồng và nô lệ / chủ an toàn cho sự cố. Nhân rộng thậm chí còn tốt hơn với MySQL 5.7 và MySQL 8.0.

Replication cho phép dữ liệu từ một máy chủ MySQL (máy chủ / chính) được sao chép sang một hoặc nhiều máy chủ MySQL (bản sao / nô lệ). MySQL Replication rất dễ thiết lập và được sử dụng để mở rộng khối lượng công việc đã đọc, cung cấp tính khả dụng cao và dự phòng về địa lý, đồng thời giảm tải các bản sao lưu và công việc phân tích.

Bản sao MySQL trong Bản chất

Chúng ta hãy có một cái nhìn tổng quan nhanh về cách MySQL Replication hoạt động trong tự nhiên. MySQL Replication rất rộng và có nhiều cách để cấu hình nó cũng như cách sử dụng nó. Theo mặc định, nó sử dụng sao chép không đồng bộ, hoạt động khi giao dịch được hoàn thành trong môi trường cục bộ. Không có gì đảm bảo rằng bất kỳ sự kiện nào sẽ đến tay bất kỳ nô lệ nào. Đó là một mối quan hệ chủ tớ được kết hợp lỏng lẻo, trong đó:

  • Chính không đợi bản sao.

  • Bản sao xác định số lượng cần đọc và từ thời điểm nào trong nhật ký nhị phân.

  • Bản sao có thể tùy ý phía sau bản gốc trong việc đọc hoặc áp dụng các thay đổi.

Nếu lỗi chính gặp sự cố, các giao dịch mà nó đã cam kết có thể không được truyền tới bất kỳ bản sao nào. Do đó, chuyển đổi dự phòng từ bản sao chính sang bản sao nâng cao nhất, trong trường hợp này, có thể dẫn đến chuyển đổi dự phòng sang bản sao chính mong muốn thực sự bị thiếu các giao dịch liên quan đến máy chủ trước đó.

Sao chép không đồng bộ cung cấp độ trễ ghi thấp hơn vì một bản ghi được thừa nhận cục bộ bởi trình chủ trước khi được ghi cho nô lệ. Nó rất tốt cho việc mở rộng quy mô đọc vì việc thêm nhiều bản sao hơn không ảnh hưởng đến độ trễ sao chép. Các trường hợp sử dụng tốt cho sao chép không đồng bộ bao gồm triển khai các bản sao đọc để mở rộng quy mô đọc, sao lưu trực tiếp để khôi phục thảm họa và phân tích / báo cáo.

Sao chép bán đồng bộ MySQL

MySQL cũng hỗ trợ sao chép bán đồng bộ, trong đó máy chủ không xác nhận các giao dịch với máy khách cho đến khi ít nhất một máy chủ đã sao chép thay đổi vào nhật ký chuyển tiếp của nó và chuyển nó vào đĩa. Để kích hoạt sao chép bán đồng bộ, cần có các bước bổ sung để cài đặt plugin và phải được bật trên các nút chính và nút phụ của MySQL được chỉ định.

Bán đồng bộ có vẻ là một giải pháp tốt và thiết thực cho nhiều trường hợp khi tính sẵn sàng cao và không mất dữ liệu là quan trọng. Nhưng bạn nên xem xét rằng bán đồng bộ có tác động đến hiệu suất do chu trình vòng bổ sung và không cung cấp đảm bảo chắc chắn chống mất dữ liệu. Khi một cam kết trả về thành công, người ta biết rằng dữ liệu tồn tại ở ít nhất hai nơi (trên chính và ít nhất một phụ). Nếu master cam kết nhưng sự cố xảy ra trong khi master đang chờ xác nhận từ một nô lệ, thì có thể giao dịch đó chưa đến được với bất kỳ nô lệ nào. Đây không phải là vấn đề lớn vì cam kết sẽ không được trả lại ứng dụng trong trường hợp này. Nhiệm vụ của ứng dụng là thử lại giao dịch trong tương lai. Điều cần thiết cần ghi nhớ là khi chủ không thành công và một nô lệ đã được thăng cấp, thì chủ cũ không thể tham gia chuỗi sao chép. Trong một số trường hợp, điều này có thể dẫn đến xung đột với dữ liệu trên các nô lệ, tức là khi chủ gặp sự cố sau khi nô lệ nhận được sự kiện nhật ký nhị phân nhưng trước khi chủ nhận được xác nhận từ nô lệ). Do đó, cách an toàn duy nhất là loại bỏ dữ liệu trên trang cái cũ và cung cấp nó từ đầu bằng cách sử dụng dữ liệu từ trang cái mới được thăng cấp.

Sử dụng Định dạng Sao chép Không chính xác

Kể từ MySQL 5.7.7, định dạng nhật ký nhị phân mặc định hoặc biến binlog_format sử dụng ROW, là STATEMENT trước 5.7.7. Các định dạng sao chép khác nhau tương ứng với phương pháp được sử dụng để ghi lại các sự kiện nhật ký nhị phân của nguồn. Bản sao hoạt động vì các sự kiện được ghi vào nhật ký nhị phân được đọc từ nguồn và sau đó được xử lý trên bản sao. Các sự kiện được ghi lại trong bản ghi nhị phân ở các định dạng sao chép khác nhau tùy theo loại sự kiện. Không biết chắc chắn những gì để sử dụng có thể là một vấn đề. MySQL có ba định dạng của các phương thức sao chép:STATEMENT, ROW và MIXED.

  • Định dạng sao chép dựa trên STATEMENT (SBR) chính xác là nó – một dòng sao chép của mỗi lần chạy câu lệnh trên cái chính sẽ được phát lại trên nút phụ. Theo mặc định, bản sao truyền thống (không đồng bộ) của MySQL không thực hiện song song các giao dịch được sao chép tới các nô lệ. Điều đó có nghĩa là thứ tự của các câu lệnh trong luồng sao chép có thể không giống nhau 100%. Ngoài ra, việc phát lại một câu lệnh có thể cho các kết quả khác nhau khi không được thực thi cùng lúc với khi được thực thi từ nguồn. Điều này dẫn đến trạng thái không nhất quán so với bản chính và (các) bản sao của nó. Đây không phải là vấn đề trong nhiều năm, vì không nhiều người chạy MySQL với nhiều luồng đồng thời. Tuy nhiên, với kiến ​​trúc đa CPU hiện đại, điều này thực sự có thể xảy ra với khối lượng công việc bình thường hàng ngày.

  • Định dạng sao chép ROW cung cấp các giải pháp mà SBR thiếu. Khi sử dụng định dạng ghi nhật ký sao chép dựa trên hàng (RBR), nguồn sẽ ghi các sự kiện vào nhật ký nhị phân cho biết các hàng trong bảng riêng lẻ được thay đổi như thế nào. Sao chép từ nguồn sang bản sao hoạt động bằng cách sao chép các sự kiện đại diện cho các thay đổi đối với các hàng trong bảng sang bản sao. Điều này có nghĩa là có thể tạo ra nhiều dữ liệu hơn, ảnh hưởng đến không gian đĩa trong bản sao và ảnh hưởng đến lưu lượng mạng và I / O đĩa. Hãy xem xét nếu một câu lệnh thay đổi nhiều hàng, giả sử với câu lệnh CẬP NHẬT, RBR ghi nhiều dữ liệu hơn vào nhật ký nhị phân ngay cả đối với các câu lệnh được cuộn lại. Việc chạy ảnh chụp nhanh theo thời gian cũng có thể mất nhiều thời gian hơn. Các vấn đề về tiền tệ tương đồng có thể xảy ra với thời gian khóa cần thiết để ghi nhiều khối dữ liệu vào nhật ký nhị phân.

  • Sau đó, có một phương thức ở giữa hai phương thức này; sao chép chế độ hỗn hợp. Loại sao chép này sẽ luôn sao chép các câu lệnh, ngoại trừ khi truy vấn chứa hàm UUID (), trình kích hoạt, thủ tục được lưu trữ, UDF và một số ngoại lệ khác. Chế độ hỗn hợp sẽ không giải quyết được vấn đề trôi dạt dữ liệu và nên tránh việc sao chép dựa trên câu lệnh.

Có kế hoạch thiết lập nhiều thiết bị?

Round Replication (còn được gọi là cấu trúc liên kết vòng) là một thiết lập đã biết và phổ biến cho bản sao MySQL. Nó được sử dụng để chạy thiết lập đa tổng thể (xem hình ảnh bên dưới) và thường cần thiết nếu bạn có môi trường nhiều trung tâm dữ liệu. Vì ứng dụng không thể đợi bản chính trong trung tâm dữ liệu khác xác nhận việc ghi, nên ưu tiên ứng dụng chính cục bộ. Thông thường, độ lệch tăng tự động được sử dụng để ngăn chặn xung đột dữ liệu giữa các bản gốc. Việc để hai bậc thầy thực hiện ghi cho nhau theo cách này là một giải pháp được chấp nhận rộng rãi.

Tuy nhiên, nếu bạn cần ghi nhiều trung tâm dữ liệu vào cùng một cơ sở dữ liệu , bạn sẽ có nhiều trang cái cần ghi dữ liệu của chúng cho nhau. Trước MySQL 5.7.6, không có phương pháp nào để thực hiện sao chép kiểu lưới, vì vậy giải pháp thay thế sẽ là sử dụng sao chép vòng tròn thay thế.

Sao chép vòng trong MySQL có vấn đề vì các lý do sau:độ trễ, tính khả dụng cao và trôi dạt dữ liệu. Việc ghi một số dữ liệu vào máy chủ A sẽ mất ba bước để kết thúc trên máy chủ D (thông qua máy chủ B và C). Vì sao chép MySQL (truyền thống) là đơn luồng, bất kỳ truy vấn chạy dài nào trong quá trình sao chép có thể làm ngưng trệ toàn bộ vòng lặp. Ngoài ra, nếu bất kỳ máy chủ nào gặp sự cố, vòng đệm sẽ bị hỏng và hiện tại, không có phần mềm chuyển đổi dự phòng nào có thể sửa chữa các cấu trúc vòng. Sau đó, sự trôi dạt dữ liệu có thể xảy ra khi dữ liệu được ghi vào máy chủ A và được thay đổi đồng thời trên máy chủ C hoặc D.

Nói chung, sao chép vòng tròn không phù hợp với MySQL và phải tránh bằng mọi giá. Vì nó được thiết kế với suy nghĩ đó, Galera Cluster sẽ là một giải pháp thay thế tốt cho các bài viết trên nhiều trung tâm dữ liệu.

Ngừng sao chép của bạn với các bản cập nhật lớn

Các công việc hàng loạt khác nhau thường thực hiện nhiều tác vụ khác nhau, từ dọn dẹp dữ liệu cũ đến tính toán mức trung bình của lượt 'thích' được lấy từ một nguồn khác. Điều này có nghĩa là một công việc sẽ tạo ra rất nhiều hoạt động cơ sở dữ liệu tại các khoảng thời gian đã định và rất có thể, ghi rất nhiều dữ liệu trở lại cơ sở dữ liệu. Đương nhiên, điều này có nghĩa là hoạt động trong luồng sao chép sẽ tăng như nhau.

Bản sao dựa trên câu lệnh sẽ sao chép các truy vấn chính xác được sử dụng trong các công việc hàng loạt, vì vậy nếu truy vấn mất nửa giờ để xử lý trên bản chính, thì luồng phụ sẽ bị dừng ít nhất là bằng thời gian. Điều này có nghĩa là không có dữ liệu nào khác có thể sao chép và các nút phụ sẽ bắt đầu tụt hậu so với nút chính. Nếu điều này vượt quá ngưỡng của công cụ chuyển đổi dự phòng hoặc proxy của bạn, nó có thể làm rớt các nút phụ này khỏi các máy chủ có sẵn trong cụm. Nếu bạn đang sử dụng sao chép dựa trên câu lệnh, bạn có thể ngăn chặn điều này bằng cách thu thập dữ liệu cho công việc của mình thành các lô nhỏ hơn.

Bây giờ, bạn có thể nghĩ rằng việc sao chép dựa trên hàng không bị ảnh hưởng bởi điều này, vì nó sẽ sao chép thông tin hàng thay vì truy vấn. Điều này đúng một phần vì đối với các thay đổi DDL, bản sao sẽ quay trở lại định dạng dựa trên câu lệnh. Ngoài ra, số lượng lớn các hoạt động CRUD (Tạo, Đọc, Cập nhật, Xóa) sẽ ảnh hưởng đến luồng sao chép. Trong hầu hết các trường hợp, đây vẫn là một hoạt động đơn luồng và do đó mọi giao dịch sẽ đợi giao dịch trước đó được phát lại thông qua nhân rộng. Điều này có nghĩa là nếu bạn có tính đồng thời cao trên master, thì slave có thể bị đình trệ do quá tải các giao dịch trong quá trình sao chép.

Để giải quyết vấn đề này, cả MariaDB và MySQL đều cung cấp bản sao song song. Việc triển khai có thể khác nhau tùy theo nhà cung cấp và phiên bản. MySQL 5.6 cung cấp sao chép song song miễn là các truy vấn được phân tách bằng lược đồ. MariaDB 10.0 và MySQL 5.7 đều có thể xử lý sao chép song song trên các lược đồ nhưng có các ranh giới khác. Việc thực thi các truy vấn thông qua các chuỗi nô lệ song song có thể tăng tốc luồng sao chép của bạn nếu bạn đang viết nặng. Nếu không, tốt hơn là nên sử dụng cách sao chép đơn luồng truyền thống.

Xử lý Thay đổi giản đồ hoặc DDL của bạn

Kể từ khi phát hành phiên bản 5.7, việc quản lý thay đổi lược đồ hoặc thay đổi DDL (Ngôn ngữ định nghĩa dữ liệu) trong MySQL đã được cải thiện rất nhiều. Cho đến MySQL 8.0, các thuật toán thay đổi DDL được hỗ trợ là COPY và INPLACE.

  • SAO CHÉP:Thuật toán này tạo một bảng tạm thời mới với lược đồ đã thay đổi. Khi nó di chuyển dữ liệu hoàn toàn sang bảng tạm thời mới, nó sẽ hoán đổi và loại bỏ bảng cũ.

  • INPLACE:Thuật toán này thực hiện các thao tác tại chỗ đối với bảng gốc và tránh sao chép và xây dựng lại bảng bất cứ khi nào có thể.

  • INSTANT:Thuật toán này đã được giới thiệu từ MySQL 8.0 nhưng vẫn còn những hạn chế.

Trong MySQL 8.0, thuật toán INSTANT đã được giới thiệu, thực hiện các thay đổi bảng ngay lập tức và tại chỗ để bổ sung cột và cho phép DML đồng thời với khả năng đáp ứng và tính khả dụng được cải thiện trong môi trường sản xuất bận rộn. Điều này giúp tránh độ trễ và độ trễ lớn trong bản sao thường là những vấn đề lớn trong quan điểm ứng dụng, khiến dữ liệu cũ được truy xuất vì các lần đọc trong máy chủ chưa được cập nhật do độ trễ.

Mặc dù đó là một cải tiến đầy hứa hẹn nhưng chúng vẫn có những hạn chế và đôi khi không thể áp dụng các thuật toán INSTANT và INPLACE đó. Ví dụ, đối với thuật toán INSTANT và INPLACE, việc thay đổi kiểu dữ liệu của cột cũng là một nhiệm vụ DBA thông thường, đặc biệt là trong quan điểm phát triển ứng dụng do thay đổi dữ liệu. Những dịp này là không thể tránh khỏi; do đó, bạn không thể tiếp tục với thuật toán SAO CHÉP vì thuật toán này khóa bảng gây ra sự chậm trễ trong nô lệ. Nó cũng ảnh hưởng đến máy chủ chính / chủ trong quá trình thực thi này vì nó chồng chất các giao dịch đến cũng tham chiếu bảng bị ảnh hưởng. Bạn không thể thực hiện thay đổi ALTER hoặc lược đồ trực tiếp trên một máy chủ bận vì điều này đi kèm với thời gian ngừng hoạt động hoặc có thể làm hỏng cơ sở dữ liệu của bạn nếu bạn mất kiên nhẫn, đặc biệt nếu bảng mục tiêu rất lớn.

Đúng là việc thực hiện các thay đổi lược đồ trên một thiết lập sản xuất đang chạy luôn là một nhiệm vụ đầy thách thức. Một giải pháp thường được sử dụng là áp dụng thay đổi lược đồ cho các nút phụ trước. Điều này hoạt động tốt cho sao chép dựa trên câu lệnh, nhưng điều này chỉ có thể hoạt động ở một mức độ nhất định đối với sao chép dựa trên hàng. Sao chép dựa trên hàng cho phép các cột thừa tồn tại ở cuối bảng, vì vậy, miễn là nó có thể viết các cột đầu tiên là được. Đầu tiên, áp dụng thay đổi cho tất cả các nô lệ, sau đó chuyển đổi dự phòng cho một trong các nô lệ và sau đó áp dụng thay đổi cho chủ và đính kèm thay đổi đó như một nô lệ. Nếu thay đổi của bạn liên quan đến việc chèn một cột ở giữa hoặc xóa một cột, thì điều này sẽ hoạt động với tính năng sao chép dựa trên hàng.

Có các công cụ có thể thực hiện các thay đổi giản đồ trực tuyến một cách đáng tin cậy hơn. Thay đổi lược đồ trực tuyến Percona (được gọi là pt-osc) và gh-ost của Schlomi Noach thường được sử dụng bởi các DBA. Các công cụ này xử lý các thay đổi lược đồ một cách hiệu quả bằng cách nhóm các hàng bị ảnh hưởng thành các phần và các phần này có thể được định cấu hình cho phù hợp tùy thuộc vào số lượng bạn muốn nhóm.

Nếu bạn định sử dụng pt-osc, công cụ này sẽ tạo một bảng bóng với cấu trúc bảng mới, chèn dữ liệu mới thông qua trình kích hoạt và chèn lấp dữ liệu trong nền. Sau khi hoàn tất việc tạo bảng mới, nó sẽ chỉ cần hoán đổi bảng cũ cho bảng mới trong một giao dịch. Điều này không hoạt động trong mọi trường hợp, đặc biệt nếu bảng hiện tại của bạn đã có trình kích hoạt.

Sử dụng gh-ost trước tiên sẽ tạo một bản sao của bố cục bảng hiện có của bạn, thay đổi bảng thành bố cục mới, và sau đó kết nối quy trình như một bản sao MySQL. Nó sẽ sử dụng luồng nhân bản để tìm các hàng mới đã được chèn vào bảng ban đầu và đồng thời, lấp đầy bảng. Sau khi hoàn tất việc lấp đầy, bảng ban đầu và bảng mới sẽ chuyển đổi. Đương nhiên, tất cả các hoạt động đối với bảng mới sẽ kết thúc trong luồng sao chép; do đó, trên mỗi bản sao, việc di chuyển diễn ra đồng thời.

Bảng bộ nhớ và sao chép

Trong khi chúng ta đang nói về chủ đề DDL, một vấn đề phổ biến là việc tạo các bảng bộ nhớ. Bảng bộ nhớ là bảng không liên tục, cấu trúc bảng của chúng vẫn còn, nhưng chúng mất dữ liệu sau khi khởi động lại MySQL. Khi tạo một bảng bộ nhớ mới trên cả master và slave, chúng sẽ có một bảng trống, bảng này hoạt động hoàn toàn tốt. Sau khi một trong hai được khởi động lại, bảng sẽ bị làm trống và lỗi sao chép sẽ xảy ra.

Sao chép dựa trên hàng sẽ bị hỏng khi dữ liệu trong nút phụ trả về các kết quả khác nhau và sao chép dựa trên câu lệnh sẽ bị hỏng khi nó cố gắng chèn dữ liệu đã tồn tại. Đối với bảng bộ nhớ, đây là một bộ ngắt sao chép thường xuyên. Cách khắc phục rất dễ dàng:tạo một bản sao mới của dữ liệu, thay đổi công cụ thành InnoDB và bây giờ nó sẽ an toàn sao chép.

Đặt read_only ={True | 1}

Tất nhiên, đây là trường hợp có thể xảy ra khi bạn đang sử dụng cấu trúc liên kết vòng và chúng tôi không khuyến khích sử dụng cấu trúc liên kết vòng nếu có thể. Chúng tôi đã mô tả trước đó, rằng việc không có cùng dữ liệu trong các nút nô lệ có thể phá vỡ quá trình sao chép. Thông thường, điều này là do một cái gì đó (hoặc ai đó) thay đổi dữ liệu trên nút phụ nhưng không phải trên nút chính. Khi dữ liệu của nút chính bị thay đổi, dữ liệu này sẽ được sao chép sang nút phụ, nơi nó không thể áp dụng thay đổi và điều này khiến quá trình sao chép bị hỏng. Điều này cũng có thể dẫn đến hỏng dữ liệu ở cấp độ cụm, đặc biệt nếu nô lệ đã được thăng cấp hoặc bị lỗi do sự cố. Đó có thể là một thảm họa.

Phòng tránh dễ dàng cho điều này là đảm bảo read_only và super_read_only (chỉ trên> 5.6) được đặt ở ON hoặc 1. Bạn có thể đã hiểu hai biến này khác nhau như thế nào và nó ảnh hưởng như thế nào nếu bạn tắt hoặc bật họ. Với super_read_only (kể từ MySQL 5.7.8) bị vô hiệu hóa, người dùng root có thể ngăn chặn bất kỳ thay đổi nào trong mục tiêu hoặc bản sao. Vì vậy, khi cả hai bị vô hiệu hóa, điều này sẽ không cho phép bất kỳ ai thực hiện thay đổi đối với dữ liệu, ngoại trừ bản sao. Hầu hết các trình quản lý chuyển đổi dự phòng, chẳng hạn như ClusterControl, đặt cờ này tự động để ngăn người dùng ghi vào bản chính đã sử dụng trong quá trình chuyển đổi dự phòng. Một số người trong số họ thậm chí còn giữ lại điều này sau khi chuyển đổi dự phòng.

Bật GTID

Trong sao chép MySQL, bắt đầu nô lệ từ vị trí chính xác trong nhật ký nhị phân là điều cần thiết. Có được vị trí này có thể được thực hiện khi tạo bản sao lưu (xtrabackup và mysqldump hỗ trợ điều này) hoặc khi bạn đã ngừng sử dụng nút mà bạn đang tạo bản sao. Bắt đầu sao chép bằng lệnh CHANGE MASTER TO sẽ trông giống như sau:

mysql> CHANGE MASTER TO MASTER_HOST='x.x.x.x',
MASTER_USER='replication_user', 
MASTER_PASSWORD='password', 
MASTER_LOG_FILE='master-bin.00001', 
MASTER_LOG_POS=4;

Bắt đầu sao chép sai chỗ có thể gây ra hậu quả tai hại:dữ liệu có thể bị ghi kép hoặc không được cập nhật. Điều này gây ra sự chênh lệch dữ liệu giữa nút chính và nút phụ.

Ngoài ra, việc thất bại giữa chủ nhân với nô lệ liên quan đến việc tìm đúng vị trí và thay đổi chủ thành máy chủ thích hợp. MySQL không giữ lại các vị trí và nhật ký nhị phân từ cái chính của nó, mà thay vào đó, tạo các vị trí và nhật ký nhị phân của riêng nó. Điều này có thể trở thành một vấn đề nghiêm trọng đối với việc căn chỉnh lại một nút nô lệ cho nút chính mới. Vị trí chính xác của master khi chuyển đổi dự phòng phải được tìm thấy trên master mới và sau đó tất cả các nô lệ có thể được sắp xếp lại.

Cả Oracle MySQL và MariaDB đều đã triển khai Mã định danh giao dịch toàn cầu (GTID) để giải quyết vấn đề này. GTID cho phép tự động căn chỉnh các nô lệ và máy chủ tự tìm ra vị trí chính xác. Tuy nhiên, cả hai đều triển khai GTID khác nhau và do đó không tương thích. Nếu bạn cần thiết lập sao chép từ cái này sang cái khác, thì việc nhân rộng phải được thiết lập với định vị nhật ký nhị phân truyền thống. Ngoài ra, phần mềm chuyển đổi dự phòng của bạn cần được lưu ý về việc không sử dụng GTID.

Nô lệ an toàn cho sự cố

Crash safe có nghĩa là ngay cả khi MySQL / OS nô lệ gặp sự cố, bạn có thể khôi phục nô lệ và tiếp tục sao chép mà không cần khôi phục cơ sở dữ liệu MySQL trên nô lệ. Để làm cho nô lệ an toàn với sự cố hoạt động, bạn chỉ phải sử dụng công cụ lưu trữ InnoDB và trong 5.6, bạn cần đặt relay_log_info_repository =TABLE và relay_log_recovery =1.

Kết luận

Việc luyện tập thực sự trở nên hoàn hảo, nhưng nếu không được đào tạo thích hợp và có kiến ​​thức về những kỹ thuật quan trọng này, nó có thể gây rắc rối hoặc dẫn đến thảm họa. Các phương pháp này thường được các chuyên gia về MySQL tuân thủ và được các ngành công nghiệp lớn điều chỉnh như một phần công việc hàng ngày của họ khi quản lý Bản sao MySQL trong máy chủ cơ sở dữ liệu sản xuất.

Nếu bạn muốn đọc thêm về MySQL Replication, hãy xem hướng dẫn này về MySQL replication để có tính khả dụng cao.

Để biết thêm thông tin cập nhật về các giải pháp quản lý cơ sở dữ liệu và các phương pháp hay nhất cho cơ sở dữ liệu dựa trên nguồn mở của bạn, hãy theo dõi chúng tôi trên Twitter và LinkedIn và đăng ký nhận bản tin của chúng tôi.


  1. Database
    2.   
  2. Mysql
    3.   
  3. Oracle
    4.   
  4. Sqlserver
    5.   
  5. PostgreSQL
    6.   
  6. Access
    7.   
  7. SQLite
    8.   
  8. MariaDB

  1. Nó có nghĩa là gì để thoát khỏi một chuỗi?

  2. MySQL JDBC Driver 5.1.33 - Sự cố về múi giờ

  3. SUBDATE () so với DATE_SUB () trong MySQL:Sự khác biệt là gì?

  4. Làm cách nào để thay đổi kiểu dữ liệu cho một cột trong MySQL?

  5. PyMySQL không thể kết nối với MySQL trên máy chủ cục bộ