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

Chia sẻ: Nhung Nhung | Ngày: | Loại File: PDF | Số trang:20

Thêm vào BST

Báo xấu

66
lượt xem 3
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

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.

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

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

Di chuyển ứng dụng PHP từ MySQL sang DB2 Phần 4: Triển khai ứng dụng của bạ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. Về đầu trang
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 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. Về đầu trang 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. Về đầu trang 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.  Cấu hình các máy chủ dữ liệu DB2 chính và bản sao.  Cấu hình máy chủ ứng dụng PHP. 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 Về đầu trang 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.  Cấu hình cơ chế báo cáo lỗi PHP  Xác định các thiết lập bảo trì DB2  Xác nhận các thiết lập sao lưu dự phòng và sao chép DB2 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
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
$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ập Giá trị Bảo trì tự động AUTO_MAINT On (Bật) Sao lưu dự phòng cơ sở dữ liệu tự độngAUTO_DB_BACKUP Off (Tắt) Bảo trì bảng tự động AUTO_TBL_MAINT On (Bật) Ghi dữ liệu thống kê tự động AUTO_RUNSTATS On (Bật) Số liệu thống kê báo cáo tự động AUTO_STMT_STATS On (Bật) Lược tả số liệu thống kê tự động AUTO_STATS_PROF Off (Tắt) Các bản cập nhật lược tả tự động AUTO_STATS_PROF Off (Tắt) Tổ chức lại tự động AUTO_STATS_PROF On (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. Về đầu trang 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ắt giữ lại các ảnh 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 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. Về đầu trang 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.  Đáp ứng với hoặc tránh các vấn đề hiệu năng  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 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ọ. Về đầu trang 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. Về đầu trang 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 đó.