2011-12-08 18 views
8

Môi trường: Ubuntu 11.10, MySQL 5.1.58MySQL có thể phục hồi đáng tin cậy các bản sao lưu có chứa các khung nhìn hay không?

Tôi có một cơ sở dữ liệu nhỏ với chế độ xem. Khi tôi cố gắng đổ và khôi phục, tôi nhận được

ERROR 1356 (HY000) at line 1693: View 'curation2.condition_reference_qrm_v' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them 

Tuy nhiên, tôi có thể kết nối với cơ sở dữ liệu được khôi phục một phần và tự tạo chế độ xem. Vì vậy, tôi nghi ngờ rằng các thông báo lỗi kết quả từ một vấn đề không liên quan đến chính nó (nhưng thay vì cách nó được khôi phục, có lẽ).

Đây là phương pháp đơn giản tôi sử dụng để chứng minh vấn đề:

MYSQL_PWD='xxx' mysqldump -u root --routines -B curation \ 
| perl -pe 's/`curation`/`curation2`/' \ 
| MYSQL_PWD='xxx' mysql -u root 

Có rất nhiều báo cáo khác trực tuyến của các vấn đề tương tự. Trang mansqldump có một lưu ý khó hiểu về các lỗi với việc sao lưu các khung nhìn, nhưng nó được viết như một vấn đề lịch sử chứ không phải là một vấn đề hiện tại.

Vì vậy, câu hỏi đặt ra là: MySQL có thể khôi phục đáng tin cậy các bản sao lưu có chứa chế độ xem hay không? Nếu nó có thể, làm thế nào? Nếu không, những gì mọi người làm như một cách giải quyết?

Cảm ơn, Reece

Trả lời

3

Tôi đã tìm thấy sự cố trong trường hợp của mình. Tôi không chắc chắn rằng nó giải quyết các báo cáo tương tự trên web.

Điều này về cơ bản là một vấn đề về quyền được tạo ra từ việc cố sao chép cơ sở dữ liệu này sang tên mới. Quyền không tồn tại đối với người dùng và lược đồ này (locus trên curation2). Tôi đã thêm thủ công 'GRANT ALL ON curation2. * TO locus' (locus là người dùng được báo cáo trong lỗi). Sau khi thực hiện điều này, dòng lệnh trên hoạt động tốt.

Bài học là người ta phải cấp phép thủ công các quyền cần thiết cho cơ sở dữ liệu đích và bảng khi tạo cơ sở dữ liệu mới.

0

Vài điều:

1.) Có, bạn có thể tạo các quan điểm sử dụng một số khách hàng NHƯNG có lẽ là chủ sở hữu của bảng không phải là chủ sở hữu của xem, mà dẫn để

2.) Thông thường, thực hiện sao lưu quan điểm trong mysql bao gồm một số "rác vô dụng" như

create algorithm xxx definer=<USER> sql security view <view_name> as .... 

và rằng người dùng thường bao gồm IP hoặc tên máy mà người dùng đã đăng nhập khi tạo chế độ xem ... SO, chế độ xem sẽ không tạo đúng cách. Kiểm tra xem, có thể giúp bạn.

+0

Tôi đang thực hiện tất cả điều này dưới dạng thư mục gốc. Đó không phải là thực hành tiêu chuẩn của tôi, nhưng quyền không có khả năng là vấn đề (tôi nghĩ) khi tôi làm điều này như là người chủ. Tôi không hiểu những gì bạn đang cố gắng để nói về định nghĩa xem, nhưng nó có vẻ hợp lý với tôi trong bãi chứa. – Reece

+0

Vui lòng mang đến đây định nghĩa chế độ xem và thêm nó vào câu hỏi. Chỉ cần kiểm tra – Alfabravo

10

Câu hỏi này hơi cũ, nhưng tôi đã lãng phí một vài giờ cố gắng giải quyết chính xác cùng một vấn đề, vì vậy tôi đoán một lời giải thích rõ ràng có thể có ích cho một ai đó trong tương lai ...

Để cắt theo đuổi: Sự cố nằm trong trường DEFINER trong vùng kết xuất mysql của bạn. Nó trông giống như sau:

/*!50013 DEFINER=`some_user`@`localhost` SQL SECURITY DEFINER */ 

Vấn đề là rằng đây * some_user @ localhost * sẽ luôn luôn được hardcoded vào tài khoản người dùng đã được sử dụng để tạo ra các quan điểm trong DB gốc và KHÔNG người dùng mà bạn' đã sử dụng để xuất hoặc nhập cơ sở dữ liệu như một người mong đợi (hoặc ít nhất là tôi đã làm). Và sau đó, trong quá trình nhập, người dùng này sẽ được sử dụng để tạo lại chế độ xem.

Vì vậy, bạn có thể xuất/nhập dưới dạng gốc, nhưng nếu DB ban đầu đang chạy dưới một người dùng khác và không có quyền CREATE VIEW trong cơ sở dữ liệu mới, quá trình nhập sẽ không thành công.

Bạn có hai giải pháp đơn giản:

  1. tìm kiếm và thay thế tất cả các tham chiếu tới some_user @localhost trong tập tin dump của bạn với người dùng của bạn mới (một trong những bạn sử dụng để nhập khẩu các bãi chứa, ví dụ: root @ localhost)
  2. Hoặc bạn có thể cấp * some_user * quyền thích hợp trên cơ sở dữ liệu mới để xem có thể được tạo ra trong tài khoản của mình

Dù bằng cách nào sẽ khắc phục vấn đề, nhưng tôi nghĩ rằng phương pháp tiếp cận đầu tiên là cách tốt hơn và sạch hơn, như y Bạn không phải lo lắng về nhiều người dùng trong tương lai.

7

Những gì tôi tìm thấy để giải quyết vấn đề là sử dụng 'kẻ xâm nhập bảo mật sql' khi tạo chế độ xem ban đầu.

create or replace sql security invoker view <VIEW_NAME> as select ... 

Nó xác định quyền truy cập vào chế độ xem của người gọi chứ không phải người hủy.

Sau đó, khi tệp kết xuất được tải, chế độ xem được tạo chính xác.

Với Amazon RDS:

Để làm công việc này với Amazon RDS, mà không cho phép siêu priv (đó là cần thiết để làm các việc trên) người ta có thể chạy lệnh này để vào các tập tin dump:

# Remove DEFINER statement from VIEWS in Dump file 
sed -i 's/\sDEFINER=`[^`]*`@`[^`]*`//' $DUMPFILE_NAME 

Sau đó, khi tệp kết xuất được tải vào RDS, chế độ xem được tạo chính xác.

+0

Điều này có vẻ là một yêu cầu vô cùng mơ hồ của Amazon. Tôi tự hỏi tại sao lượt xem không được bao gồm một cách đơn giản theo mặc định? –

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