Di chuyển ứng dụng PHP từ MySQL sang DB2, Phần 4: Triển khai ứng dụng của bạn

Những bài học rút ra từ việc nghiên cứu các ứng dụng IBM Intranet

Tìm hiểu tại sao cần di chuyển một ứng dụng PHP sang DB2 ®, cách lập kế hoạch di trú, cách thực hiện nó, cách hỗ trợ nó và cách xử lý các rủi ro tiềm ẩn dựa trên kinh nghiệm nghiên cứu về ứng dụng mạng nội bộ (Intranet) của IBM. Loạt bài bốn phần này chia sẻ các bài học rút ra từ một cuộc di trú MySQL-sang-DB2 thành công cho một ứng dụng Intranet PHP trọng yếu được 4.000 người dùng của IBM trên toàn cầu sử dụng để hỗ trợ sản xuất nội dung cho ibm.com. Phần 4 của loạt bài này mô tả các bước thực hiện để triển khai và hỗ trợ ứng dụng.

Daniel Krook, Kỹ sư phần mềm, IBM

Daniel Krook là một chuyên gia CNTT có chứng chỉ xuất sắc của IBM/Open Group làm việc tại vùng New York City mở rộng. Ông đã có hơn mười năm kinh nghiệm trong việc phát triển ứng dụng web và hiện đang xây dựng một cơ sở hạ tầng Đám mây cho IBM bằng cách sử dụng các công nghệ Java EE, DB2, REST và công nghệ di động. Ông có các chứng chỉ về PHP, Java EE, BlackBerry, DB2 và Solaris. Ông viết các bài liên quan đến PHP cho developerWorks của IBM và đồng tác giả của quyển sách IBM Redbook "Developing PHP Applications for IBM Data Servers (Phát triển các ứng dụng PHP cho Các máy chủ dữ liệu của IBM)".


Cấp độ đóng góp cho developerWorks của
        tác giả

Yan Li Mu, Kiến trúc sư CNTT, I.B.M.

Yan Li Mu là một kiến trúc sư CNTT làm việc tại Đại Liên, Trung Quốc. Anh đã có hơn tám năm kinh nghiệm trong việc phát triển ứng dụng web, tập trung vào các công nghệ Java EE, PHP và phát triển cơ sở dữ liệu.



Mark Nusekabel, Kiến trúc sư CNTT cao cấp, I.B.M.

Mark Nusekabel là một Kiến trúc sư CNTT có chứng chỉ xuất sắc của IBM/Open Group sống ở vịnh Tampa, vùng Florida. Ông đã có hơn 20 năm kinh nghiệm trong lĩnh vực công nghệ thông tin và ông hiện đang xây dựng các công cụ nội bộ bằng cách sử dụng JavaScript, PHP, Java và DB2. Ông có các chứng chỉ về các giải pháp kinh doanh điện tử, Java và XML.



02 04 2013

Giới thiệu về loạt bài này

MySQL hiện là máy chủ cơ sở dữ liệu phổ biến nhất được sử dụng với ngôn ngữ lập trình PHP để xây dựng các ứng dụng web động. Tuy nhiên, DB2 lại là một cơ sở dữ liệu phổ biến khác được PHP hỗ trợ đầy đủ và cung cấp các lợi thế hấp dẫn hơn so với MySQL, làm cho DB2 trở thành một lựa chọn lý tưởng cho nhiều ứng dụng.

Loạt bài này mô tả tại sao nên di chuyển một ứng dụng PHP sang DB2, cách chuẩn bị cho việc di trú, cách thực hiện nó, cách hỗ trợ nó và cách xử lý các rủi ro tiềm ẩn dựa trên kinh nghiệm của các tác giả trong một cuộc di trú mới đây. Nhiều đoạn mã mẫu và cấu hình mẫu được cung cấp, cũng như các chỉ dẫn đến tài nguyên để giúp cho dự án chạy trơn tru.

Với các ví dụ và các bài học đã thu được từ một cuộc chuyển đổi thực tế thành công, bạn sẽ thấy đây là một dự án đơn giản, có tài liệu hướng dẫn đầy đủ và mang lại nhiều lợi ích hấp dẫn.

Loạt bài bốn phần này chia sẻ các bài học thu được từ việc di chuyển MySQL sang DB2 thành công cho một ứng dụng Intranet PHP trọng yếu, mức sản xuất, được 4.000 người dùng của IBM trên toàn cầu sử dụng để hỗ trợ sản xuất nội dung cho ibm.com.

  • Phần 1 mô tả các bước cần thực hiện để chuẩn bị cho việc di trú.
  • Phần 2 mô tả các bước cần thực hiện để di trú cơ sở dữ liệu.
  • Phần 3 mô tả các bước cần thực hiện để chuyển đổi mã PHP.
  • Phần 4 mô tả các bước cần thực hiện để triển khai và hỗ trợ ứng dụng.

Bạn sẽ học được điều gì

Mục đích của loạt bài này là cung cấp cho bạn sự hiểu biết về những gì cần thiết để di trú một ứng dụng PHP từ MySQL sang DB2, những tài nguyên nào có sẵn để giúp bạn và một nhóm dự án của IBM đã thực hiện nhiệm vụ này vào đầu năm 2010 như thế nào.

Nếu bạn đã nghiên cứu việc di chuyển từ MySQL sang DB2, bạn có thể đã thấy giá trị mà DB2 cung cấp dựa trên tài liệu sản phẩm, các đánh giá tiêu chuẩn về hiệu năng, các tính năng mà bạn đã đọc trong tài liệu hướng dẫn DB2 hoặc các so sánh trong IBM Redbooks ® dành riêng cho nhiệm vụ này, bao gồm sách MySQL to DB2 Conversion Guide - Hướng dẫn chuyển đổi MySQL sang DB2 (xem phần Tài nguyên).

Có lẽ bạn cũng biết rằng DB2 Express-C là một máy chủ dữ liệu quan hệ có đủ chức năng, miễn phí có thể dễ dàng được cài đặt hoặc được đánh giá bằng cách sử dụng IBM SmartCloud (tên cũ là Development and Test on the Cloud - Phát triển và Thử nghiệm trên Đám mây của IBM) hoặc Amazon EC2. Các liên kết đến các sản phẩm này có sẵn trong phần Tài nguyên.

Loạt bài này cung cấp cho bạn một ví dụ cụ thể về việc di chuyển thực tế đã được thực hiện thành công như thế nào trong năm 2010 cho một ứng dụng Intranet PHP được sử dụng rất nhiều trong IBM để hỗ trợ quản lý nội dung hàng ngày được công bố trên nhiều phần của trang Web ibm.com.

Sau khi bạn đọc xong loạt bài này, bạn có thể thực hiện một trường hợp di chuyển tương tự, hiểu được thời hạn và các phụ thuộc của các mục công việc cần được thực hiện, dự kiến các rủi ro tiềm ẩn và biết nơi để tìm kiếm sự hỗ trợ từng bước trong lúc thực hiện di trú. Tất cả điều này sẽ cho bạn sự tự tin hơn để lựa chọn DB2 và sử dụng nó một cách tốt nhất cho các ứng dụng PHP của mình hiện đang được xây dựng trên MySQL.

Những gì không được trình bày

Loạt bài này nhằm chia sẻ các bài học thu được từ một cuộc di trú nội bộ của IBM từ MySQL sang DB2 và cung cấp cho bạn thông tin về tài nguyên có sẵn để thực hiện một công việc tương tự. Loạt bài này không phải là một hướng dẫn toàn diện về di trú để có thể áp dụng được cho tất cả các kịch bản.

Để xác định cách tiếp cận phù hợp với bạn, hãy tham khảo MySQL to DB2 Conversion Guide - Hướng dẫn chuyển đổi MySQL sang DB2 hoặc liên hệ với SMPO (Software Migration Project Office - Văn phòng dự án di trú phần mềm) để đánh giá di trú miễn phí. Các liên kết này được cung cấp trong phần Tài nguyên.


Giới thiệu về triển khai

Bài này trình bày bốn bước chính để triển khai và hỗ trợ ứng dụng và cơ sở dữ liệu một khi nó đã sẵn sàng cho sản xuất. Nếu cần, hãy tham khảo Phần 1 của loạt bài này để xem lịch trình các bước ấy trong quá trình di trú tổng thể trước khi tiến hành triển khai.

Bước 1: Tạo một môi trường sản xuất mới
  • Xác định cấu trúc liên kết sản xuất và chiến lược triển khai.
  • Cấu hình các máy chủ dữ liệu DB2 chính và bản sao sản xuất.
  • Cấu hình máy chủ ứng dụng PHP sản xuất.
Bước 2: Chuẩn bị một chiến lược giám sát ứng dụng
  • Thực hiện hay cập nhật cơ chế báo cáo lỗi PHP.
  • Xác định các giá trị thích hợp cho các tính năng tự trị trong DB2.
  • Xác nhận các giá trị thiết lập sao lưu dự phòng và sao chép cơ sở dữ liệu.
Bước 3: Triển khai ứng dụng đã cập nhật
  • Lập lịch biểu một ngày triển khai để giảm thiểu ảnh hưởng đến công việc kinh doanh.
  • Bắt giữ lại các bản sao lưu ảnh của hệ thống hiện có và hệ thống mới.
  • Triển khai dữ liệu DB2.
  • Triển khai mã PHP.
  • Giám sát hệ thống mới.
Bước 4: Xử lý hỗ trợ liên tục
  • Đáp ứng hoặc tránh các vấn đề hiệu năng.
  • Cấu hình lại khi kích cỡ của dữ liệu và luồng công việc phát triển thêm.

Hiểu một nghiên cứu sâu ví dụ về cấu trúc liên kết triển khai PTT hiện có

Nhắc nhở

Nếu cần, hãy tự mình tìm hiểu phần Tài nguyên có thể có ích trong việc di trú của bạn. Các tài nguyên sau có thể đặc biệt có ích cho bước này:

  • Chương 9 và 10 trong ấn phẩm Redbooks® của IBM Hướng dẫn chuyển đổi MySQL sang DB2 (MySQL to DB2 Conversion Guide).
  • Bài "Danh sách nên xem: Quản trị cơ sở dữ liệu của DB2 cho Linux, UNIX và Windows" trên developerWorks.
  • Loạt bài "Sử dụng các kỹ năng về MySQL để tìm hiểu DB2 Express" trên developerWorks.
  • Sách trắng "Các hướng dẫn thực hành tốt nhất: Các chiến lược giảm chi phí với DB2" trên developerWorks .

Một tùy chọn khác là sử dụng đám mây cho quá trình di trú. Bạn có thể sử dụng các ảnh máy Amazon (AMI) Linux và DB2 của Amazon EC2 hoặc đăng ký dùng SmartCloud của IBM (trước đây được biết đến với tên gọi Phát triển và thử nghiệm trên Đám mây IBM) (xem Tài nguyên).

Để có được cấu trúc liên kết triển khai ví dụ trong bài này, hệ thống sản xuất PTT (Project Tracking Tool - Công cụ dò vết dự án) có một máy Linux chạy máy chủ web Apache được biên dịch từ mã nguồn với phần mở rộng mod_php được xây dựng và được nạp như một mô-đun động, một máy Linux chạy cơ sở dữ liệu chủ MySQL và một máy Linux thứ ba chạy ;một cơ sở dữ liệu MySQL sao chép cho các phân tích và các truy vấn đặc biệt.

Ứng dụng PTT được sử dụng cho các chức năng khác nhau để hỗ trợ luồng công việc thông tin được công bố trên trang web của IBM. Hơn 4.000 người dùng trên toàn thế giới truy cập và sửa đổi cơ sở dữ liệu MySQL thông qua mặt trước của trang web PHP. Tại bất kỳ thời điểm nào cũng có vài trăm người dùng đang hoạt động đồng thời trên hệ thống.

Cấu trúc liên kết đơn giản này được hiển thị trong Hình 1.

Hình 1. Cấu trúc liên kết máy chủ và phần mềm ban đầu
Người dùng cuối nối đến máy chủ web Apache với PHP trên Linux nối vào các máy chủ MySQL trên Linux để nối đến một bản sao. Người dùng báo cáo được nối tới bản sao.

Phần lớn người dùng truy cập cơ sở dữ liệu chủ thông qua mặt trước của Apache và PHP. Một ít người dùng kết nối trực tiếp đến cơ sở dữ liệu sao chép để chạy các truy vấn SQL đặc biệt hoặc sử dụng Hyperion Brio để tạo ra các báo cáo.

Trong ví dụ triển khai, vẫn duy trì cách bố trí ba máy chủ giống nhau, nhưng các hệ thống MySQL chính và bản sao đã được thay thế bằng các cá thể của DB2. Cấu hình Apache và PHP được biên dịch từ nguồn đã được thay thế bằng các phiên bản đóng gói nhị phân của Apache và PHP (Zend Server với các phần mở rộng DB2).

Bài này mô tả các yếu tố cần xem xét khi lựa chọn một cấu trúc liên kết PHP và DB2, các bước cần thiết để di chuyển mã vào sản xuất càng trôi chảy càng tốt và cách duy trì một hệ thống ổn định sau khi triển khai.


Chuẩn bị các tài sản triển khai

Để chuẩn bị triển khai các ứng dụng đã cập nhật, hãy bảo đảm rằng một bản sao ổn định của cơ sở dữ liệu và mã đã sẵn sàng cho sản xuất. Bạn sẽ đạt tới điểm này sau một số lần lặp lại quá trình di trú và chuyển đổi được mô tả trong Phần 2 và Phần 3 của loạt bài này, xem phần Tài nguyên. Ngoài sự ổn định, hãy chắc chắn rằng chức năng của ứng dụng nói chung đã được các đại diện của các bên liên quan chấp thuận.

Bản sao ổn định và được phê duyệt của dữ liệu và cấu trúc cơ sở dữ liệu DB2 được di trú
Tùy thuộc vào việc liệu môi trường sản xuất của bạn có cùng một nền tảng như hệ thống phát triển của bạn hay không, ví dụ nếu cả hai đều là các hệ thống Linux 64-bit, bạn có thể dùng một trong hai cách tiếp cận để di chuyển dữ liệu của mình vào sản xuất. Nếu chúng có cùng một nền tảng, chỉ cần sao lưu cơ sở dữ liệu trên hệ thống phát triển của bạn và phục hồi nó như một bản sao mới của cơ sở dữ liệu trong sản xuất. Trái lại, nếu chúng là các nền tảng khác nhau, bạn sẽ cần tính đến tập hợp các kịch bản lệnh của ngôn ngữ định nghĩa dữ liệu (DDL) để tạo ra cấu trúc cơ sở dữ liệu, bao gồm các đối tượng như khóa và các ràng buộc giá trị được phép, các chỉ mục và các thiết lập cấu hình. Tập hợp này cũng sẽ bao gồm các kịch bản lệnh nhập khẩu thường dùng để di chuyển dữ liệu đã di trú vào hệ thống DB2 mới.
Bản sao ổn định và được phê duyệt của mã PHP đã chuyển đổi và các tệp tĩnh khác
Bản sao này bao gồm mã PHP đã chuyển đổi và tất cả các tệp JavaScript, CSS và hình ảnh cần thiết khác để tạo ra ứng dụng web. Bản sao này cũng bao gồm các kịch bản lệnh vỏ (shell) được lập lịch biểu và được gọi thông qua các công việc dựa theo lịch biểu thời gian (cron) để xử lý các thông báo định kỳ và bảo trì thường xuyên, chẳng hạn như việc thực hiện các quy tắc lưu giữ dữ liệu hàng đêm.

Dữ liệu đúng thời điểm

Trong hầu hết các trường hợp, hệ thống sản xuất MySQL của bạn sẽ tiếp tục tạo ra các dữ liệu mới khi bạn tiến hành các bước trong Phần 2 và 3 của loạt bài này, xem phần Tài nguyên. Nhiều khả năng bạn sẽ cần nhập khẩu dữ liệu mới nhất này vào bản sao ổn định của mình để di chuyển vào sản xuất như trong Bước 2 của Phần 2. Xem Liệt kê 3 trong bài đó để thấy cách di chuyển chỉ dữ liệu đã thay đổi kể từ khi xuất khẩu ban đầu.

Hãy chắc chắn tham khảo các quyết định về cấu hình của bạn và các bài học rút ra từ các bước ở trên trong loạt bài này để bạn có thể bảo đảm hệ thống sản xuất được cấu hình đúng khi bạn triển khai. Hãy xem xét việc lưu một ảnh chụp nhanh của cả hai hệ thống hiện có và hệ thống mới như là các ảnh máy ảo trước khi triển khai tại các điểm mốc quan trọng để dùng làm các bản sao lưu dự phòng và làm các vạch chuẩn để so sánh việc cải thiện mã tiếp theo.

Nếu bạn muốn bắt giữ lại một hình ảnh của một cấu hình máy tính vật lý, bạn có thể làm việc này bằng VMware vCenter Converter (Bộ chuyển đổi vCenter của Vmware) miễn phí. Có một sự thay thế khác là xem xét dùng đám mây cho những thay đổi thực hành như vậy. Bạn có thể sử dụng các Ảnh máy Amazon (AMI) DB2 của Amazon EC2 hoặc bạn có thể đăng ký dùng SmartCloud của IBM (trước đây được gọi là Phát triển và thử nghiệm trên Đám mây của IBM). Với các máy ảo, bạn sẽ có thể không phải mua sắm phần cứng máy chủ và cài đặt một hệ điều hành và DB2, để tiết kiệm thời gian, đẩy nhanh quá trình di trú và mang lại cho bạn sự tự tin hơn để trải nghiệm với cấu hình phù hợp nhất cho nhu cầu của bạn. Có thể tìm thấy các liên kết đến tất cả những sản phẩm này trong phần Tài nguyên.


Bước 1: Tạo một môi trường sản xuất mới

Vì bạn đã di trú dữ liệu và mã trong Phần 2 và 3 của loạt bài này, hãy xem phần Tài nguyên, bạn đã nắm bắt được các lưu ý về cấu hình để biểu thị kiểu tài nguyên mà ứng dụng của bạn sẽ cần có trong sản xuất. Bây giờ ứng dụng này đã được thử nghiệm và được kiểm tra, bạn đã sẵn sàng để xác nhận môi trường có sẵn cho sản xuất cần thiết để chạy nó.

Trong nghiên cứu sâu này, ứng dụng triển khai sản xuất được chuẩn bị trên các máy chủ vật lý mới (mặc dù các máy ảo cũng là một tùy chọn), chứ không phải cấu hình lại các máy chủ hiện có để lưu trữ trên đó hệ thống dựa vào MySQL đã thấy ở trên trong Hình 1. Bước này liên quan đến các bước con sau đây.

Xác định chiến lược sản xuất

Trong ví dụ này, một cơ sở dữ liệu DB2 mới và một bản sao được cài đặt và dữ liệu được di trú lên cả hai máy chủ Linux 64-bit. Cả hai máy chủ MySQL chính và bản sao cũ hơn có bốn lõi xử lý (3,0 GHz) và 8 GB bộ nhớ RAM. Hai máy chủ DB2 mới có 8 lõi xử lý (2,5 GHz) và 16 GB RAM. Các thông số kỹ thuật mạnh hơn phản ánh tuổi tác của máy tính chứ không phải là một yêu cầu tiên quyết để có phần cứng tốt hơn cho DB2. Các kinh nghiệm di trú, chuyển đổi và thử nghiệm của bạn từ các phần trước của loạt bài này, xem phần Tài nguyên, sẽ giúp bạn phối hợp đúng các tài nguyên cho tải công việc của mình.

Các cách tiếp cận triển khai

Bạn sẽ cần trả lời những câu hỏi quan trọng sau đây khi bạn chuẩn bị triển khai ứng dụng mới được cập nhật của mình vào sản xuất.

  • Bạn có bắt đầu với một cấu hình mới hay là bạn thay thế phần mềm trên hệ thống hiện có và sử dụng lại phần cứng ? Nói cách khác, bạn có cài đặt DB2 và gỡ bỏ cài đặt MySQL như là một phần trong cùng một hoạt động triển khai không?
  • Bạn có triển khai nâng cấp cơ sở dữ liệu và nâng cấp phiên bản PHP cùng một lúc hay là bạn triển khai mỗi thành phần ở một giai đoạn riêng biệt? Đó là, nâng cấp môi trường PHP lên Zend Server trong khi vẫn sử dụng MySQL, sau đó thay thế MySQL bằng DB2?

Không phải lúc nào cũng có một câu trả lời rõ ràng. Trong ví dụ này, việc bắt đầu từ các thành phần mới được cài đặt và triển khai cấu trúc liên kết hoàn chỉnh có ít rủi ro hơn vì nói chung mọi thứ đã được thử nghiệm và vì bạn có thể dễ dàng quay trở lại hệ thống cũ trong lúc triển khai nếu có vấn đề.

Quyết định có nên thay đổi môi trường sản xuất hiện tại của bạn hay bắt đầu bằng các máy tính mới hay không
Dựa trên những quan sát từ việc thử nghiệm ứng dụng và việc hiểu các đặc tính hiệu năng của nó trong Phần 2 và Phần 3 của loạt bài này, xem phần Tài nguyên, phần cứng của bản chính và bản sao MySQL hiện có (hoặc tương tự) có thể đã đủ cho hệ thống mới dựa trên DB2.

Tuy nhiên, do hệ thống hiện có đã nhiều hơn ba tuổi rồi, nên trường hợp thử nghiệm này đã bắt đầu với phần cứng mới để vừa mạnh hơn lại vừa tiết kiệm năng lượng hơn. Bạn có thể muốn đánh giá xem đây có phải là lúc để mua sắm phần cứng mới không hoặc nếu không thì có phải là lúc để nâng cấp hệ thống của bạn để đáp ứng tốt nhất với tải công việc cơ sở dữ liệu và ứng dụng của bạn không, dựa trên bất kỳ sự nghẽn cổ chai nào mà bạn thấy trong quá trình di trú và chuyển đổi.

Quyết định xem có nên thay thế toàn bộ hệ thống sản xuất hay là nâng cấp trong nhiều giai đoạn
Một vấn đề cần xem xét khác đối với quá trình triển khai của bạn là quyết định xem bạn sẽ xây dựng một hệ thống hoàn toàn mới tách biệt khỏi bất kỳ các máy chủ sản xuất hiện tại nào của bạn hay là bạn sẽ thay thế các phần mềm trên các máy chủ vật lý hay các máy chủ ảo hiện tại của bạn. Một hệ quả tất yếu của quyết định này là liệu bạn sẽ chuyển hoàn toàn dữ liệu đồng bộ từ hệ thống cũ sang hệ thống mới cùng một lúc không hay là bạn sẽ thay thế dần dần một số thành phần.

Ví dụ, một tùy chọn đã được xem xét là thay thế một bản xây dựng tùy chỉnh của Apache và PHP bằng các phiên bản đóng gói trước khi chuyển đổi từ MySQL sang DB2. Cuối cùng, đã quyết định là thay thế tất cả các thành phần đã được thử nghiệm tích hợp cùng một lúc, chứ không phải là thực hiện các thay đổi cơ sở hạ tầng dần dần từng bước theo các giai đoạn.

Cuối cùng, hệ thống mới dựa trên DB2 phản chiếu cấu trúc liên kết triển khai MySQL hiện có, nhưng nó được xây dựng tách khỏi hệ thống trung gian và hệ thống sản xuất hiện có. Khi đã đến thời gian bật nguồn cho hệ thống mới, lưu lượng đã được chuyển hướng đến các máy chủ web mặt trước mới. Điều này cũng có nghĩa là việc triển khai có thể quay lại hệ thống cũ bằng cách đảo ngược chuyển hướng.

Lúc đầu, đã lập kế hoạch để chỉ thay thế các cá thể MySQL bằng các cơ sở dữ liệu DB2, nhưng trường hợp sử dụng này đã tận dụng lợi thế của quá trình di trú để đồng thời nâng cấp phiên bản đã biên dịch tùy chỉnh của Apache và PHP bằng các phiên bản đóng gói và dễ bảo trì.

Cấu hình các máy chủ dữ liệu DB2 chính và bản sao

Hãy cài đặt phiên bản 9.7.2 của DB2 Enterprise (Doanh nghiệp DB2) lên hai máy chủ Linux doanh nghiệp Red Hat 64-bit giống hệt nhau. Như đã lưu ý trong ô đóng khung bên cạnh đầu tiên trong bài này, các bài báo trên developerWorks là "Quản trị cơ sở dữ liệu DB2 cho Linux, UNIX và Windows" và "Sử dụng các kỹ năng MySQL để tìm hiểu DB2 Express: Các nhiệm vụ quản trị và các nhiệm vụ cơ bản của DB2 so với MySQL" đưa ra một tổng quan rất hay về các nhiệm vụ cài đặt và cấu hình then chốt và có thể tìm thấy các bài này trong phần Tài nguyên.

Cấu hình máy chủ ứng dụng PHP

Tiếp theo, hãy cài đặt Apache và Server Zend lên máy chủ ứng dụng. Máy chủ này có thể chia sẻ các đặc tả tương tự như hai máy chủ cơ sở dữ liệu. Trên máy chủ sản xuất trước đó, Apache đã được biên dịch từ mã nguồn và PHP được xây dựng để được chạy như là một mô-đun được chia sẻ động.

Đối với hệ thống sản xuất mới, Server Zend đã được sử dụng để thay thế và tiện ích quản lý gói của hệ điều hành được phép xử lý gói và các bản nâng cấp Apache (http). Người ta đã chọn cách này vì những lý do sau đây.

  • Zend Server là một bản phân phối nhị phân của PHP để tự động cấu hình máy chủ web Apache. Nó được hỗ trợ và đã được thử nghiệm trên các bản phân phối Linux mức doanh nghiệp. Việc cài đặt và bảo trì rất dễ dàng theo một định dạng gói để có thể được quản lý bằng công cụ yum trên Red Hat Linux.
  • Zend Server bao gồm các trình điều khiển DB2 và cung cấp một giao diện dựa vào Giao diện người dùng đồ họa (GUI) để cấu hình các phần mở rộng cần thiết.
  • Zend Server cung cấp chức năng giám sát, ghi nhật ký và cảnh báo để mang lại sự hiểu biết tốt hơn về cách hệ thống đang hoạt động.

Bài báo "Tạo ra một môi trường phát triển PHP trên đám mây" của Daniel Krook trên developerWorks cung cấp thêm chi tiết về cách cài đặt và cấu hình DB2 với Zend Server (xem phần Tài nguyên). Bài này đã đi theo một quá trình giống hệt.

Hình 2 cho thấy hệ thống sau khi đã thay thế MySQL bằng DB2 và hệ thống đã nâng cấp lên Zend Server. Miếng ghép còn thiếu cuối cùng là cài đặt phần mềm Cognos Business Intelligence của IBM dựa trên web, để thay thế cho công cụ Hyperion Brio di sản chạy trên máy tính để bàn, đã được cấu hình để tạo ra các phân tích từ cơ sở dữ liệu DB2 mới. Bạn có thể tìm hiểu thêm về cách cài đặt Cognos bằng cách tham khảo các liên kết đến các sản phẩm trong phần Tài nguyên.

Hình 2. Cấu trúc liên kết máy chủ và phần mềm mới
Người dùng cuối nối đến máy chủ web Apache, được nối tới các máy chủ MySQL trên Linux, để cung cấp cho bản sao. Người dùng báo cáo được nối tới bản sao qua hệ thống Cognos.

Bước 2: Chuẩn bị một chiến lược giám sát ứng dụng

Nếu bạn đang di trú từ một hệ thống sản xuất hoàn thiện, bạn có thể có một cơ chế báo cáo lỗi đang tồn tại. Trong trường hợp này, do có sử dụng tầng trừu tượng của cơ sở dữ liệu PDO trong PHP, nên vẫn có thể tiếp tục sử dụng hệ thống hiện có để thông báo cho các quản trị viên biết các vấn đề trong mã. Ở mức cơ sở dữ liệu, DB2 Health Monitor (Bộ theo dõi sức khỏe của DB2) được sử dụng để đưa ra các cảnh báo dựa vào lúc các ngưỡng cụ thể đã đạt đến hay vượt quá giới hạn quy định. Bước này liên quan đến các bước con sau đây.

Ngoài các hiểu biết sâu hơn do mã báo cáo lỗi tùy chỉnh cung cấp, trường hợp sử dụng này cũng được hưởng lợi từ việc theo dõi và phân tích chi tiết mịn hơn nhờ việc chuyển đổi sang Zend Server.

Cấu hình cơ chế báo cáo lỗi PHP

Dù bạn phát triển và thử nghiệm cẩn thận đến mấy đi nữa, thì bạn vẫn có cơ hội phát sinh các lỗi không lường trước được trong sản xuất. Ứng dụng này đã luôn kết hợp một tính năng gỡ lỗi tự động hiệu quả. Nếu ứng dụng web gặp một lỗi, nó sẽ thu thập tất cả các thông tin về bối cảnh lỗi và gửi một email đến những người phụ trách phát triển để họ có thể ngay lập tức nhận biết và sửa chữa lỗi. Điều này đặc biệt có ích với một ứng dụng vừa được di trú sang DB2. Bạn có thể tính đến các mã trạng thái và các mã lỗi SQL của DB2 chi tiết để giúp một nhà phát triển trong việc gỡ lỗi.

Trường hợp sử dụng này dựa vào cơ chế báo cáo lỗi của ứng dụng được hiển thị ở trên trong Hình 2 và nhờ vào việc thiết lập các ngưỡng với cơ sở dữ liệu để nó gửi các thông báo cơ sở dữ liệu cụ thể. Trong trường hợp các ngưỡng này đã bị vượt qua, DB2 Health Monitor sẽ gửi đi các thông báo email để cho biết có một vấn đề tiềm ẩn.

Việc thu nhận thông tin về lỗi và hiệu năng kịp thời là rất quan trọng. Ứng dụng này đã thực hiện hai loại thông báo email sau đây trong mã PHP dùng cho mục đích này.

  • Gửi email cho nhóm bảo trì khi xuất hiện bất kỳ các lỗi SQL nào.
  • Gửi email cho nhóm bảo trì khi chạy bất kỳ trang nào kéo dài hơn 60 giây.

Để bắt giữ lỗi SQL, một lớp truy cập cơ sở dữ liệu đã được triển khai thực hiện để cung cấp một loạt các phương thức thi hành tất cả truy vấn ứng dụng. Tất cả câu lệnh SQL đã được định tuyến qua lớp này và các phương thức của nó, sao cho có thể thực hiện các câu lệnh SQL bên trong một khối try/catch. Khi xuất hiện các lỗi, lớp này có thể thu thập thông tin dò vết đầy đủ và gửi thông tin đó cho nhóm bảo trì. Trong các email như vậy có các thông tin sau đây: mã lỗi và thông báo lỗi từ DB2, câu lệnh SQL được thi hành, dò vết ngăn xếp PHP và tài khoản người dùng cuối đã gọi hoạt động đó. Với thông tin này, nhóm bảo trì có thể cô lập các lỗi và giải quyết vấn đề.

Liệt kê 1 cho thấy một đoạn mã của lớp truy cập cơ sở dữ liệu PHP, nơi câu lệnh SQL được thực hiện trong một giao dịch PDO và để bắt giữ bất kỳ các vấn đề nào qua một PDOException.

Liệt kê 1. Mã PHP ví dụ mẫu để bẫy và báo cáo các lỗi cơ sở dữ liệu khi sử dụng PDOException
<?php
// Database query or update specified by the application.
// $query = ...
Database::beginTransaction();

try {                     
	$res = Database::getRawResource()->prepare($query);
	Database::$affectedRows = 0;
	foreach ($data as $itemData) {
		Database::$queryCount++;
		if (!$res->execute($itemData)) {
			throw new PDOException("Could not execute query: $query");
		}
		Database::$affectedRows += $res->rowCount();
		$res->closeCursor();
	}
	
} catch (PDOException $e) {  
	Database::rollback();
	$error = new error("Database error: " . $e->getMessage(), 0, $query);
	if (true == Config::get('DB', 'DIE')) {
		// Captures full trace error info and sends notification.
		$error->nicedie(); 
		return $error;	
	}	
}

Database::commit();

Trong trường hợp thực hiện không tốt mã và các truy vấn, kịch bản lệnh này bắt giữ lại thời gian thực hiện với mỗi trang. Kịch bản lệnh ghi lại thời gian bắt đầu trước khi thực hiện logic nghiệp vụ chính và ghi nhận thời gian kết thúc sau khi nội dung chính được hiển thị, rồi đánh giá toàn bộ giao dịch đã mất bao lâu. Nếu giao dịch kéo dài hơn 60 giây, thì kịch bản lệnh này sẽ gửi ra thông báo email cùng với dò vết ngăn xếp PHP, các tham số được gửi cùng với yêu cầu HTTP, thông tin trình duyệt và tài khoản người dùng cuối đã gọi hoạt động này.

Liệt kê 2 cho thấy kịch bản lệnh PHP có sử dụng hằng số ngưỡng cấu hình (60 giây) và gửi một thông báo đến địa chỉ email của quản trị viên đã định

Liệt kê 2. Mã PHP ví dụ mẫu để bắt giữ lại thời gian thực hiện kịch bản lệnh
<?php
// This static function returns the current UNIX timestamp as microseconds.
function getmicrotime() {
	list($usec, $sec) = explode(" ", microtime());
	return ((float) $usec + (float) $sec);
}

$starttime = getmicrotime();

// Main PHP code for current page executes here.
// ......

$endtime = getmicrotime();

if(($starttime - $endtime) >= $CONFIG['DEBUG']['EXECUTION_THRESHOLD']) {
	$message = "Execution time > ".$CONFIG['DEBUG']['EXECUTION_THRESHOLD'].":\n\n";
	$message .= Error::createReport();
	Mailer::textmail(
		$CONFIG['DEBUG']['EXECUTION_MAIL'], 
		'Execution time greater than '. $CONFIG['DEBUG']['EXECUTION_THRESHOLD'] . 
		' seconds', $message
	);   
}

Xác định các thiết lập bảo trì DB2

Khi bạn chuẩn bị cơ sở dữ liệu của mình, bạn sẽ muốn bảo đảm rằng các thiết lập bảo trì trong DB2 phù hợp với nhu cầu của mình. Một cấu hình ví dụ được hiển thị trong Bảng 1. Các thiết lập này giúp cân đối giữa việc tự động hóa nhiều sự thay đổi cấu hình DB2 thường lệ cho khớp với tải công việc nhưng vẫn mang lại nhiều quyền kiểm soát sao lưu dự phòng và sao chép hơn.

Bảng 1. Các thiết lập bảo trì DB2
Mô tảThiết lậpGiá trị
Bảo trì tự độngAUTO_MAINTOn (Bật)
Sao lưu dự phòng cơ sở dữ liệu tự độngAUTO_DB_BACKUPOff (Tắt)
Bảo trì bảng tự độngAUTO_TBL_MAINTOn (Bật)
Ghi dữ liệu thống kê tự độngAUTO_RUNSTATSOn (Bật)
Số liệu thống kê báo cáo tự độngAUTO_STMT_STATSOn (Bật)
Lược tả số liệu thống kê tự độngAUTO_STATS_PROFOff (Tắt)
Các bản cập nhật lược tả tự độngAUTO_STATS_PROFOff (Tắt)
Tổ chức lại tự độngAUTO_STATS_PROFOn (Bật)

Xác nhận các giá trị thiết lập sao lưu và sao chép DB2

Để sử dụng lại các kịch bản lệnh sao lưu dựa trên lịch biểu thời gian từ hệ thống MySQL cũ và hệ thống lưu trữ để tuân theo một chính sách lưu giữ dữ liệu tùy chỉnh, bạn có thể vô hiệu hóa việc sao lưu cơ sở dữ liệu tự động trong DB2 như đã thấy ở trên trong Bảng 1.

Như đã lưu ý trong Phần 2, bạn có thể cấu hình cơ sở dữ liệu chủ của mình và cơ sở dữ liệu sao chép để duy trì đồng bộ bằng cách sử dụng SQL Replication (Sao chép SQL). Chính sách này đã được áp dụng và cơ sở dữ liệu bản sao đã được điền với các dữ liệu từ cơ sở dữ liệu chủ bằng cách chạy lại các câu lệnh SQL từ bản ghi nhật ký.

Chương 9 của Hướng dẫn chuyển đổi MySQL sang DB2, trong phần Tài nguyên, đưa ra nhiều chi tiết hơn về các chiến lược sao lưu, phục hồi và sao chép. Hãy sử dụng tài liệu này để tìm ra giải pháp phù hợp với bạn.


Bước 3: Triển khai ứng dụng đã cập nhật

Trong bước này, bạn đặt những mảnh ghép cuối cùng của việc triển khai vào vị trí và làm cho hệ thống mới có sẵn cho những người dùng. Khi bạn thực hiện di trú dữ liệu và mã, bạn sẽ bắt đầu hình thành một ý tưởng về ngày phát hành thích hợp. Dựa trên kế hoạch dự án ban đầu trong trường hợp sử dụng này, người ta đã ước tính là nó kéo dài khoảng ba tháng kể từ ngày bắt đầu dự án. Đánh giá này về công việc còn lại cũng đã phù hợp với các nhu cầu của doanh nghiệp để bảo đảm rằng sự ra mắt sẽ gây ra gián đoạn ít nhất cho những người dùng toàn cầu. Bước này liên quan đến các bước con sau đây.

Lập lịch biểu một ngày triển khai

Để bảo đảm triển khai thành công, hãy chọn một ngày sao cho là tốt nhất với những người dùng và nhân viên hỗ trợ. Để giảm thiểu ảnh hưởng đến những người dùng, hãy triển khai vào một ngày cuối tuần, vào quãng thời gian trong năm khi mà các công việc trọng yếu dự kiến sẽ không xảy ra, chẳng hạn như khi khóa sổ các báo cáo ở cuối một quý tài chính hoặc trước lúc khởi chạy một sản phẩm chính. Đối với trường hợp sử dụng này, người ta đã chọn một ngày cuối tuần khi tất cả các kiến trúc sư, các nhà phát triển và các quản trị viên cơ sở dữ liệu có thể rảnh rỗi, cùng với một số các bên liên quan chính. Thậm chí nếu bạn đang lạc quan rằng việc di trú sẽ chỉ mất một vài giờ, thì hãy để dành nhiều thời gian để xử lý các vấn đề.

Trường hợp sử dụng này đã bắt đầu vào một buổi tối thứ Sáu sau giờ làm việc ở Mỹ, tương ứng với sáng thứ bảy ở Trung Quốc, nơi đặt trụ sở của nhóm phát triển. Điều đó hóa ra lại là một ý tưởng tốt, vì có một số vấn đề đã xảy ra và phải mất một thời gian để giải quyết. Những vấn đề này đã không liên quan đến việc di trú cơ sở dữ liệu hoặc mã, mà là do người ta đã không để ý đến các bộ phận khác của hệ thống, ví dụ như các quy tắc tường lửa và các giấy phép của hệ điều hành, vì người ta đã không nghĩ rằng những thay đổi của môi trường sẽ ảnh hưởng đến chúng.

Bắt giữ lại các ảnh hệ thống hiện có và hệ thống mới

Như bạn đã thấy trong các phần khác của loạt bài này, xem phần Tài nguyên, điều quan trọng là bắt giữ lại các ảnh máy ảo thích hợp hoặc các bản sao lưu của cơ sở hạ tầng hiện có của bạn và để tạo ra các bản sao mà bạn muốn triển khai. Điều này sẽ làm cho quá trình hỗ trợ việc triển khai của bạn trở nên dễ dàng hơn khi có vấn đề xảy ra và nó sẽ cho phép bạn nhân bản hệ thống mới, đã trở thành mã sản xuất của bạn để sử dụng làm vạch chuẩn cho sự phát triển trong tương lai.

Triển khai dữ liệu DB2

Trước hết hãy cài đặt dữ liệu đã cập nhật trên máy chủ dữ liệu chủ bằng cách sao lưu cơ sở dữ liệu máy chủ phát triển ổn định của bạn và khôi phục lại nó trên cơ sở dữ liệu sản xuất mới. Hãy trích ra cơ sở dữ liệu từ hệ thống phát triển bằng cách sử dụng lệnh BACKUP. Liệt kê 3 cho thấy cách tạo ra kho lưu trữ để di trú dữ liệu.

Liệt kê 3. Sao lưu cơ sở dữ liệu để di trú vào sản xuất
db2 BACKUP DATABASE PTT

Liệt kê 4 cho thấy cách tạo ra một cơ sở dữ liệu rỗng trên máy chủ DB2 chính cho sản xuất. Hãy tham khảo Phần 2 của loạt bài này để tìm hiểu lý do tại sao lại sử dụng các tùy chọn cấu hình cụ thể này.

Liệt kê 4. Tạo cơ sở dữ liệu DB2 trong sản xuất
db2 "CREATE DATABASE PTT
USING CODESET UTF-8
TERRITORY US
COLLATE USING UCA500R1_S1
PAGESIZE 4096"

Như đã lưu ý ở trên, nếu bạn đang di chuyển qua các nền tảng, phương thức sao lưu và phục hồi này sẽ không hoạt động. Thay vào đó, bạn sẽ cần tải cấu trúc cơ sở dữ liệu và các đối tượng thông qua DDL và nhập khẩu dữ liệu riêng biệt. Xem lại Phần 2 của loạt bài này để tìm hiểu thêm về việc tải dữ liệu.

Sau khi cài đặt ứng dụng và kiểm tra chức năng của ứng dụng, hãy chạy bắt giữ lại và áp dụng các công việc để thiết lập việc sao chép. Xem lại Phần 2 của loạt bài này để tìm hiểu thêm về việc cách cấu hình sao chép.

Liệt kê 5 cho thấy cách di chuyển dữ liệu trên máy chủ DB2 sản xuất chính bằng cách sử dụng lệnh RESTORE.

Liệt kê 5. Phục hồi cơ sở dữ liệu vào sản xuất
db2 RESTORE DB PTT TAKEN AT 20100101090000 INTO PTT REPLACE EXISTING

Vào lúc này, bạn sẽ có cơ sở dữ liệu chức năng đầy đủ. Hãy kiểm tra xem dữ liệu có đúng không bằng một số bài kiểm tra chất lượng như đề xuất trong Chương 10 của Hướng dẫn chuyển đổi MySQL sang DB2, trong phần Tài nguyên.

Triển khai mã PHP

Bây giờ đến thời điểm quan trọng. Nếu bạn đã dùng cách tiếp cận tương tự như trường hợp sử dụng này đã làm, ở đây một hệ thống mới được xây dựng độc lập với hệ thống cũ, thì việc triển khai gồm có việc chuyển hướng lưu lượng từ một hệ thống này sang một hệ thống khác và bảo đảm rằng mọi sự truyền thông giữa các máy chủ ứng dụng và các máy chủ dữ liệu là đúng và hoạt động tốt.

Giám sát hệ thống mới

Những giờ và những ngày sau khi triển khai là quan trọng nhất. Điều vô cùng quan trọng là cần bảo đảm rằng bạn giám sát các kiểu hoạt động có ảnh hưởng đến cơ sở dữ liệu. Như với bất kỳ hệ thống cơ sở dữ liệu khác nào, nếu do một lỗi logic nào đó, bạn đang tạo ra dữ liệu xấu hoặc sửa đổi sai dữ liệu sẵn có, thì có thể rất khó để phục hồi hoàn hảo khi thời gian trôi qua. Bạn có thể phải tắt mạng của hệ thống để ngăn không cho mã lỗi gây thêm các vấn đề nữa và bạn có thể phải chạy một số kịch bản lệnh hiệu chỉnh để sửa chữa dữ liệu đã bị sửa đổi sai.

Vì vậy, nếu bạn chọn một cửa sổ thời gian triển khai vào đêm khuya, hãy chắc chắn rằng bạn đã phân phối đủ thời gian sau khi triển khai cho nhóm làm việc để xử lý bất kỳ những vấn đề nào có thể phát sinh. Chẳng có cảm giác nào tệ hơn là triển khai một bản cập nhật lớn, vội vã gọi nó là thành công, rồi bị đánh thức vào lúc 3 giờ sáng bằng một cuộc gọi điện thoại hoặc một số email từ những người dùng đang báo là có các vấn đề cần phải ngừng hoạt động ngoài kế hoạch và cần nhiều thay đổi sâu rộng để hồi phục lại.


Bước 4: Xử lý hỗ trợ liên tục

Điều quan trọng là phải giám sát hệ thống cẩn thận ngay cả sau khi hệ thống đã đạt được một trạng thái ổn định trong nhiều giờ và nhiều ngày sau khi triển khai thành công. Bước này liên quan đến các bước con sau đây.

Chương 10 của Hướng dẫn chuyển đổi MySQL sang DB2, trong phần Tài nguyên, cung cấp thêm các chi tiết về các kỹ thuật chẩn đoán và khắc phục sự cố.

Đáp ứng hoặc tránh các vấn đề hiệu năng

Như đã lưu ý ở trên, việc đáp ứng với các cảnh báo lỗi do hệ thống phát ra rất quan trọng, cũng như việc chủ động xác định vấn đề và xác định xu hướng thông qua sự phân tích bản ghi nhật ký. Trong trường hợp này, người ta biết rằng sẽ có một sự gia tăng đột biến về số người dùng vào mỗi buổi sáng từ 8 đến 10 giờ sáng theo giờ chuẩn ở miền Đông Bắc Mỹ (EST) và vào những thời điểm tương tự với những người dùng khác trên toàn thế giới khi một ngày làm việc bắt đầu. Khoảng thời gian chạy kịch bản lệnh và việc khóa leo thang được giám sát chặt chẽ để bảo đảm tải công việc được xử lý một cách nhanh chóng và chính xác.

Ví dụ, từ một phân tích, người ta nhận ra rằng một truy vấn chậm khác thường không cần phải nối nhiều bảng cơ sở dữ liệu đến thế. Trong một truy vấn khác, việc cô lập sự tranh chấp của nó đã quá cứng nhắc. Bạn có thể tìm thấy vấn đề, nơi các truy vấn của bạn cho phép đọc ảo hoặc những sự không nhất quán khác. Hãy chắc chắn để giữ cho những đường dây liên lạc của bạn với những người dùng luôn mở để cho họ biết khi nào và làm thế nào để báo cáo về các vấn đề đáng ngờ. Sau đó, bạn có thể áp dụng một số kỹ thuật tương tự để tối ưu hóa hệ thống mà bạn sử dụng trong Phần 3 của loạt bài này.

Cấu hình lại khi kích thước của dữ liệu và luồng công việc phát triển

Tất cả các ứng dụng đều đi theo một vòng đời chung. Chúng được triển khai, chúng được duy trì và chúng được gỡ bỏ khỏi dịch vụ. Trong suốt vòng đời này, chúng cũng đi qua vô số các bước cải tiến dần dần. Tương tự như vậy, các ứng dụng của bạn sẽ cần được giám sát và cải thiện.

May mắn thay DB2 cung cấp cho bạn nhiều công cụ để giúp bạn trong các nỗ lực bảo trì của mình. Hãy tìm hiểu chúng, sử dụng chúng và biết cần hỏi ở đâu khi bạn đang gặp phải một vấn đề. Nhiều khả năng là những người dùng DB2 đồng nghiệp của bạn đã gặp phải một tình huống tương tự. IBM có thể đưa ra sự hỗ trợ cho bạn khi bạn gặp phải tình huống đó.

Trong trường hợp này, các nhà phát triển có xu hướng theo dõi các trang web và các diễn đàn được liệt kê trong mục "Thảo luận" trong phần Tài nguyên. Việc này giúp họ theo kịp các bản cập nhật bảo mật và các bản vá lỗi cho DB2 và tìm hiểu về các tính năng mới, có thể phù hợp với các nhu cầu hiện tại của họ.


Các kết quả di trú

Đối với trường hợp sử dụng này, ngay sau khi triển khai ứng dụng, người ta đã xác định rằng nhiều lợi ích được kỳ vọng đã thành hiện thực. Cụ thể là, đã nhận được các tác động đến quy trình nghiệp vụ đã được cải thiện như dự kiến vì hệ thống cơ sở dữ liệu có thể cung cấp chính xác các số liệu đo lường quan trọng để dẫn dắt hướng hoạt động nghiệp vụ. Trường hợp sử dụng này cũng được đặt ở vị trí tốt hơn để chọn dùng các tính năng cơ sở dữ liệu tiên tiến trong DB2, có tác động đến hiệu năng và khả năng mở rộng quy mô trong tương lai khi dữ liệu tăng trưởng thêm, chẳng hạn như khả năng mở rộng quy mô lớn nhất, bảo đảm an toàn mức chi tiết hơn, lưu trữ XML nguyên gốc và nén dữ liệu.

Lợi ích của Cognos Business Intelligence

Di chuyển sang DB2 cho phép chúng ta bắt đầu sử dụng Cognos để tạo báo cáo. Điều này cho phép chúng ta tạo ra các báo cáo trên web và kiểm soát những người dùng nào có thể xem các báo cáo đó. Quá trình tạo báo cáo một tuần một lần trước đây sẽ cần đến gần 16 giờ để thực hiện một truy vấn, chuyển đổi dữ liệu thành các biểu đồ trực quan và rút ra các kết luận có ý nghĩa. Đây cũng là một quá trình thủ công và dễ bị lỗi, thường đe dọa việc phân phối kịp thời các thông tin chính xác lên ban quản lý cấp trên, dẫn đến làm giảm sự nhanh nhẹn trong việc đáp ứng với các điều kiện kinh doanh thay đổi.

Với hệ thống mới, các báo cáo chính xác có thể được chạy dưới 6 giờ, do nhà phân tích nghiệp vụ không cần có một nguồn tài nguyên kỹ thuật chuyên dụng để chạy báo cáo nữa. Hơn nữa, càng nhiều người dùng có thể xem thông tin liên quan đến họ với mức kiểm soát truy cập lớn hơn và tác động lên nó để hoàn thành mục tiêu kinh doanh của họ càng hiệu quả hơn.

Ngoài ra, với hệ thống cũ, những người dùng cuối sẽ phải tải về các tệp báo cáo lớn, có thể mất 10 phút hoặc nhiều hơn cho mỗi tệp. Và, dữ liệu đó đã chỉ chính xác cho đến thời điểm khi chạy báo cáo. Với hệ thống mới, người dùng có thể truy cập các báo cáo một cách nhanh chóng bằng một trình duyệt web. Trong khi một số báo cáo vẫn còn là các ảnh chụp nhanh ở một thời điểm cụ thể, thì hầu hết các báo cáo hiện nay là thời gian thực, do đó người dùng có thể thấy thông tin cập nhật mới nhất bất cứ khi nào họ chọn báo cáo.

Cải thiện chất lượng dữ liệu

Với các quy tắc nghiệp vụ buộc phải thực hiện trong cơ sở dữ liệu bằng cách kiểm tra những ràng buộc và các mối quan hệ thể hiện qua khóa, bây giờ hệ thống ngăn không để cho các vấn đề về toàn vẹn dữ liệu làm hỏng cơ sở dữ liệu. Điều này dẫn đến dữ liệu có chất lượng tốt hơn. Trong quá khứ, việc sửa chữa thủ công vài ba điểm không nhất quán dữ liệu mỗi tuần là điều bình thường. Hiện nay không có báo cáo vấn đề hàng tháng, hạ tổng số báo cáo hàng tháng từ 12 xuống 0 trong quý đầu tiên sau khi triển khai, tiết kiệm nhiều giờ nỗ lực phát triển và cải thiện niềm tin của người dùng cuối vào hệ thống.

Tác động tối thiểu đến trải nghiệm của người dùng

Việc di trú đã không ảnh hưởng đến những người dùng ngoài cửa sổ thời gian triển khai vào cuối tuần đầu khi hệ thống vẫn chưa có sẵn. Sự ngừng hoạt động theo kế hoạch này cũng tương tự như bất kỳ sự ngừng hoạt động khác nào mà họ đã được thông báo để triển khai các phiên bản ứng dụng mới hoặc xử lý bảo trì và các bản nâng cấp hệ thống thường kỳ, do đó đạt được một hệ thống chất lượng tốt hơn mà không cần có sự thỏa hiệp nào từ góc nhìn của người dùng cuối.

Hiệu năng và giám sát tốt hơn

Với mảng rộng lớn các tính năng tự trị có sẵn và bộ công cụ kèm theo với DB2, bạn có thể nhận biết và giải quyết các vấn đề với ứng dụng của mình nhanh hơn là trên một hệ thống dựa vào MySQL. Bạn có khả năng để cho chính DB2 tự động điều chỉnh hoặc cảnh báo cho bạn trước khi chạm đến các ngưỡng quan trọng.

Bảo trì dễ dàng hơn

Đối với trường hợp sử dụng này, khi cần có sự can thiệp của quản trị viên cơ sở dữ liệu để thêm các chỉ mục mỗi tháng một lần, thì bây giờ người ta đã áp dụng các bản vá lỗi hiệu năng mỗi quý một lần hoặc ít hơn.

Thêm các tuỳ chọn để sử dụng các giải pháp của IBM

Bên cạnh khả năng sử dụng Cognos Business Intelligence sau khi di trú sang DB2, có một hướng đi rõ ràng để bắt đầu làm là liệu bao giờ bạn quyết định di chuyển từ PHP sang một giải pháp Java EE dựa trên WebSphere trong tương lai. Người ta cũng có thể hy vọng tìm ra sự tích hợp đơn giản với các chồng phần mềm của IBM khác nhau và các dịch vụ cơ sở hạ tầng và các dịch vụ nền tảng điện toán đám mây của IBM.


Kết luận

Mục đích của loạt bài này là cung cấp một sự hiểu biết về những điều cần thiết nói chung để di trú một ứng dụng PHP từ MySQL sang DB2, những tài nguyên nào có sẵn để giúp bạn và nhiệm vụ này đã được thực hiện thành công ra sao đối với ứng dụng trong một trường hợp sử dụng.

Trong Phần 1 của loạt bài này, bạn đã làm những việc sau.

  • Đã học về các động lực, các rủi ro và các lợi ích của một nghiên cứu sâu về chuyển đổi ứng dụng Intranet của IBM.
  • Đã học từ kinh nghiệm về trường hợp sử dụng này để thu thập các tài liệu để tìm hiểu DB2 và để hiểu những gì cần thiết với một cuộc di trú MySQL.
  • Đã học về các công cụ để có thể giúp bạn thực hiện cuộc di trú.
  • Đã học về cách có thể tập hợp lại tất cả tài nguyên với nhau để hướng dẫn bạn qua từng giai đoạn của dự án.

Trong Phần 2 của loạt bài này, bạn đã làm những việc sau.

  • Đã học về cơ sở dữ liệu nguồn MySQL mà bạn đã chuyển đổi.
  • Đã học cách chuyển đổi cấu trúc cơ sở dữ liệu sang DB2.
  • Đã học cách di trú dữ liệu sang DB2.
  • Đã học cách thiết lập quản trị cơ sở dữ liệu.

Trong Phần 3 của loạt bài này, bạn đã làm những việc sau.

  • Đã học về mã nguồn PHP mà bạn đã chuyển đổi.
  • Đã học cách cập nhật ứng dụng cho DB2.
  • Đã học cách thử nghiệm và điều chỉnh mã sau khi bạn đã chuyển đổi nó.

Trong phần cuối cùng của loạt bài về triển khai ứng dụng của bạn, bạn đã làm những việc sau.

  • Đã học cách chuẩn bị và triển khai ứng dụng theo cấu trúc liên kết dựa trên DB2.
  • Đã học cách thực hiện sự hỗ trợ liên tục để dò vết các vấn đề trong hệ thống mới của bạn.
  • Đã học về những lợi ích đã thu được từ lúc bắt đầu làm dự án di trú này.

Hy vọng rằng loạt bài này đã giúp bạn lập kế hoạch riêng của mình để di trú MySQL sang DB2 và đã cung cấp thông tin để hướng dẫn bạn theo từng bước di trú, với các hiểu biết tốt đã thu được khi thực hiện cuộc di trú trong trường hợp sử dụng này.

Để giúp xác định một cách tiếp cận phù hợp với bạn, hãy tham khảo bài Hướng dẫn chuyển đổi MySQL sang DB2, trong phần Tài nguyên hoặc liên hệ với Văn phòng dự án di trú phần mềm (SMPO) để nhận được một đánh giá di trú miễn phí. Trong phần Tài nguyên đã cung cấp các liên kết đó.


Lời cảm ơn

Các tác giả cảm ơn Leons Petrazickis và Ambrish Bhargava đã đọc lại và góp ý kiến cho bài này.

Tài nguyên

Học tập

Lấy sản phẩm và công nghệ

Thảo luận

Bình luận

developerWorks: Đăng nhập

Các trường được đánh dấu hoa thị là bắt buộc (*).


Bạn cần một ID của IBM?
Bạn quên định danh?


Bạn quên mật khẩu?
Đổi mật khẩu

Bằng việc nhấn Gửi, bạn đã đồng ý với các điều khoản sử dụng developerWorks Điều khoản sử dụng.

 


Ở lần bạn đăng nhập đầu tiên vào trang developerWorks, một hồ sơ cá nhân của bạn được tạo ra. Thông tin trong bản hồ sơ này (tên bạn, nước/vùng lãnh thổ, và tên cơ quan) sẽ được trưng ra cho mọi người và sẽ đi cùng các nội dung mà bạn đăng, trừ khi bạn chọn việc ẩn tên cơ quan của bạn. Bạn có thể cập nhật tài khoản trên trang IBM bất cứ khi nào.

Thông tin gửi đi được đảm bảo an toàn.

Chọn tên hiển thị của bạn



Lần đầu tiên bạn đăng nhập vào trang developerWorks, một bản trích ngang được tạo ra cho bạn, bạn cần phải chọn một tên để hiển thị. Tên hiển thị của bạn sẽ đi kèm theo các nội dung mà bạn đăng tải trên developerWorks.

Tên hiển thị cần có từ 3 đến 30 ký tự. Tên xuất hiện của bạn phải là duy nhất trên trang Cộng đồng developerWorks và vì lí do an ninh nó không phải là địa chỉ email của bạn.

Các trường được đánh dấu hoa thị là bắt buộc (*).

(Tên hiển thị cần có từ 3 đến 30 ký tự)

Bằng việc nhấn Gửi, bạn đã đồng ý với các điều khoản sử dụng developerWorks Điều khoản sử dụng.

 


Thông tin gửi đi được đảm bảo an toàn.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=70
Zone=Information Management, Nguồn mở
ArticleID=863559
ArticleTitle=Di chuyển ứng dụng PHP từ MySQL sang DB2, Phần 4: Triển khai ứng dụng của bạn
publish-date=04022013