Có an toàn không khi sử dụng innodb_flush_log_at_trx_commit = 2
Câu trả lời:
Bạn có thể mất tới một giây giao dịch. Giá trị mặc định là 1, giúp tuân thủ InnoDB ACID .
Theo Tài liệu MySQL trên innodb_flush_log_at_trx_commit
Nếu giá trị của innodb_flush_log_at_trx_commit là 0, bộ đệm nhật ký được ghi ra tệp nhật ký một lần mỗi giây và thao tác xả vào đĩa được thực hiện trên tệp nhật ký, nhưng không có gì được thực hiện tại một cam kết giao dịch. Khi giá trị là 1 (mặc định), bộ đệm nhật ký được ghi ra tệp nhật ký tại mỗi lần giao dịch và thao tác tuôn ra đĩa được thực hiện trên tệp nhật ký. Khi giá trị là 2, bộ đệm nhật ký được ghi ra tệp tại mỗi lần xác nhận, nhưng thao tác tuôn ra đĩa không được thực hiện trên nó. Tuy nhiên, việc xả vào tệp nhật ký cũng diễn ra một lần mỗi giây khi giá trị là 2. Lưu ý rằng việc xả một lần mỗi giây không được đảm bảo 100% xảy ra mỗi giây, do các vấn đề lập lịch xử lý.
Giá trị mặc định là 1 là bắt buộc để tuân thủ ACID đầy đủ. Bạn có thể đạt được hiệu suất tốt hơn bằng cách đặt giá trị khác với 1, nhưng sau đó bạn có thể mất tối đa một giây giao dịch trong một vụ tai nạn. Với giá trị 0, bất kỳ sự cố quá trình mysqld nào cũng có thể xóa giây cuối cùng của giao dịch. Với giá trị là 2, chỉ một sự cố hệ điều hành hoặc mất điện mới có thể xóa đi giây cuối cùng của giao dịch. Phục hồi sự cố của InnoDB hoạt động bất kể giá trị.
Để có độ bền và tính nhất quán cao nhất có thể trong thiết lập sao chép bằng InnoDB với các giao dịch, hãy sử dụng innodb_flush_log_at_trx_commit = 1 và sync_binlog = 1 trong tệp my.cnf của máy chủ chính của bạn.
Thận trọng
Nhiều hệ điều hành và một số phần cứng đĩa đánh lừa hoạt động tuôn ra đĩa. Họ có thể nói với mysqld rằng việc xả nước đã diễn ra, mặc dù điều đó không xảy ra. Sau đó, độ bền của các giao dịch không được đảm bảo ngay cả với cài đặt 1 và trong trường hợp xấu nhất, mất điện thậm chí có thể làm hỏng cơ sở dữ liệu InnoDB. Sử dụng bộ đệm đĩa được hỗ trợ bằng pin trong bộ điều khiển đĩa SCSI hoặc trong chính đĩa sẽ tăng tốc độ xả tệp và giúp thao tác an toàn hơn. Bạn cũng có thể thử sử dụng lệnh Unix hdparm để vô hiệu hóa bộ nhớ đệm của đĩa ghi trong bộ nhớ cache phần cứng hoặc sử dụng một số lệnh khác dành riêng cho nhà cung cấp phần cứng.
Dựa trên điều này, các giá trị khác 1 khiến InnoDB có nguy cơ mất các giao dịch trị giá 1 giây hoặc giá trị dữ liệu của một cam kết giao dịch.
Các tài liệu cũng nói sử dụng sync_binlog=1.
Theo Tài liệu MySQL trên sync_binlog
Giá trị 1 là lựa chọn an toàn nhất vì trong trường hợp xảy ra sự cố, bạn mất tối đa một tuyên bố hoặc giao dịch từ nhật ký nhị phân. Tuy nhiên, nó cũng là lựa chọn chậm nhất (trừ khi đĩa có bộ đệm được hỗ trợ bằng pin, giúp đồng bộ hóa rất nhanh).
Sự lựa chọn an toàn nhất của bạn là
[mysqld]
innodb_flush_log_at_trx_commit=1
sync_binlog=1
Nếu bạn không bận tâm đến việc mất dữ liệu (giá trị lên tới 1 giây) thì bạn có thể tự chịu rủi ro 0 hoặc 2 nếu phần thưởng (tốc độ ghi nhanh hơn) có giá trị.
commit thực sự có thể bị mất?
Các innodb_flush_log_at_trx_commitđược sử dụng với mục đích như ..
Nếu giá trị innodb_flush_log_at_trx_commit là 0, bộ đệm nhật ký được ghi ra tệp nhật ký một lần mỗi giây và thao tác tuôn ra đĩa được thực hiện trên tệp nhật ký, nhưng không có gì được thực hiện tại một cam kết giao dịch.
Khi giá trị là 1 (mặc định), bộ đệm nhật ký được ghi ra tệp nhật ký tại mỗi lần giao dịch và thao tác tuôn ra đĩa được thực hiện trên tệp nhật ký.
Khi giá trị là 2, bộ đệm nhật ký được ghi ra tệp tại mỗi lần xác nhận, nhưng thao tác tuôn ra đĩa không được thực hiện trên nó. Tuy nhiên, việc xả vào tệp nhật ký cũng diễn ra một lần mỗi giây khi giá trị là 2. Lưu ý rằng việc xả một lần mỗi giây không được đảm bảo 100% xảy ra mỗi giây, do các vấn đề lập lịch xử lý.
Giá trị mặc định là 1 là bắt buộc để tuân thủ ACID đầy đủ. Bạn có thể đạt được hiệu suất tốt hơn bằng cách đặt giá trị khác với 1, nhưng sau đó bạn có thể mất tối đa một giây giao dịch trong một vụ tai nạn. Với giá trị 0, bất kỳ sự cố quá trình mysqld nào cũng có thể xóa giây cuối cùng của giao dịch. Với giá trị là 2, chỉ một sự cố hệ điều hành hoặc mất điện mới có thể xóa đi giây cuối cùng của giao dịch. Phục hồi sự cố của InnoDB hoạt động bất kể giá trị.
Theo ý kiến của tôi, sử dụng innodb_flush_log_at_trx_commitđến 2 không phải là một vấn đề. Nhưng để sử dụng 1 là an toàn nhất.
Ý kiến của tôi khác với khác. innodb_flush_log_at_trx_commit = 0 nếu: đó là máy tính phát triển của tôi hoặc cơ sở dữ liệu nhỏ tại nhà không có dữ liệu nhạy cảm.
innodb_flush_log_at_trx_commit = 2 nếu: đó là blog / thống kê / thương mại điện tử (với ~ 100x cửa hàng trong ngày), v.v.
innodb_flush_log_at_trx_commit = 1 nếu: bạn có rất nhiều khách hàng hoặc bạn cần phải làm việc với giao dịch tiền như ngân hàng. vì vậy lần này bạn nên phân chia luồng dữ liệu của mình giữa một số máy chủ để có tốc độ và an toàn.
Tôi thích 2, vì nó có tốc độ ghi nhanh hơn ~ 75 lần và CHỈ bị lỗi nếu phần cứng bị lỗi.
Dù sao, bạn nên biết những gì bạn cần nhiều hơn tốc độ viết hoặc lên đến 1 giây thông tin?
75x faster write speed and it fails ONLY if hardware fails.
UPDATEvới innodb_flush_log_at_trx_commit = 1: 179 giây. Với innodb_flush_log_at_trx_commit = 2: 1,12 giây. Đó là tốc độ ghi nhanh hơn 160 lần trong trường hợp của tôi.
crash
Tôi đang cố gắng trả lời, mục đích của innodb_flush_log_at_trx_commit?
InnoDB thực hiện hầu hết các hoạt động của nó tại bộ nhớ ( InnoDB Buffer Pool). Al dữ liệu đã sửa đổi được ghi vào InnoDB transaction log filevà sau đó xóa (ghi) để lưu trữ lâu bền (đĩa cứng).
Để an toàn dữ liệu ( Durability from ACID), InnoDB phải lưu trữ dữ liệu đã sửa đổi của từng giao dịch vào một bộ lưu trữ vĩnh viễn. Đồng thời, cam kết vào đĩa cho mỗi giao dịch là quá trình tốn kém.
Đĩa I / O là một quá trình chặn và nó rất chậm, nó là một đĩa chậm, hơn nữa nó sẽ làm giảm số lượng InnoDB transaction per seconds(Thông lượng đĩa).
InnoDB cung cấp, innodb_flush_log_at_trx_commitbiến để kiểm soát tần suất của hoạt động tuôn ra này. Dựa trên giá trị, hoạt động tuôn ra của InnoDB hoạt động khác nhau.
(Đã được giải thích trong các câu trả lời khác)
0 - Ghi vào tệp nhật ký và xóa vào đĩa mỗi giây (dữ liệu nằm trong vùng đệm không được ghi vào tệp nhật ký - để đạt được hiệu suất). 1 - Xả vào đĩa khi giao dịch được thực hiện - mặc định (Vì an toàn dữ liệu - Tuân thủ ACID) 2 - ghi vào tệp nhật ký cho mỗi giao dịch và xả vào đĩa mỗi giây. (Để đạt được hiệu suất)
Tùy thuộc vào yêu cầu ứng dụng ( Performance Vs data safety), bạn có thể đặt biến này. Sự khác biệt giữa 0 và 2 - cả hai sẽ tăng hiệu suất, giá trị 2 lưu trữ dữ liệu trong tệp giao dịch và có thể phục hồi được, trong trường hợp gặp sự cố hoặc thất bại, nhưng không phải là 0.
Trong nhiều trường hợp, tuôn ra đĩa là phương tiện, dữ liệu được ghi từ InnoDB buffer pool (memory) to Operating systems cachekhông thực sự được ghi vào đĩa lưu trữ (lưu trữ vĩnh viễn). Trong trường hợp thất bại, trong trường hợp xấu nhất, bạn có thể mất dữ liệu tối đa một giây)
Hiệu suất đạt được phụ thuộc vào môi trường và bạn có thể điểm chuẩn và xác định. Trong một môi trường nhân rộng, để đảm bảo an toàn và nhất quán dữ liệu, hãy đặt innodb_flush_log_trx_commit = 1và sync_binlog=1.
Nếu hiệu suất là mục tiêu chính của ứng dụng, InnoDB cung cấp một biến để kiểm soát tần suất xả nhật ký - innodb_flush_log_at_timeout- cho phép bạn đặt dải tần số xả nhật ký từ 1 to 2700 seconds, theo mặc định, đó là 1.
Xin lưu ý, khi bạn tăng khoảng thời gian xả lên tới N giây, hiệu suất đạt được đi kèm với sự thỏa hiệp về an toàn dữ liệu lên đến N giây. Ví dụ: nếu bạn đặt xả nước xảy ra cứ sau 5 giây - mức tăng thông lượng rất cao, nhưng trong trường hợp mất điện hoặc sự cố hệ thống, bạn sẽ mất dữ liệu trị giá 5 giây.
Bài viết này thảo luận về hoạt động xả rửa và giao dịch cam kết của InnoDB .
Bạn có thể thay đổi sau khi bạn thực hiện chế độ 2 trên aws rds:
Không thể thay đổi trong một số trường hợp như nếu bạn có bản sao đa az:
Nếu phần cứng của bạn bị lỗi, bạn có thể mất tất cả dữ liệu của mình, vì vậy tôi sử dụng param = 2 mà không phải lo lắng gì. Dù sao, bạn có thể phân chia dữ liệu nhạy cảm (thứ tự, tiền ảo, ...) và dữ liệu thông thường (thống kê, giỏ hàng, ...) giữa 2 máy chủ db và giữ chúng an toàn và nhanh chóng. Đối với các giao dịch giữa các cơ sở dữ liệu, bạn có thể sử dụng http://dev.mysql.com/doc/refman/5.7/en/xa.html