Di chuyển một ứng dụng PHP từ MySQL sang DB2 - Phần 2: Di trú dữ liệu của bạn

áo 
Ứng dụng 
(pttuser) 
Một người dùng có quyền truy cập đọc và viết vào cơ sở dữ 
liệu sản xuất Sản xuất 
Tạo báo cáo 
(read) 
Một người có quyền truy cập chỉ đọc vào cơ sở dữ liệu sản 
xuất và tạo báo cáo 
Sản xuất và tạo 
báo cáo 
Có thể tạo ra các tài khoản người dùng trên hệ điều hành Linux và các câu lệnh GRANT (cấp) 
được dùng để gán cho chúng các đặc quyền cơ sở dữ liệu đúng đắn. Điều này thường được thực 
hiện như một hoạt động riêng rẽ sau khi bạn đã tạo ra cơ sở dữ liệu DB2 và đã di trú dữ liệu từ 
MySQL vào nó. Tuy nhiên, khi bạn triển khai vào sản xuất, bạn sẽ bao gồm các câu lệnh 
GRANT vào trong cùng DDL khi bạn sử dụng để tạo cấu trúc cơ sở dữ liệu. 
Với MySQL, việc cung cấp quyền truy cập thường là ở mức thô, vì bạn có thể cấp phép cho một 
người dùng (được xác định đủ điều kiện bởi một tên máy tính chủ (hostname) mà từ đó người 
dùng kết nối) các quyền hạn truy cập đọc, viết hoặc quản lý khác đối với toàn bộ cơ sở dữ liệu. 
Trong ví dụ này, người dùng pttuser có quyền truy cập đọc và viết vào cơ sở dữ liệu (chỉ từ tên 
máy tính chủ (hostname) của máy chủ web) và do đó có thể truy cập và chỉnh sửa mỗi bảng 
trong đó. 
Với DB2, bạn cấp phép truy cập cho một người dùng, nhưng bạn không chỉ ra tên máy tính chủ 
mà từ đó người dùng kết nối. Ngoài ra với DB2, bạn có thể chỉ rõ đó là quyền truy cập để truy 
vấn, thêm, hoặc cập nhật dữ liệu như bạn làm trong MySQL. Tuy nhiên, bạn phải cấp phép truy 
cập cho một người dùng với mỗi bảng trong cơ sở dữ liệu, vì không có một câu lệnh đơn lẻ nào 
để cấp phép truy cập toàn bộ cơ sở dữ liệu (trừ khi bạn đã tạo ra cơ sở dữ liệu và các bảng với tư 
cách là người dùng đó, mà điều này được khuyến cáo là không nên làm). Vì vậy, các lệnh 
GRANT thường bao gồm trong DDL sau khi các đối tượng, như các bảng, được tạo ra. 
cho thấy các quyền hạn để cấp cho bảng WORK trong ví dụ. Người dùng application nhận được 
đầy đủ quyền truy cập đọc và viết, trong khi người dùng reporting chỉ có thể đọc dữ liệu. 
Liệt kê 6. Các câu lệnh GRANT mẫu 
-- GRANT statements to provide read/write access to the application user 
account 
GRANT DELETE ON TABLE "TIMETRAC"."WORK" TO USER "PTTUSER"; 
GRANT INSERT ON TABLE "TIMETRAC"."WORK" TO USER "PTTUSER"; 
GRANT SELECT ON TABLE "TIMETRAC"."WORK" TO USER "PTTUSER"; 
GRANT UPDATE ON TABLE "TIMETRAC"."WORK" TO USER "PTTUSER"; 
-- GRANT statement to provide read only access to the reporting/ad hoc user 
account 
GRANT SELECT ON TABLE "TIMETRAC"."WORK" TO USER "READ"; 
Mục 7.1.3 trong Hướng dẫn chuyển đổi MySQL sang DB2 (xem phần Tài nguyên) cung cấp 
thông tin chi tiết về các khác biệt trong việc quản lý tài khoản người dùng và các tùy chọn mức 
chi tiết hơn do DB2 cung cấp. 
Chuyển đổi thủ tục sao lưu và khôi phục lại 
Bạn đã sẵn sàng thực hiện một kế hoạch khắc phục thảm họa, cân bằng giữa yêu cầu sẵn sàng 
cao của ứng dụng với yêu cầu lưu trữ cẩn thận dữ liệu của bạn. 
Trong MySQL, bạn có thể sử dụng một lệnh như mysqldump để sao lưu dữ liệu của bạn và chạy 
thi hành SQL để khôi phục lại dữ liệu. Trong hệ thống ví dụ, bạn muốn dựa vào các bản sao lưu 
hàng đêm bằng cách sử dụng mysqldump và bạn muốn chạy một cơ sở dữ liệu bản sao được đồng 
bộ hóa cho mục đích tạo báo cáo chỉ đọc và phục vụ cho nhiệm vụ kép như một hệ thống dự 
phòng sống. 
Đối với cơ sở dữ liệu mới, hãy lập lịch biểu các lệnh sao lưu và phục hồi bằng cách sử dụng các 
công cụ được cung cấp kèm DB2. Bạn có một số lựa chọn cho các lệnh này để cho phép bạn 
thực hiện các sao lưu đầy đủ hoặc sao lưu gia tăng, trực tuyến hoặc không trực tuyến. Ví dụ, bạn 
có thể muốn thực hiện một sao lưu gia tăng trực tuyến một lần mỗi ngày, và rồi thực hiện một 
sao lưu đầy đủ, không trực tuyến một lần cho mỗi tuần trong một cửa sổ bảo trì. cho thấy một ví 
dụ về chính sách và lập lịch biểu sao lưu và khôi phục. 
Bảng 2. Kế hoạch. sao lưu và khắc phục thảm họa 
Nhiệm vụ Mô tả 
Sao lưu trực 
tuyến hàng 
đêm 
Thực hiện sao lưu trực tuyến cơ sở dữ liệu DB2 mỗi đêm và lưu trữ nó trên cùng 
một máy chủ DB2. Việc sao lưu này cung cấp khả năng khôi phục lại nhanh chóng 
và dễ dàng khỏi các vấn đề cơ sở dữ liệu đơn giản. Nó không đòi hỏi bạn phải 
dừng ứng dụng. Tuy nhiên, nó cũng không cung cấp khả năng sử dụng các bản ghi 
nhật ký để khôi phục lại giao dịch kể từ lúc sao lưu, có nghĩa là bất kỳ dữ liệu nào 
được tạo ra trong thời gian từ lúc thực hiện sao lưu đến lúc có lỗi cơ sở dữ liệu có 
thể không còn nữa. 
Sao lưu hàng 
tuần không 
trực tuyến 
Thực hiện sao lưu không trực tuyến cơ sở dữ liệu DB2, mỗi cuối tuần và lưu trữ 
nó trên máy chủ khác, tốt nhất ở vị trí khác. Việc sao lưu này tạo ra khả năng khôi 
phục lại tin cậy hơn khỏi các vấn đề lớn của máy chủ. Việc sao lưu này đòi hỏi 
bạn dừng ứng dụng. Tuy nhiên, nó cũng cung cấp khả năng khôi phục lại các giao 
dịch từ lúc sao lưu bằng cách sử dụng các bản ghi nhật ký, có nghĩa là dữ liệu có 
thể được khôi phục lại đầy đủ bằng cách sử dụng sao lưu và các hoạt động đã 
được ghi lại kể từ lúc sao lưu bằng cách cho chạy lại dựa theo nhật ký. 
Chương 9 của Hướng dẫn chuyển đổi MySQL sang DB2 (xem phần Tài nguyên) có thể là chìa 
khóa để xác định và triển khai một quá trình sao lưu và khôi phục lại mới. Nó cung cấp các lệnh 
sao lưu mẫu và các gợi ý về cách lập lịch biểu các lần chạy sao lưu bằng cách sử dụng DB2 
Control Center hay Optim™ Development Studio. 
Chuyển đổi mô hình sao chép tạo báo cáo 
Như đã nói trong Phần 1, việc cải thiện sự tinh thông nghiệp vụ của bạn qua việc chọn dùng một 
công cụ như Cognos là một yếu tố quan trọng dẫn dắt bạn di trú sang DB2. Như vậy, cấu hình 
một cơ sở dữ liệu bản sao để chạy các truy vấn và trích xuất các báo cáo trên đó phải là một phần 
trọng yếu của các nỗ lực di trú cơ sở dữ liệu của bạn. 
Nếu bạn cần chạy các báo cáo dựa vào dữ liệu của bạn, thì nhiều khả năng bạn có một cơ sở dữ 
liệu bản sao chỉ đọc để giảm tải trên cơ sở dữ liệu sản xuất chính của bạn. Cơ sở dữ liệu bản sao 
là một bản sao chính xác của cơ sở dữ liệu vận hành. Bạn chạy ứng dụng của mình để truy cập và 
sửa đổi thông tin của cá thể chính của cơ sở dữ liệu, sao chép tất cả dữ liệu vào cơ sở dữ liệu bản 
sao, và chạy tất cả các báo cáo của bạn dựa vào cá thể chỉ đọc đó của cơ sở dữ liệu. 
Một lần nữa, MySQL và DB2 xử lý các bản sao khác nhau. Với MySQL, bạn có thể thay đổi một 
vài tham số cấu hình và sao chép toàn bộ cơ sở dữ liệu từ một máy chủ sang máy chủ khác trong 
thời gian thực. Hoặc bạn có thể thực hiện các lần sao lưu và hồi phục không đồng bộ các bản sao 
lưu này vào một thời gian sau đó vào trong cơ sở dữ liệu khác. 
Với DB2, bạn có sẵn các tùy chọn tương tự, bao gồm sao chép SQL và sao chép Q. Ví dụ, sử 
dụng sao chép SQL để tránh sự phức tạp tăng thêm do trình quản lý hàng đợi thông báo dựa trên 
kênh, cần phải có để xử lý sao chép Q. Với sao chép SQL, bạn tạo một cấu hình chỉ rõ mỗi bảng 
trong cơ sở dữ liệu mà bạn muốn sao chép. Bạn sẽ cần chắc chắn cập nhật cấu hình đó bất cứ lúc 
nào bạn thực hiện một thay đổi cho cấu trúc cơ sở dữ liệu của bạn. 
Ngoài ra, trước khi thiết lập sao chép trong DB2, bạn sẽ cần đảm bảo rằng tất cả các bảng cơ sở 
dữ liệu có một khóa chính hoặc chỉ mục duy nhất. Trong khi đây là một cách thực hành tốt, thì 
một số cơ sở dữ liệu có thể thiếu điều này. Hãy nhớ rằng các bảng MySQL ví dụ thiếu các giá trị 
này bởi vì chúng đã được tạo ra bằng máy lưu trữ MyISAM cơ bản. Bản sao MySQL sẽ làm việc 
mà không cần khóa hoặc chỉ mục. Tuy nhiên, việc sao chép DB2 đòi hỏi có khóa hoặc chỉ mục 
để định danh duy nhất các hàng trong một bảng. Nếu một bảng không có một khóa chính hoặc 
một chỉ mục duy nhất nào, các bản ghi được cập nhật trong cơ sở dữ liệu vận hành có thể được 
xem như các bản ghi mới được tạo ra chứ không phải bản ghi đang có được cập nhật, vì không 
có khóa nào để sử dụng để tìm ra bản ghi đang được cập nhật. 
Chương 9 của Hướng dẫn chuyển đổi MySQL sang DB2 (xem phần Tài nguyên) là trung tâm của 
chiến lược cấu hình tạo bản sao của bạn. DB2 cung cấp các công cụ có thể được sử dụng để quản 
lý các thiết lập sao chép, hoặc bạn có thể thực hiện một giải pháp tùy chỉnh dựa trên việc chuyển 
đổi các bản ghi nhật ký. 
Về đầu trang 
Bước 4. Kiểm lại bước khởi đầu di trú cơ sở dữ liệu 
Tại thời điểm này sau một lần lặp lại trọn vẹn các bước 1-3, mà bản thân chúng lại bao gồm một 
số bước, bạn sẽ phải có một hệ thống cơ sở dữ liệu hoạt động trên một máy trạm Windows và 
một số ghi chép về những gì bạn đã thay đổi và những gì đã có vấn đề. 
Nếu bạn đã sử dụng máy ảo, bạn lấy một ảnh của hệ thống Windows làm một ảnh chụp, vừa để 
lưu trữ như là một điểm lưu làm việc vừa để sử dụng như là một vạch khởi đầu để so sánh các 
thay đổi hiệu năng trong tương lai. Một lựa chọn khác, tất nhiên, là sử dụng một ảnh ảo trong 
Đám mây của IBM hay của Amazon và sử dụng ảnh đó theo cùng một cách. 
Bạn có thể muốn thí nghiệm một số cách thực hiện di trú khác nhau để xem cách nào làm việc 
tốt nhất cho môi trường của bạn. Một khi bạn đã hài lòng với hệ thống trên máy trạm Windows 
được sử dụng trong các bước 1-3, thì bạn có thể di chuyển cơ sở dữ liệu đến một máy chủ dành 
riêng, ở đó bạn sẽ thử nghiệm các bản cập nhật cho ứng dụng PHP trong Phần 3 của loạt bài này. 
Về đầu trang 
Kết luận 
Mục đích của loạt bài này là cung cấp cho bạn một sự hiểu biết về những gì cần thiết nói chung 
để di trú một ứng dụng PHP từ MySQL sang DB2, tài nguyên nào có sẵn để giúp bạn, và một ví 
dụ về một cuộc di trú thành công. 
Trong phần thứ hai này của loạt bài, bạn: 
 Đã tìm hiểu về cơ sở dữ liệu MySQL nguồn bạn đã chuyển đổi 
 Đã tìm hiểu cách chuyển đổi cấu trúc cơ sở dữ liệu sang DB2 
 Đã tìm hiểu cách di trú dữ liệu sang DB2 
 Đã tìm hiểu cách thiết lập quản trị cơ sở dữ liệu của bạn 
Trong phần tiếp theo của loạt bài này, bạn sẽ tìm hiểu cách chuyển đổi mã PHP. 
Lời cảm ơn 
Các tác giả cảm ơn Leons Petrazickis và Ambrish Bhargava về việc xem xét và góp ý kiến cho 
bài này..