Giải quyết các vấn đề trong môi trường các dịch vụ cụm của DB2 pureScale

Một cách tiếp cận có hệ thống để thu thập thông tin chẩn đoán và xác định vấn đề

Bài này hướng dẫn các nhà quản trị cơ sở dữ liệu (DBA) và các nhà quản trị hệ thống trong việc xác định vấn đề đối với các dịch vụ cụm IBM® DB2® pureScale® (pureScale DB2 của IBM). Khi bạn triển khai IBM DB2 pureScale Feature (Tính năng pureScale DB2 của IBM) dành cho các hệ thống DB2 Enterprise Server Edition (Ấn bản máy chủ doanh nghiệp DB2) vào sản xuất, bạn cần có các kỹ năng xác định vấn đề thích hợp. Bài này cung cấp thông tin về thu thập thông tin chẩn đoán khi xảy ra các lỗi và cung cấp thêm thông tin để giúp hiểu rõ các thành phần con tích hợp chặt chẽ trong DB2 pureScale Feature, như Cluster Caching Facility (CF - Tiện ích cụm lưu trữ tạm), General Parallel File System (GPFS –Hệ thống tệp song song tổng quát), Reliable Scalable Cluster Technology (RSCT - Công nghệ cụm có khả năng mở rộng tin cậy) và IBM Tivoli Systems Automation for Multiplatforms (Tivoli SA MP - Tự động hóa các hệ thống Tivoli cho Nhiều nền tảng của IBM).

Oleg Tyschenko, Trưởng nhóm phát triển DB2 PureScale, IBM

Oleg Tyschenko lãnh đạo công việc của nhóm phát triển máy DB2 ở Ireland và là một thành viên của nhóm Tính sẵn sàng cao DB2 dành cho phát triển DB2 pureScale. Ông có hơn mười lăm năm kinh nghiệm về chuyên môn và kỹ thuật trong quản lý thông tin và các công nghệ liên quan. Ông hiện đã tham gia một số việc triển khai pureScale DB2 và các dự án tiền khả thi (proof-of-concept) trên khắp châu Âu. Các lĩnh vực chuyên môn của ông gồm DB2 pureScale Feature, tính sẵn sàng cao và quản lý cụm của DB2, Tivoli SA cho Nhiều nền tảng và triển khai GPFS. Oleg có bằng khoa học máy tính và bằng MBA của Trường kinh doanh Warwick (Anh).



Massimiliano Gallo, Kỹ sư thử nghiệm chức năng của DB2, IBM

Massimiliano Gallo là một thành viên cấp cao của nhóm thử nghiệm xác nhận hợp lệ chức năng của DB2 tại Dublin và đã làm về thử nghiệm DB2 pureScale trong nhiều năm qua. Ông có hơn 10 năm kinh nghiệm trong việc phát triển phần mềm và thử nghiệm sản phẩm, đang làm việc trên một loạt các công nghệ khác nhau. Các lĩnh vực chuyên môn của ông gồm DB2 pureScale Feature, tính sẵn sàng cao và quản lý cụm của DB2, Tivoli SA cho Nhiều nền tảng. Massimiliano có bằng Thạc sĩ kỹ thuật hàng không vũ trụ của trường Đại học Sapienza của Rome.



29 06 2012

Trước khi bạn bắt đầu

Giới thiệu

DB2 pureScale Feature của IBM dành cho Enterprise Server Edition cung cấp công nghệ phân cụm để giúp đưa ra tính sẵn sàng cao và khả năng mở rộng đặc biệt trong suốt đến các ứng dụng và mang lại kiến trúc tốt nhất cho nền tảng phân tán. DB2 pureScale Feature cho phép cơ sở dữ liệu tiếp tục xử lý vượt qua các sự cố bất ngờ và cung cấp khả năng hoạt động gần như không hạn chế đối với bất kỳ tải giao dịch nào. Việc mở rộng hệ thống của bạn chỉ đơn giản là vấn đề kết nối một máy chủ và ban hành hai lệnh đơn giản. Kiến trúc đĩa chia sẻ, dựa vào cụm của DB2 pureScale Feature cũng giúp giảm các chi phí thông qua việc sử dụng hiệu quả tài nguyên hệ thống.

DB2 pureScale Feature kết hợp một số thành phần phần mềm tích hợp chặt chẽ, được cài đặt và cấu hình tự động khi bạn triển khai DB2 pureScale Feature. Bạn tương tác với các thành phần như trình quản lý cụm DB2 và các dịch vụ cụm DB2 thông qua các khung nhìn và các lệnh quản trị DB2, như công cụ db2instance, db2icrt, db2iupdtdb2cluster. Công cụ db2cluster cũng cung cấp các tùy chọn để xử lý sự cố và xác định vấn đề. Ngoài ra, các thông báo do các hệ thống con của trình quản lý cụm DB2 tạo ra là một nguồn thông tin tuyệt vời để xác định vấn đề. Ví dụ, các trình quản lý tài nguyên của các lớp tài nguyên được các dịch vụ cụm DB2 sử dụng mỗi lần viết thông tin trạng thái vào các tệp bản ghi nhật ký của chúng. Các tệp bản ghi nhật ký db2diag cũng cung cấp thông tin có ích. Thông thường, các thông báo trong các tệp bản ghi nhật ký db2diag giải thích lý do lỗi và đưa ra lời khuyên về việc cách giải quyết nó.

Các dịch vụ cụm DB2 có thể tự động xử lý phần lớn các lỗi thời gian chạy (runtime). Tuy nhiên, có nhiều kiểu lỗi cụ thể đòi hỏi bạn phải có hành động để giải quyết các lỗi đó. Ví dụ, dây nguồn có thể không cắm vào máy chủ hoặc cáp mạng có thể bị ngắt kết nối. Nếu Các dịch vụ cụm DB2 không thể giải quyết tự động lỗi này, thì một trường hợp cảnh báo được thiết lập để báo cho các DBA biết rằng có một vấn đề đã xảy ra cần phải phải lưu ý đến. Các DBA có thể xem cảnh báo khi họ kiểm tra trạng thái của cá thể DB2, như hiển thị sau.

Hiểu mô hình tài nguyên của DB2 pureScale Feature

Mô hình tài nguyên của DB2 pureScale Feature, Phiên bản 9.8 khác với mô hình tài nguyên được sử dụng trong một cá thể HA DB2 trong các môi trường cơ sở dữ liệu một phân vùng và nhiều phân vùng của Phiên bản 9.7. Để có thêm thông tin về các cá thể HA DB2 trong các phiên bản DB2 có trước DB2 pureScale Feature, Phiên bản 9.8, xin vui lòng tham khảo các liên kết thông tin cơ bản trong phần Tài nguyên ở cuối của bài này.

Mô hình tài nguyên mới được thực hiện trong DB2 pureScale Feature Phiên bản 9.8 là cần thiết để biểu diễn các tiện ích lưu trữ cụm trong bộ nhớ nhanh (CF) và hệ thống tệp có phân cụm chia sẻ.

Trong một cá thể chia sẻ dữ liệu của DB2 pureScale, một CF thực hiện vai trò chính, trong đó có chứa dữ liệu đang hoạt động dành cho cá thể chia sẻ dữ liệu. CF thứ hai duy trì một bản sao thông tin cần thiết cho việc phục hồi vai trò chính ngay lập tức.

Mô hình tài nguyên mới cho phép Tivoli SA MP (IBM Tivoli® System Automation for Multiplatforms - (Tự động hóa hệ thống Tivoli cho Nhiều nền tảng của IBM) tự động hóa một cách thích hợp việc di chuyển vai trò chính trong trường hợp nút CF chính có lỗi.

Các dịch vụ cụm DB2 gồm ba thành phần chính:

  • Trình quản lý cụm: Tivoli SA MP, gồm có RSCT (Công nghệ cụm có khả năng mở rộng tin cậy).
  • Hệ thống tệp có phân cụm chia sẻ: GPFS (Hệ thống tệp song song tổng quát).
  • Quản trị cụm DB2: Các lệnh và các khung nhìn quản trị của DB2 để quản lý và giám sát cụm.
Hình 1. Các dịch vụ cụm DB2
Sơ đồ hiển thị các trạm làm việc của khách được nối đến máy chủ dữ liệu DB2, có CF chính, CF phụ, các thành viên, các dịch vụ cụm DB2 và hệ thống tệp chia sẻ

Các dịch vụ cụm DB2 cung cấp cơ sở hạ tầng thiết yếu cho cá thể chia sẻ dữ liệu để luôn sẵn sàng cao, mang lại khả năng khắc phục lỗi tự động và khởi động lại ngay khi cá thể được tạo ra.

Các phần tử cụm DB2 là biểu diễn của các thực thể được giám sát và các thay đổi trạng thái của chúng được quản lý bởi các dịch vụ cụm DB2. Đối với các mục đích của bài này, chúng ta sẽ đề cập đến ba kiểu phần tử cụm DB2:

  • Các máy chủ: Một máy chủ có thể là một máy tính vật lý, LPAR (phân vùng logic của một máy tính vật lý) hoặc một máy ảo.
  • Các thành viên DB2: Một thành viên DB2 là máy xử lý lõi và thường lưu trú trên máy chủ nhà của nó. Máy chủ nhà của một thành viên DB2 là tên máy chủ được cung cấp như là vị trí của thành viên khi thành viên đó đã được bổ sung vào cá thể chia sẻ dữ liệu DB2. Một thành viên DB2 có một máy chủ nhà duy nhất. Các thành viên DB2 có thể chấp nhận các kết nối máy khách chỉ khi chúng đang chạy trên máy chủ nhà của mình.
  • Các CF (các tiện ích lưu trữ cụm trong bộ nhớ nhanh): CF là một ứng dụng phần mềm do các dịch vụ cụm DB2 quản lý để cung cấp các dịch vụ hoạt động nội bộ cho một cá thể chia sẻ dữ liệu DB2.

Không nhất thiết phải có một ánh xạ một-một giữa các phần tử cụm DB2 và các tài nguyên, nhóm tài nguyên của trình quản lý cụm nằm bên dưới.

Hiểu DB2 pureScale Feature tự động xử lý lỗi như thế nào

Khi có lỗi xuất hiện trong cá thể pureScale DB2, các dịch vụ cụm DB2 cố gắng tự động khởi động lại tài nguyên có lỗi. Việc tiến hành khởi động lại khi nào và ở đâu phụ thuộc vào các nhân tố khác nhau, như kiểu tài nguyên có lỗi và vị trí trong vòng đời của tài nguyên mà tại đó có lỗi xảy ra.

Nếu một lỗi phần mềm hay phần cứng trên máy chủ làm cho một thành viên DB2 không hoạt động, các dịch vụ cụm DB2 tự động khởi động lại thành viên đó. Có thể khởi động lại các thành viên DB2 trên cùng máy chủ (khởi động lại cục bộ) hoặc nếu việc này thất bại, thì khởi động lại trên một máy chủ khác (khởi động lại thành viên trong chế độ khởi động lại nhanh). Việc khởi động lại một thành viên trên máy chủ khác được gọi là chuyển đổi dự phòng.

Việc khởi động lại thành viên bao gồm khởi động lại các quá trình DB2 có lỗi và thực hiện khôi phục cấp tốc thành viên (hủy hoặc áp dụng lại các giao dịch ghi nhật ký) để quay lại bất kỳ giao dịch nào đang hoạt động và giải phóng bất kỳ các khóa nào do chúng nắm giữ. Việc khởi động lại thành viên cũng đảm bảo rằng các trang cập nhật đã được ghi vào CF.

Khi một thành viên được khởi động lại trên một máy chủ khác trong chế độ khởi động lại nhanh, chỉ các tài nguyên tối thiểu được sử dụng trên máy chủ mới (là máy chủ nhà của một thành viên DB2 khác). Một thành viên đang chạy trong chế độ khởi động lại nhanh không xử lý các giao dịch mới, vì mục đích duy nhất của nó là thực hiện phục hồi cấp tốc thành viên. Các cơ sở dữ liệu trên các thành viên có lỗi được khôi phục tới một điểm nhất quán càng nhanh càng tốt. Điều này cho phép các thành viên đang hoạt động khác truy cập và thay đổi các đối tượng cơ sở dữ liệu đã bị các thành viên ngừng hoạt động bất thường khóa lại. Tất cả các giao dịch đang hoạt động của các thành viên ngừng hoạt động được khôi phục lại và tất cả các khóa được nắm giữ vào lúc thành viên ngừng hoạt động bất thường sẽ được giải phóng. Mặc dù thành viên đó không chấp nhận giao dịch mới, nhưng nó vẫn sẵn sàng để giải quyết các giao dịch còn nghi ngờ. Khi một thành viên DB2 đã được chuyển đổi dự phòng sang một máy chủ mới, toàn bộ khả năng xử lý của tổng thể cả cụm tạm thời bị giảm xuống. Khi máy chủ nhà chuyển sang hoạt động và sẵn sàng lại, thành viên DB2 tự động chuyển trở về máy chủ nhà của nó và thành viên DB2 được khởi động lại trên máy chủ của mình. Khả năng xử lý của cụm được phục hồi ngay khi thành viên DB2 đã chuyển đổi trở lại và đã khởi động lại trên máy chủ của mình. Các giao dịch trên tất cả các thành viên DB2 khác không bị ảnh hưởng trong quá trình chuyển trở lại.


Quản lý môi trường cụm dành cho DB2 pureScale Feature

Các dịch vụ cụm DB2 cung cấp các khung nhìn và các lệnh quản trị DB2 để quản lý cụm. Bạn có thể sử dụng các lệnh DB2 để quản lý hệ thống tệp chia sẻ và trình quản lý cụm chứ không phải sử dụng các lệnh Tivoli SA MP hoặc GPFS riêng biệt. Ví dụ, khi bạn tạo một cá thể DB2 và thêm các thành viên DB2 hoặc các CF mới, trình quản lý cơ sở dữ liệu DB2 tự động gọi các hành động thích hợp cho Tivoli SA MP và các GPFS để thiết lập hoặc cập nhật miền ngang hàng khi cần. Miền ngang hàng là một cụm các máy chủ được cấu hình với tính sẵn sàng cao và có thể gồm tất cả các máy chủ trong cụm hoặc có thể là một tập con của các máy chủ trong giải pháp cụm tổng thể. Miền ngang hàng bao gồm các máy chủ làm các đích chuyển đổi dự phòng theo một chính sách quay vòng tròn, để chọn một máy chủ từ một danh sách các máy chủ có sẵn.

Các dịch vụ cụm DB2 giám sát và phản ứng với các lệnh cụm cơ sở dữ liệu khi trình quản lý cơ sở dữ liệu DB2 gọi bất kỳ các hoạt động nào sau đây:

  • Tạo và xóa các tài nguyên cụm, như là một phần của quá trình cài đặt và nâng cấp.
  • Mở rộng hoặc thu gọn trình quản lý cụm và hệ thống tệp chia sẻ để đưa vào các máy chủ bổ sung hoặc giảm bớt số lượng các máy chủ, như là một phần của việc thêm vào hoặc bỏ bớt một máy chủ hoặc một thành viên DB2
  • Dừng cá thể để bảo trì theo kế hoạch do không thể thực hiện bảo trì trực tuyến.

Ví dụ, bạn có thể sử dụng lệnh db2cluster để nhập chế độ bảo trì, lệnh db2icrt để tạo một cá thể DB2 pureScale Feature mới và lệnh db2iupdt để cập nhật cá thể đó.

Việc tiếp tục quản lý các dịch vụ cụm DB2 do lệnh db2cluster cung cấp.

Sử dụng lệnh db2cluster để chẩn đoán và sửa chữa các vấn đề

Trong rất ít trường hợp, mô hình tài nguyên cụm có thể trở nên không nhất quán, đòi hỏi bạn phải can thiệp vào.

Các lệnh db2clusterdb2instance cho phép bạn thu thập thông tin về trạng thái của mô hình tài nguyên.

Trong ví dụ này, mô hình tài nguyên khỏe mạnh:

 > db2cluster -cm -verify –resources Cluster manager
         resource states for the DB2 instance are consistent.

Trong trường hợp này, mô hình tài nguyên không nhất quán:

 > db2cluster -cm -verify –resources Cluster manager
         resource states for the DB2 instance are inconsistent. Refer to the 
         db2diag.log for more information on inconsistencies.

Khi một mô hình tài nguyên không nhất quán, bạn cần xem xét các thông báo trong các tệp ghi nhật ký db2diag để xác định các chi tiết về vấn đề này. Thông thường, các thông báo trong các tệp ghi nhật ký db2diag giải thích lý do có lỗi và đưa ra lời khuyên về vấn đề là gì và cách giải quyết nó. Ví dụ, thông báo này cho thấy rằng tệp db2nodes.cfg có thể đã bị thay đổi thủ công. Nếu đúng như vậy, các hành động được khuyến cáo là quay về phiên bản trước của tệp db2nodes.cfg. Nếu không phải như vậy, thì bạn có thể thấy một hành động được khuyến cáo thay thế là hãy sửa chữa những sự không nhất quán bằng lệnh db2cluster.

Liệt kê 1. Tệp db2diag.log với các thông tin chi tiết về lỗi
2011-05-25-15.01.21.776169+060 E13778E572            LEVEL: Info
PID     : 21058                TID  : 46912898085712 KTID : 21058
PROC    : db2cluster
INSTANCE: db2inst1                NODE : 000
HOSTNAME: hostA
FUNCTION: DB2 UDB, high avail services, sqlhaUISDVerifyResources, probe:0
MESSAGE : Resource verification failed.  Recommendation: if db2nodes.cfg was
          modified, return it to its original form.
DATA #1 : String, 124 bytes
Issue a 'db2cluster -cm -repair -resources' command to fix the inconsistencies 
if the db2nodes.cfg was not manually changed.

Trong nhiều trường hợp, bạn có thể sử dụng công cụ db2cluster để sửa chữa tài nguyên, bằng cách sử dụng lệnh sau đây:

> db2cluster -cm -repair -resources 
All cluster configurations have been completed successfully. db2cluster exiting...

Lưu ý rằng lệnh trên yêu cầu dừng cá thể DB2.

Sau khi mô hình tài nguyên được sửa chữa, trình quản lý cụm trả về trạng thái hoạt động khỏe mạnh bình thường mà không đưa ra bất kỳ cảnh báo nào. Để có thêm thông tin về trạng thái của cụm, bạn có thể sử dụng lệnh sau đây:

Liệt kê 2. Kết quả đầu ra của lệnh db2instance -list
> db2instance -list
ID  TYPE   STATE      HOME_HOST CURRENT_HOST ALERT PARTITION_NUMBER LOGICAL_PORT NETNAME
--  ----   -----      --------- ------------ ----- ---------------- ------------ -------
0   MEMBER STARTED    hostA     hostA        NO    0                0            hostA-ib0
1   MEMBER STARTED    hostC     hostC        NO    0                0            hostC-ib0
128 CF     PRIMARY    hostB     hostB        NO    -                0            hostB-ib0
129 CF     CATCHUP    hostD     hostD        NO    -                0            hostD-ib0

HOSTNAME                   STATE                INSTANCE_STOPPED        ALERT
--------                   -----                ----------------        -----
hostD                      ACTIVE               NO                      NO
hostB                      ACTIVE               NO                      NO
hostC                      ACTIVE               NO                      NO
hostA                      ACTIVE               NO                      NO

Ví dụ trên của kết quả đầu ra db2instance cho thấy trường hợp của một cụm khỏe mạnh, có hai thành viên DB2 và hai CF. Không có cảnh báo trong cụm: tất cả các thành viên DB2 được khởi động và hoạt động trên máy chủ nhà của chúng. CF được biểu diễn bằng Mã định danh (ID) 128 giữ vai trò PRIMARY (chính) và tất cả các máy chủ đang hoạt động, với cá thể DB2 được khởi động trên mỗi máy chủ.

Chúng ta có thể kiểm tra thêm lần nữa là không có cảnh báo nào bằng cách sử dụng lệnh sau:

> db2cluster -cm -list -alert There are no alerts

Bạn có thể kiểm tra trạng thái của các máy chủ trong miền ngang hàng bằng cách sử dụng lệnh sau:

Liệt kê 3. Kết quả đầu ra của db2cluster -list -cm -host -state
> db2cluster -list -cm -host -state
HOSTNAME                    STATE
------------------------    -----------
hostA                       ONLINE
hostB                       ONLINE
hostC                       ONLINE
hostD                       ONLINE

Điều này có nghĩa là miền ngang hàng là đang trực tuyến (online) và hoạt động trên tất cả các máy chủ.

Sử dụng các thông báo và dữ liệu lỗi của hệ thống con để khắc phục các sự kiện quản lý cụm DB2

Để khắc phục sự cố và xác định vấn đề, các thông báo do các hệ thống con của trình quản lý cụm DB2 tạo ra là một nguồn thông tin quan trọng.

Trên các nền tảng Linux, các thông báo được viết vào bản ghi nhật ký hệ thống (/var/log/messages).

Trên các nền tảng AIX, các trình ghi nhật ký hệ thống không được cấu hình theo mặc định và các thông báo được ghi vào các bản ghi nhật ký lỗi. Điều quan trọng là bạn nên cấu hình trình ghi nhật ký hệ thống trong tệp /etc/syslog.conf. Sau khi cập nhật /etc/syslog.conf, bạn phải chạy lệnh refresh –s syslogd.

Các lớp tài nguyên được các thành phần của các dịch vụ cụm DB2 sử dụng được quản lý bằng một loạt các trình quản lý tài nguyên (các RM). Trình quản lý tài nguyên nào có trách nhiệm quản lý một lớp cụ thể nào là phụ thuộc vào lớp đó. Một trình quản lý tài nguyên chạy như một daemon (trình thường trực) được bộ điều khiển tài nguyên hệ thống (SRC) điều khiển. Để biết thêm thông tin về các trình quản lý tài nguyên, xin vui lòng tham khảo Hướng dẫn sử dụng và quản trị Tivoli SA MP. Có sẵn một liên kết trong phần Tài nguyên.

Global Resource RM (IBM.GblResRM)

Trên mỗi nút, Trình quản lý tài nguyên Chung - Global Resource RM (IBM.GblResRM) duy trì một bản ghi kiểm toán trong đó nó ghi lại bất kỳ việc thi hành lệnh khởi động và ngừng nào và các hoạt động thiết lập lại (reset). Global Resource RM chỉ có thể hoạt động trong chế độ miền ngang hàng. Các bản ghi nhật ký của Global Resource RM được đặt trong:

/var/ct/<domain_name>/log/mc/IBM.GblResRM/

Có thể tìm tên miền bằng lệnh db2cluster:

> db2cluster -cm -list -domain Domain Name: db2domain

Để xem bản ghi nhật ký kiểm toán, hãy ban hành lệnh rpttr cục bộ trên một nút:

rpttr -o dtic /var/ct/<domain_name>/log/mc/IBM.GblResRM/trace_summary*

Lưu ý rằng cần có quyền truy cập chủ (root) vào thư mục /var/ct/<domain_name>/log/mc/IBM.RecoveryRM/ để xem các bản ghi nhật ký bằng lệnh rpttr như được hiển thị ở trên. (Để xem các cách tiếp cận thay thế khác, cho phép những người dùng không có quyền truy cập chủ đọc các dò vết với ít đặc quyền hơn, hãy xem Phụ lục A).

Ví dụ sau cho thấy định dạng của thông tin dò vết trong nhật ký kiểm toán:

Liệt kê 4. Tệp dò vết có định dạng
[00] 04/15/11 17:07:43.324891 T(4150437552) ____  ******************* Trace Started - Pid 
= 7268 **********************
[00] 04/18/11 09:08:57.498711 T(4150433456) ____  ******************* Trace Started - Pid 
= 6735 **********************
[00] 04/19/11 11:41:31.832310 T(4128861088) _GBD Monitor detect OpState change for resourc
e Name=instancehost_db2inst1_hostD OldOpState=0 NewOpState=2 Handle=0x6028 0xffff 0xb82b28
63 0x4a725d1a 0x1215ee4e 0xc2f1e0b0
[00] 04/19/11 11:41:32.574276 T(4128861088) _GBD Monitor detect OpState change for resourc
e Name=instancehost_db2inst1_hostD OldOpState=2 NewOpState=1 Handle=0x6028 0xffff 0xb82b28
63 0x4a725d1a 0x1215ee4e 0xc2f1e0b0
[00] 04/19/11 11:42:07.255763 T(4123835296) _GBD Monitor detect OpState change for resourc
e Name=cacontrol_db2inst1_128_hostD OldOpState=0 NewOpState=2 Handle=0x6028 0xffff 0xb82b2
863 0x4a725d1a 0x1215ee57 0x8657b518
[00] 04/19/11 11:42:08.973508 T(4123736992) _GBD Monitor detect OpState change for resourc
e Name=ca_db2inst1_0-rs OldOpState=0 NewOpState=2 Handle=0x6028 0xffff 0xb82b2863 0x4a725d
1a 0x1215ee57 0xc96670b0
[00] 04/19/11 11:42:19.740162 T(4123638688) _GBD Monitor detect OpState change for resourc
e Name=primary_db2inst1_900-rs OldOpState=0 NewOpState=2 Handle=0x6028 0xffff 0xb82b2863 0
x4a725d1a 0x1215ee5a 0x63655418
[00] 04/19/11 11:50:14.697605 T(4123835296) _GBD Monitor detect OpState change for resourc
e Name=cacontrol_db2inst1_128_hostD OldOpState=2 NewOpState=1 Handle=0x6028 0xffff 0xb82b2
863 0x4a725d1a 0x1215ee57 0x8657b518

Lưu ý: Để đọc các dấu vết đã định dạng dễ dàng, bạn có thể chuyển hướng kết quả đầu ra của lệnh rpttr vào một tệp, do đầu ra có chứa một khối lượng đáng kể các hồ sơ ghi nhật ký sự kiện.

Recovery RM (IBM.RecoveryRM)

Trình quản lý tài nguyên Khôi phục - RM Recovery (IBM.RecoveryRM) dùng làm máy quyết định cho Tivoli SA MP. Một RM Recovery chạy trên mỗi máy chủ trong cụm, với một RM Recovery được chỉ định làm chủ. RM Recovery chủ chịu trách nhiệm đánh giá thông tin giám sát và hành động dựa trên thông tin do IBM.GlbResRM cung cấp. Khi một tình huống phát triển đòi hỏi phải can thiệp, RM Recovery điều khiển các quyết định dẫn đến các hoạt động khởi động (start) hay ngừng (stop) các tài nguyên, khi cần.

Các bản ghi nhật ký của Recovery RM được đặt trong:

/var/ct/<domain_name>/log/mc/IBM.RecoveryRM/

Recovery RM chủ duy trì một bản ghi kiểm toán về:

  • Tất cả các yêu cầu.
  • Các đáp ứng lỗi với các yêu cầu.
  • Thông tin về các chính sách hiện hành.
  • Thông tin về các vấn đề kết buộc.

Để xem bản ghi nhật ký, bạn cần phải phát hành lệnh rpttr trên máy chủ có Recovery RM chủ đang chạy. Trước tiên, bạn có thể xác định máy chủ đó bằng cách sử dụng lệnh lssrc, ví dụ:

Liệt kê 5. Kết quả đầu ra của lệnh lssrc
lssrc -ls IBM.RecoveryRM | grep Master

Example output:
   Master Node Name     : hostD (node number =  4)
rpttr -o dtic /var/ct/<domain_name>/log/mc/IBM.RecoveryRM/trace_summary*

Lưu ý rằng cần có quyền truy cập chủ vào thư mục /var/ct/<domain_name>/log/mc/IBM.RecoveryRM/ để xem các bản ghi nhật ký bằng lệnh rpttr như được hiển thị ở trên (Để xem các cách tiếp cận thay thế khác cho phép những người dùng không có quyền truy cập chủ đọc các dò vết với ít đặc quyền hơn, hãy xem Phụ lục A).

Dưới đây là một ví dụ về định dạng tệp dò vết:

Liệt kê 6. Định dạng tệp dò vết
[02] 05/25/11 14:59:25.487143 T(4112939936) _RCD ReportMoveState: Resource : db2_db2inst1_
1-rs/Float/IBM.Application  reported move state change: a000 - preparing: 0
[02] 05/25/11 14:59:25.487651 T(4112939936) _RCD ReportMoveState: Resource : db2_db2inst1_
1-rs/Fixed/IBM.Application/hostA  reported move state change: db2_db2inst1_1-rs/Fixed/IBM.
Application/hostA  reported state change: 2
[02] 05/25/11 14:59:25.488380 T(4112939936) _RCD Offline request injected: db2_db2inst1_0-
rg/ResGroup/IBM.ResourceGroup
[02] 05/25/11 14:59:25.488637 T(4112939936) _RCD ReportMoveState: Resource : db2_db2inst1_
0-rs/Float/IBM.Application  reported move state change: a000 - preparing: 0
[02] 05/25/11 14:59:25.488914 T(4112939936) _RCD ReportMoveState: Resource : db2_db2inst1_
0-rs/Fixed/IBM.Application/hostA  reported move state change: a000 - preparing: 0
[02] 05/25/11 14:59:25.488955 T(4112939936) _RCD ReportState: Resource : db2_db2inst1_0-rs
/Fixed/IBM.Application/hostA  reported state change: 2
[02] 05/25/11 14:59:25.489642 T(4112939936) _RCD Offline request injected: idle_db2inst1_9
97_hostA-rg/ResGroup/IBM.ResourceGroup

Lưu ý: Để dễ đọc các dấu vết đã định dạng, bạn có thể chuyển hướng kết quả đầu ra của lệnh rpttr vào một tệp, do kết quả đầu ra có chứa một khối lượng đáng kể các bản ghi nhật ký sự kiện.

Configuration RM (IBM.ConfigRM)

Trình quản lý tài nguyên Cấu hình - Configuration RM (IBM.ConfigRM) được sử dụng trong DB2 pureScale Cluster Services (Các dịch vụ cụm DB2 pureScale). Ngoài ra, nó giúp đưa ra sự hỗ trợ số tối thiểu cần thiết, một phương tiện đảm bảo tính toàn vẹn dữ liệu khi các phần của một cụm bị mất truyền thông. Configuration RM chỉ cập nhật các bản ghi nhật ký của nó khi trạng thái thay đổi (một sự kiện mới xảy ra). Các bản ghi nhật ký này nằm trong đường dẫn sau:

/var/ct/IW/log/mc/IBM.ConfigRM/

Dịch vụ cấu trúc mạng cụm đăng ký bất kỳ sự thay đổi nào vào một trang thái truyền thông của miền ngang hàng RSCT. Nếu một bộ chuyển đổi mạng được cho là không hoạt động, sự thay đổi trạng thái của bộ chuyển đổi được ghi lại trong các dò vết của Configuration RM. Các bản ghi nhật ký của dịch vụ cấu trúc mạng này được đặt tại đường dẫn sau, ở đây <domain_name> là tên miền của bạn:

/var/ct/<domain_name>/log/cthats

Daemon "hatsd" là daemon chính chịu trách nhiệm về hầu hết công việc trong các dịch vụ cấu trúc mạng. Nó thực hiện việc tổ chức ở cấp cao hơn, bao gồm cả việc thiết lập các vòng nhịp tim (heartbeat rings). Một vòng nhịp tim là một quá trình trong đó mỗi nút gửi một thông báo tới các nút lân cận và hy vọng sẽ nhận được một trả lời từ một trong các nút lân cận khác của nó. Daemon "hatsd" đôi khi có thể không phát hiện được sự thay đổi trạng thái cấu trúc mạng cho Network Interface Module (NIM - Mô đun giao diện mạng), vì thế trước hết bạn nên kiểm tra các bản ghi nhật ký NIM. Các bản ghi nhật ký chính bắt đầu bằng "nim" và chứa tên giao diện đang được giám sát:

nim.cthats.ib0 nim.cthats.ib0.001 nim.cthats.ib0.002 nim.cthats.ib0.003

Thư viện netmon, được NIM sử dụng, giám sát trạng thái của mỗi bộ chuyển đổi (được các quá trình Các dịch vụ cấu trúc mạng NIM sử dụng) để xác định xem bộ chuyển đổi cục bộ có hoạt động không. Tên tệp của bản ghi nhật ký khớp với tên của bản ghi nhật ký NIM cộng thêm tiền tố "nmDiag":

 nmDiag.nim.cthats.ib0.001

Tệp bản ghi nhật ký cho GPFS

GPFS viết cả các thông báo hoạt động lẫn dữ liệu lỗi vào tệp bản ghi nhật ký MMFS. Tệp bản ghi nhật ký MMFS được đặt trong thư mục /var/adm/ras trên mỗi nút và có tên là mmfs.log.date.nodeName, ở đây date là dấu thời gian khi cá thể GPFS khởi động trên nút và nodeName là tên nút. Bạn có thể tìm thấy tệp bản ghi nhật ký MMFS mới nhất bằng cách sử dụng tên tệp ký hiệu /var/adm/ras/mmfs.log.latest.

GPFS ghi lại các lỗi hệ thống tệp hoặc đĩa bằng cách sử dụng tiện ích ghi nhật ký lỗi do hệ điều hành cung cấp:

  • Tiện ích syslog trên các nền tảng Linux.
  • Tiện ích errpt trên các nền tảng AIX.

Bạn có thể xem các lỗi này bằng cách đưa ra lệnh sau đây trên một nền tảng AIX:

errpt -a

Ban hành lệnh này trên một nền tảng Linux:

grep "mmfs:" /var/log/messages

Kịch bản 1: Thành viên bị lỗi và khởi động lại trên máy chủ nhà của thành viên đó, với các bản ghi nhật ký có chú thích

Kịch bản này gồm trường hợp có một lỗi phần mềm xuất hiện trên một thành viên DB2 và thành viên DB2 đó có thể được khởi động lại tự động trên máy chủ nhà của nó. Với mục đích trình diễn kịch bản này, quá trình db2sysc trên thành viên DB2 sẽ được loại bỏ.

Sau khi các bước được hiển thị, tiếp sau là một giải thích chi tiết về thông tin nào được ghi vào các bản ghi nhật ký.

Ban đầu, có bốn máy chủ (gọi là hostA, hostB, HoSTC, hostD) có thể truy cập dữ liệu chia sẻ của cá thể DB2 có tên là db2inst1 thông qua một hệ thống tệp phân cụm. Cá thể có hai thành viên DB2: thành viên 0 của DB2 đang chạy trên máy chủ nhà hostA, thành viên 1 của DB2 đang chạy trên máy chủ nhà hostB.

Lệnh db2instance cho thấy trạng thái ban đầu của cụm khỏe mạnh bình thường:

Liệt kê 7. Kết quả đầu ra của lệnh db2instance với cụm khỏe mạnh
> db2instance -list
ID  TYPE   STATE      HOME_HOST CURRENT_HOST ALERT PARTITION_NUMBER LOGICAL_PORT NETNAME
--  ----   -----      --------- ------------ ----- ---------------- ------------ -------
0   MEMBER STARTED    hostA     hostA        NO    0                0            hostA-ib0
1   MEMBER STARTED    hostB     hostB        NO    0                0            hostB-ib0
128 CF     PRIMARY    hostC     hostC        NO    -                0            hostC-ib0
129 CF     PEER       hostD     hostD        NO    -                0            hostD-ib0
	
HOSTNAME             STATE                INSTANCE_STOPPED        ALERT
--------             -----                ----------------        -----
hostA                ACTIVE               NO                      NO
hostB                ACTIVE               NO                      NO
hostC                ACTIVE               NO                      NO
hostD                ACTIVE               NO                      NO

Để trình diễn hành vi trong trường hợp có một lỗi phần mềm với thành viên 1 của DB2 trên hostB, đầu tiên chúng ta đưa ra psdb2 để liệt kê tất cả các tiến trình của trình quản lý cơ sở dữ liệu đang chạy trên hostB cho cá thể db2inst1 hiện tại:

Liệt kê 8. Kết quả đầu ra của psdb2
> psdb2
25014 db2sysc (idle 997)
25018 db2sysc (idle 998)
25027 db2sysc (idle 999)
	
25416 db2sysc 1
	
25440 db2vend (PD Vendor Process - 1) 0 0
	
25517 db2acd 1 ,0,0,0,1,0,0,0000,1,0,8a8e50,14,1e014,2,0,1,11fc0,0x210000000,0x210000000,1
600000,1138029,2,372802f

Sau đó chúng ta sử dụng lệnh hệ thống kill -9 25416 để loại bỏ quá trình db2sysc gắn với thành viên 1 của DB2 trên hostB:

> kill -9 25416

Ngay khi tiến trình này được loại bỏ, bạn sẽ thấy rằng việc khởi động lại thành viên DB2 được khởi tạo, bởi vì chúng ta có thể kiểm tra bằng cách chạy lệnh db2instance ngay sau khi loại bỏ tiến trình này:

Liệt kê 9. Chạy lệnh db2instance sau khi loại bỏ tiến trình
> db2instance -list
ID  TYPE   STATE      HOME_HOST CURRENT_HOST ALERT PARTITION_NUMBER LOGICAL_PORT NETNAME
--  ----   -----      --------- ------------ ----- ---------------- ------------ -------
0   MEMBER STARTED    hostA     hostA        NO    0                0            hostA-ib0
1   MEMBER RESTARTING hostB     hostB        NO    0                0            hostB-ib0
128 CF     PRIMARY    hostC     hostC        NO    -                0            hostC-ib0
129 CF     PEER       hostD     hostD        NO    -                0            hostD-ib0

HOSTNAME             STATE                INSTANCE_STOPPED        ALERT
--------             -----                ----------------        -----
hostA                ACTIVE               NO                      NO
hostB                ACTIVE               NO                      NO
hostC                ACTIVE               NO                      NO
hostD                ACTIVE               NO                      NO

Bằng cách chạy lệnh psdb2 chúng ta cũng có thể thấy tiến trình db2start đang khởi động lại thành viên DB2:

Liệt kê 10. Kết quả đầu ra của psdb2 hiển thị việc khởi động lại thành viên DB2
> psdb2
25014 db2sysc (idle 997)
25018 db2sysc (idle 998)
25027 db2sysc (idle 999)
	
27497 db2start NOMSG DATA 1 RESTART HOSTNAME hostB CM NETNAME hostB-ib0

Bạn cũng có thể có được trạng thái tài nguyên của mô hình tài nguyên bằng cách xem kết quả đầu ra của lệnh lssam:

Liệt kê 11. Kết quả đầu ra của lệnh lssam
Pending online IBM.ResourceGroup:db2_db2inst1_1-rg Nominal=Online
'- Pending online IBM.Application:db2_db2inst1_1-rs
|- Offline IBM.Application:db2_db2inst1_1-rs:hostA
'- Pending online IBM.Application:db2_db2inst1_1-rs:hostB

Tài nguyên db2_db2inst1_1-rs gắn với thành viên 1 của DB2 trong trạng thái PENDING ONLINE (đang chờ trực tuyến), có nghĩa là thành viên đó đang được các dịch vụ cụm DB2 khởi động lại, như lệnh db2instance đã thông báo.

Vì thành viên DB2 đã được khởi động lại trên máy chủ nhà của nó, lệnh db2instance sẽ thông báo rằng trạng thái của cụm đã trở lại khỏe mạnh và thành viên DB2 được khởi động lại đã sẵn sàng để xử lý tiếp tải công việc:

Liệt kê 12. Kết quả đầu ra của lệnh db2instance
> db2instance -list
ID  TYPE   STATE      HOME_HOST CURRENT_HOST ALERT PARTITION_NUMBER LOGICAL_PORT NETNAME
--  ----   -----      --------- ------------ ----- ---------------- ------------ -------
0   MEMBER STARTED    hostA     hostA        NO    0                0            hostA-ib0
1   MEMBER STARTED    hostB     hostB        NO    0                0            hostB-ib0
128 CF     PRIMARY    hostC     hostC        NO    -                0            hostC-ib0
129 CF     PEER       hostD     hostD        NO    -                0            hostD-ib0
	
HOSTNAME             STATE                INSTANCE_STOPPED        ALERT
--------             -----                ----------------        -----
hostA                ACTIVE               NO                      NO
hostB                ACTIVE               NO                      NO
hostC                ACTIVE               NO                      NO
hostD                ACTIVE               NO                      NO

Các sự kiện tương ứng trong các bản ghi nhật ký

Tài nguyên db2_db2inst1_1-rs tương ứng với thành viên 1 của DB2 được thông báo là không hoạt động trên hostB (IBM.RecoveryRM):

2011-05-25 18:10:34.421792 R(hostA) T(4118616992) _RCD ReportState: Resource: db2_db2inst
1_1-rs/Fixed/IBM.Application/hostB  reported state change: 2

Sau đó, Recovery RM đưa ra một yêu cầu kết thúc công việc đối với thành viên 1 của DB2 trên máy chủ nhà hostB của nó:

2011-05-25 18:10:34.583168 R(hostA) T(4118616992) _RCD Cleanup: Resource db2_db2inst1_1-rs
cleaned up on node hostB

Yêu cầu kết thúc công việc được thông báo đã thành công (IBM.RecoveryRM):

2011-05-25 18:10:36.506559 R(hostA) T(4118616992) _RCD RIBME-HIST: db2_db2inst1_1-rs/Float
/IBM.Application Cleanup: Cleanup order successfully completed.

Bạn cũng có thể thấy lệnh kết thúc công việc tương ứng được thực hiện từ bản ghi nhật ký RM GblRes (IBM.GblResRM):

Liệt kê 13. Tệp dò vết được định dạng với lệnh kết thúc công việc
2011-05-25 18:10:34.584000 G(hostB) T(4125461408) _GBD Running cleanup command "/home/db2i
nst1/sqllib/adm/db2rocm 1 DB2 db2inst1 1 CLEANUP" for resource 0x6028 0xffff 0x5b83a378 0x
a4e2ad4a 0x1221057d 0xf2eda550. Supporter: 0x0000 0x0000 0x00000000 0x00000000 0x00000000 
0x00000000.
	
2011-05-25 18:10:36.498548 G(hostB) T(4122803104) _GBD Cleanup command for application 
resource "db2_db2inst1_1-rs" (handle 0x6028 0xffff 0x5b83a378 0xa4e2ad4a 0x1221057d 
0xf2eda550) succeeded with exit code 0

Bạn có thể thấy các sự kiện tương ứng trong các tệp ghi nhật ký db2diag khi thành viên DB2 đã thực hiện kết thúc công việc thành công trên máy chủ nhà hostB của mình:

Liệt kê 14. Tệp ghi nhật ký db2diag khi thành viên DB2 đã thực hiện kết thúc công việc
2011-05-25-18.10.36.485126-240 I128222E517           LEVEL: Event
PID     : 27434                TID  : 46912763496800 PROC : db2rocm 1 [db2inst1]
INSTANCE: db2inst1             NODE : 001
HOSTNAME: hostB
FUNCTION: DB2 UDB, high avail services, db2rocm_main, probe:949
DATA #1 : SQLHA Event Recorder header data (struct sqlhaErPdInfo), PD_TYPE_SQLHA_ER_PDINFO
, 80 bytes
Original timestamp: 2011-05-25-18.10.34.787912000
DATA #2 : String, 32 bytes
db2rocm 1 DB2 db2inst1 1 CLEANUP
DATA #3 : String, 5 bytes
BEGIN
	
2011-05-25-18.10.36.492805-240 I132248E520           LEVEL: Event
PID     : 27434                TID  : 46912763496800 PROC : db2rocm 1 [db2inst1]
INSTANCE: db2inst1             NODE : 001
HOSTNAME: hostB
FUNCTION: DB2 UDB, high avail services, db2rocm_main, probe:1796
DATA #1 : SQLHA Event Recorder header data (struct sqlhaErPdInfo), 
PD_TYPE_SQLHA_ER_PDINFO, 80 bytes
Original timestamp: 2011-05-25-18.10.36.484918000
DATA #2 : String, 32 bytes
db2rocm 1 DB2 db2inst1 1 CLEANUP
DATA #3 : String, 7 bytes
SUCCESS

Khi kết thúc công việc đã hoàn tất, bạn sẽ thấy một yêu cầu trực tuyến được ban hành để khởi động lại thành viên DB2 trên máy chủ nhà hostB (IBM.RecoveryRM):

2011-05-25 18:10:36.563398 R(hostB) T(4118616992) _RCD Resource::doRIBMAction 
Online Request against db2_db2inst1_1-rs on node hostB.

Cuối cùng, thành viên DB2 được khởi động lại thành công và trạng thái tài nguyên tương ứng của nó được thông báo lại là ONLINE (IBM.RecoveryRM):

2011-05-25 18:10:54.947427 R(hostB) T(4118616992) _RCD ReportState: Resource : db2_db2inst
1_1-rs/Fixed/IBM.Application/hostB  reported state change: 1

Bạn cũng có thể thấy việc thực hiện yêu cầu trực tuyến tương ứng (IBM.GblResRM):

Liệt kê 15. Thực hiện yêu cầu trực tuyến tương ứng
2011-05-25 18:10:36.563972 G(hostB) T(4128926624) _GBD Bringing application resource 
online: Name=db2_db2inst1_1-rs Handle=0x6028 0xffff 0x5b83a378 0xa4e2ad4a 
0x1221057d 0xf2eda550

2011-05-25 18:10:54.937889 G(hostB) T(4122803104) _GBD Start command for application resou
rce "db2_db2inst1_1-rs" (handle 0x6028 0xffff 0x5b83a378 0xa4e2ad4a 0x1221057d 0xf2eda550)
succeeded with exit code 0

Nhìn vào kết quả đầu ra của lệnh lssam, bạn sẽ thấy rằng tài nguyên lại thực sự là trực tuyến trên máy chủ nhà hostB (trong khi vẫn chưa trực tuyến trên máy chủ khách tiềm năng là hostA):

Liệt kê 16. Kết quả đầu ra của lệnh lssam hiển thị trực tuyến tài nguyên trên máy chủ nhà
Online IBM.ResourceGroup:db2_db2inst1_1-rg Nominal=Online
'- Online IBM.Application:db2_db2inst1_1-rs
'- Online IBM.Application:db2_db2inst1_1-rs:hostB

Trong tệp bản ghi nhật ký db2diag, các sự kiện khởi động của thành viên DB2 sau đây được ghi nhật ký:

Liệt kê 17. Kết quả đầu ra của db2diag hiển thị các sự kiện khởi động của thành viên DB2
2011-05-25-18.10.36.777580-240 I132769E364           LEVEL: Event
PID     : 27496                TID  : 46912763496800 PROC : db2rocm 1 [db2inst1]
INSTANCE: db2inst1             NODE : 001
HOSTNAME: hostB
FUNCTION: DB2 UDB, high avail services, db2rocm_main, probe:949
DATA #1 : String, 30 bytes
db2rocm 1 DB2 db2inst1 1 START
DATA #2 : String, 5 bytes
BEGIN
	
2011-05-25-18.10.54.932894-240 I534141E367           LEVEL: Event
PID     : 27496                TID  : 46912763496800 PROC : db2rocm 1 [db2inst1]
INSTANCE: db2inst1             NODE : 001
HOSTNAME: hostB
FUNCTION: DB2 UDB, high avail services, db2rocm_main, probe:1796
DATA #1 : String, 30 bytes
db2rocm 1 DB2 db2inst1 1 START
DATA #2 : String, 7 bytes
SUCCESS

Thành viên 1 của DB2 khởi động lại thành công trên máy chủ nhà của mình là hostB và bây giờ có thể xử lý các giao dịch mới. Trạng thái cho thành viên 1 của DB2 lại là STARTED (đã khởi động) và nếu bạn truy vấn trạng thái của các thành viên bằng cách sử dụng lệnh db2instance -list, máy chủ hiện tại vẫn được hiển thị là hostB.


Kịch bản 2: Chuyển đổi dự phòng và chuyển đổi trở về của thành viên (kịch bản tuột cáp), với các bản ghi nhật ký có chú thích

Trong kịch bản này, một lỗi phần cứng xảy ra. Cụ thể, một người nào đó vô tình làm tuột cáp truyền dẫn InfiniBand.

Các dịch vụ cụm DB2 tự động khởi động lại thành viên trong chế độ khởi động lại nhanh trên một máy chủ hoạt động khác trong cụm. Khi máy chủ nhà có lỗi quay lại trực tuyến, thành viên trong chế độ khởi động lại nhanh tự động chuyển đổi trở về máy chủ nhà của mình và trở thành một thành viên hoạt động hoàn toàn đầy đủ, có thể lại xử lý các giao dịch mới.

Sau các bước được hiển thị, tiếp theo là một giải thích chi tiết về những gì được ghi vào các bản ghi nhật ký.

Ban đầu, có bốn máy chủ (hostA, hostB, hostC, hostD) có thể truy cập dữ liệu chia sẻ của cá thể DB2 là db2inst1, thông qua một hệ thống tệp phân cụm. Thành viên 0 của DB2 đang chạy trên máy chủ nhà hostA, thành viên 1 của DB2 đang chạy trên máy chủ nhà HostC. Có một liên kết InfiniBand giữa các thành viên và CF, trọng yếu cho cả các thành viên DB2 và CF.

Liệt kê 18. Kết quả đầu ra của db2instance hiển thị cấu hình
> db2instance -list
ID  TYPE   STATE      HOME_HOST CURRENT_HOST ALERT PARTITION_NUMBER LOGICAL_PORT NETNAME
--  ----   -----      --------- ------------ ----- ---------------- ------------ -------
0   MEMBER STARTED    hostA     hostA        NO    0                0            hostA-ib0
1   MEMBER STARTED    hostC     hostC        NO    0                0            hostC-ib0
128 CF     PRIMARY    hostB     hostB        NO    -                0            hostB-ib1
129 CF     CATCHUP    hostD     hostD        NO    -                0            hostD-ib1

HOSTNAME             STATE                INSTANCE_STOPPED        ALERT
--------             -----                ----------------        -----
hostA                ACTIVE                             NO           NO
hostB                ACTIVE                             NO           NO
hostC                ACTIVE                             NO           NO
hostD                ACTIVE                             NO           NO

Khi một ai đó vướng chân và làm tuột dây truyền dẫn InfiniBand, các dịch vụ cụm DB2 phát hiện có một lỗi xảy ra trên hostA. trạng thái tài nguyên trên giao diện mạng chuyển sang OFFLINE với hostA. Bạn có thể có được trạng thái tài nguyên từ kết quả đầu ra lệnh lssam:

Liệt kê 19. Trạng thái tài nguyên từ lssam
Online IBM.Equivalency:db2_private_network_db2inst1_0
|- Offline IBM.NetworkInterface:ib0:hostA
'- Online IBM.NetworkInterface:ib0:hostC

Các dịch vụ cụm DB2 tự động khởi tạo một sự khởi động lại thành viên 0 trên một máy chủ khách:

Liệt kê 20. db2instance hiển thị sự khởi động lại của thành viên 0
>$ db2instance -list
ID  TYPE   STATE      HOME_HOST CURRENT_HOST ALERT PARTITION_NUMBER LOGICAL_PORT NETNAME
--  ----   -----      --------- ------------ ----- ---------------- ------------ -------
0  MEMBER RESTARTING hostA   hostC        NO    0                0            hostA-ib0
1   MEMBER STARTED    hostC     hostC        NO    0                0            hostC-ib0
128 CF     PRIMARY    hostB     hostB        NO    -                0            hostB-ib1
129 CF     CATCHUP    hostD     hostD        NO    -                0            hostD-ib1

HOSTNAME             STATE                INSTANCE_STOPPED        ALERT
--------             -----                ----------------        -----
hostA                ACTIVE               NO                      YES
hostB                ACTIVE               NO                      NO
hostC                ACTIVE               NO                      NO
hostD                ACTIVE               NO                      NO
There is currently an alert for a member, CF, or host in the data-sharing instance. For mo
re information on the alert, its impact, and how to clear it, run the following command: '
db2cluster -cm -list -alert'.

Khi các dịch vụ cụm DB2 hoàn thành việc khởi động lại thành viên 0, chúng ta có thể thấy thành viên này đã được khởi động lại trên máy chủ khách HostC:

Liệt kê 21. db2instance hiển thị cảnh báo
> db2instance -list
ID  TYPE   STATE      HOME_HOST CURRENT_HOST ALERT PARTITION_NUMBER LOGICAL_PORT NETNAME
--  ----   -----      --------- ------------ ----- ---------------- ------------ -------
0  MEMBER WAITING_FOR.hostA  hostC        NO    0                0            hostA-ib0
1   MEMBER STARTED    hostC     hostC        NO    0                0            hostC-ib0
128 CF     PRIMARY    hostB     hostB        NO    -                0            hostB-ib1
129 CF     CATCHUP    hostD     hostD        NO    -                0            hostD-ib1

HOSTNAME             STATE                INSTANCE_STOPPED        ALERT
--------             -----                ----------------        -----
hostA                ACTIVE               NO                      YES
hostB                ACTIVE               NO                      NO
hostC                ACTIVE               NO                      NO
hostD                ACTIVE               NO                      NO
There is currently an alert for a member, CF, or host in the data-sharing instance. For 
more information on the alert, its impact, and how to clear it, run the following 
command: 'db2cluster -cm -list -alert'.


$ db2cluster -cm -list -alert
1.
Alert: Host 'hostA' is not responding on the network adapter 'ib0'. Check the operating
system for error messages related to this network adapter and chec k the connections to 
the adapter as well.

Action: This alert will clear itself when the network adapter starts to respond. This 
alert cannot be cleared manually with db2cluster.

Impact: DB2 members and CFs on the affected host that require access to network adapter 
'ib0' will not be operational until the problem is resolved. While the network adapter 
is offline, the DB2 members on this host will be in restart light mode on other systems, 
and will be in the WAITING_FOR_FAILBACK state. The affected CFs will not be available 
for CF failover and will remain in the STOPPED state until the network adapter issue is 
resolved.

Sau khi cắm lại dây InfiniBand, các dịch vụ cụm DB2 tự động phát hiện rằng hostA đã trở lại trực tuyến và thiết lập lại giao diện mạng thành ONLINE cho hostA:

Liệt kê 22. Thiết lập lại giao diện mạng
Online IBM.Equivalency:db2_private_network_db2inst1_0
|- Online IBM.NetworkInterface:ib0:hostA
'- Online IBM.NetworkInterface:ib0:hostC

Sau đó, các dịch vụ cụm DB2 chấm dứt thành viên 0 của DB2 trên máy chủ khách HostC và gọi khởi động lại DB2 bình thường thành viên 0 của DB2 trên máy chủ nhà hostA:

Liệt kê 23. Khởi động lại thành viên 0 của DB2 trên máy chủ nhà
> db2instance -list
ID  TYPE   STATE      HOME_HOST CURRENT_HOST ALERT PARTITION_NUMBER LOGICAL_PORT NETNAME
--  ----   -----      --------- ------------ ----- ---------------- ------------ -------
0  MEMBER STARTED    hostA   hostA        NO    0                0            hostA-ib0
1   MEMBER STARTED    hostC     hostC        NO    0                0            hostC-ib0
128 CF     PRIMARY    hostB     hostB        NO    -                0            hostB-ib1
129 CF     CATCHUP    hostD     hostD        NO    -                0            hostD-ib1
	
HOSTNAME             STATE                INSTANCE_STOPPED        ALERT
--------             -----                ----------------        -----
hostA                ACTIVE               NO                      NO
hostB                ACTIVE               NO                      NO
hostC                ACTIVE               NO                      NO
hostD                ACTIVE               NO                      NO
> db2cluster -cm -list -alert
There are no alerts

Các sự kiện tương ứng trong các bản ghi nhật ký:

Giao diện mạng tương ứng với bộ chuyển đổi ib0 trên máy chủ hostA được thông báo là không hoạt động (IBM.RecoveryRM):

2011-02-28 06:15:26.411814 R(hostA) T(4117486496) _RCD ReportState: Resource : ib0/Fixed/I
BM.NetworkInterface/hostA reported state change: 2

Recovery RM đưa ra một yêu cầu không trực tuyến đối với thành viên 0 trên máy chủ nhà hostA của nó:

2011-02-28 06:15:26.421832 R(hostA) T(4117486496) _RCD Resource::doRIBMAction Offline Requ
est against db2_db2inst1_0-rs on node hostA.
2011-02-28 06:15:26.425470 G(hostA) T(4127394720) _GBD Taking application resource offline
: Name=db2_db2inst1_0-rs Handle=0x6028 0xffff 0x77babcfd 0xac578906 0x120693f5 0xeea64740
2011-02-28 06:15:26.425613 R(hostA) T(4117486496) _RCD ReportState: Resource : db2_db2inst
1_0-rs/Fixed/IBM.Application/hostA reported state change: 6
2011-02-28 06:15:29.009743 G(hostA) T(4123753376) _GBD Stop command for application resour
ce "db2_db2inst1_0-rs" (handle 0x6028 0xffff 0x77babcfd 0xac578906 0x120693f5 0xeea64740) 
succeeded with exit code 0
2011-02-28 06:15:29.288071 R(hostA) T(4117486496) _RCD ReportState: Resource : db2_db2inst
1_0-rs/Fixed/IBM.Application/hostA reported state change: 2

Bạn có thể xem các sự kiện tương ứng trong các tệp bản ghi nhật ký db2diag khi thành viên đã ngừng lại thành công trên máy chủ nhà hostA:

Liệt kê 24. Tệp bản ghi nhật ký db2diag.log khi thành viên đã ngừng hoạt động trên máy chủ nhà
2011-02-28-06.15.28.988205-300 I981598E541           LEVEL: Event
PID : 1613                     TID : 46912880928864  KTID : 1613
PROC : db2rocm 0 [db2inst1]
INSTANCE: db2inst1             NODE : 000
HOSTNAME: hostA
FUNCTION: DB2 UDB, high avail services, db2rocm_main, probe:915
DATA #1 : SQLHA Event Recorder header data (struct sqlhaErPdInfo), PD_TYPE_SQLHA_ER_PDINFO
, 80 bytes
Original timestamp: 2011-02-28-06.15.26.693115000
DATA #2 : String, 40 bytes
db2rocm 1 DB2 db2inst1 0 STOP (SA_RESET)
DATA #3 : String, 5 bytes
BEGIN
	
2011-02-28-06.15.29.001230-300 I984566E544           LEVEL: Event
PID : 1613                     TID : 46912880928864  KTID : 1613
PROC : db2rocm 0 [db2inst1]
INSTANCE: db2inst1             NODE : 000
HOSTNAME: hostA
FUNCTION: DB2 UDB, high avail services, db2rocm_main, probe:1590
DATA #1 : SQLHA Event Recorder header data (struct sqlhaErPdInfo), PD_TYPE_SQLHA_ER_PDINFO
, 80 bytes
Original timestamp: 2011-02-28-06.15.28.987779000
DATA #2 : String, 40 bytes
db2rocm 1 DB2 db2inst1 0 STOP (SA_RESET)
DATA #3 : String, 7 bytes
SUCCESS

Bây giờ, thành viên 0 được khởi động lại trên máy chủ khách HostC (IBM.RecoveryRM):

Liệt kê 25. Thành viên 0 được khởi động lại trên máy chủ khách
2011-02-28 06:15:29.439708 R(hostA) T(4117486496) _RCD Resource::doRIBMAction Online Reque
st against db2_db2inst1_0-rs on node hostC.
2011-02-28 06:15:35.491788 G(hostC) T(4122594208) _GBD Start command for application resou
rce "db2_db2inst1_0-rs" (handle 0x6028 0xffff 0x5b83a378 0xa4e2ad4a 0x120693f5 0xeea67620)
succeeded with exit code 0
2011-02-28 06:15:35.496093 R(hostA) T(4117486496) _RCD ReportState: Resource : db2_db2inst
1_0-rs/Fixed/IBM.Application/hostC reported state change: 1

Các tệp bản ghi nhật ký db2diag cho thấy:

Liệt kê 26. db2diag.log hiển thị sự khởi động trên máy chủ khách
2011-02-28-06.15.29.710141-300 I996097E381           LEVEL: Event
PID : 17290                    TID : 46912880937056  KTID : 17290
PROC : db2rocm 0 [db2inst1]
INSTANCE: db2inst1             NODE : 000
HOSTNAME: hostC
FUNCTION: DB2 UDB, high avail services, db2rocm_main, probe:915
DATA #1 : String, 30 bytes
db2rocm 1 DB2 db2inst1 0 START
DATA #2 : String, 5 bytes
BEGIN
	
2011-02-28-06.15.35.482268-300 I1342111E384          LEVEL: Event
PID : 17290                    TID : 46912880937056  KTID : 17290
PROC : db2rocm 0 [db2inst1]
INSTANCE: db2inst1             NODE : 000
HOSTNAME: hostC
FUNCTION: DB2 UDB, high avail services, db2rocm_main, probe:1590
DATA #1 : String, 30 bytes
db2rocm 1 DB2 db2inst1 0 START
DATA #2 : String, 7 bytes
SUCCESS

Khi cáp InfiniBand được cắm trở lại, bộ chuyển đổi (ib0) trên hostA thông báo là trực tuyến trở lại (IBM.RecoveryRM):

2011-02-28 06:22:40.503749 R(hostA) T(4117486496) _RCD ReportState: Resource : ib0/Fixed/I
BM.NetworkInterface/hostA reported state change: 1

Do đó, thành viên 0 được ngừng lại trên máy chủ khách HostC:

Liệt kê 27. Thành viên 0 được dừng lại trên máy chủ khách
2011-02-28 06:22:40.549388 R(hostA) T(4117486496) _RCD Resource::doRIBMAction Offline Requ
est against db2_db2inst1_0-rs on node hostC.
2011-02-28 06:22:43.402484 G(hostC) T(4122594208) _GBD Stop command for application resour
ce "db2_db2inst1_0-rs" (handle 0x6028 0xffff 0x5b83a378 0xa4e2ad4a 0x120693f5 0xeea67620) 
succeeded with exit code 0

Các tệp bản ghi nhật ký db2diag cho thấy sự kiện này:

Liệt kê 28. Bản ghi nhật ký db2diag hiển thị sự kiện
2011-02-28-06.22.43.373821-300 I2291438E542          LEVEL: Event
PID : 19699                    TID : 46912880937056  KTID : 19699
PROC : db2rocm 0 [db2inst1]
INSTANCE: db2inst1             NODE : 000
HOSTNAME: hostC
FUNCTION: DB2 UDB, high avail services, db2rocm_main, probe:915
DATA #1 : SQLHA Event Recorder header data (struct sqlhaErPdInfo), PD_TYPE_SQLHA_ER_PDINFO
, 80 bytes
Original timestamp: 2011-02-28-06.22.40.810556000
DATA #2 : String, 40 bytes
db2rocm 1 DB2 db2inst1 0 STOP (SA_RESET)
DATA #3 : String, 5 bytes
BEGIN
	
2011-02-28-06.22.43.392086-300 I2295670E545          LEVEL: Event
PID : 19699                    TID : 46912880937056  KTID : 19699
PROC : db2rocm 0 [db2inst1]
INSTANCE: db2inst1             NODE : 000
HOSTNAME: hostC
FUNCTION: DB2 UDB, high avail services, db2rocm_main, probe:1590
DATA #1 : SQLHA Event Recorder header data (struct sqlhaErPdInfo), PD_TYPE_SQLHA_ER_PDINFO
, 80 bytes
Original timestamp: 2011-02-28-06.22.43.373504000
DATA #2 : String, 40 bytes
db2rocm 1 DB2 db2inst1 0 STOP (SA_RESET)
DATA #3 : String, 7 bytes
SUCCESS

Bây giờ, thành viên 0 được khởi động lại trên máy chủ nhà của nó, hostA (IBM.RecoveryRM):

Liệt kê 29. Thành viên 0 được khởi động lại trên máy chủ nhà
2011-02-28 06:22:43.825145 R(hostA) T(4117486496) _RCD Resource::doRIBMAction Online Reque
st against db2_db2inst1_0-rs on node hostA.
2011-02-28 06:22:55.189619 G(hostA) T(4123360160) _GBD Start command for application resou
rce "db2_db2inst1_0-rs" (handle 0x6028 0xffff 0x77babcfd 0xac578906 0x120693f5 0xeea64740)
succeeded with exit code 0
2011-02-28 06:22:55.193415 R(hostA) T(4117486496) _RCD ReportState: Resource : db2_db2inst
1_0-rs/Fixed/IBM.Application/hostA reported state change: 1

Các tệp bản ghi nhật ký db2diag cho thấy sự kiện này:

Liệt kê 30. Tệp bản ghi nhật ký db2diag hiển thị thành viên 0 được khởi động lại
2011-02-28-06.22.44.102847-300 I2369547E380          LEVEL: Event
PID : 4468                     TID : 46912880928864  KTID : 4468
PROC : db2rocm 0 [db2inst1]
INSTANCE: db2inst1             NODE : 000
HOSTNAME: hostA
FUNCTION: DB2 UDB, high avail services, db2rocm_main, probe:915
DATA #1 : String, 30 bytes
db2rocm 1 DB2 db2inst1 0 START
DATA #2 : String, 5 bytes
BEGIN
	
2011-02-28-06.22.55.178487-300 I2763321E383          LEVEL: Event
PID : 4468                     TID : 46912880928864  KTID : 4468
PROC : db2rocm 0 [db2inst1]
INSTANCE: db2inst1             NODE : 000
HOSTNAME: hostA
FUNCTION: DB2 UDB, high avail services, db2rocm_main, probe:1590
DATA #1 : String, 30 bytes
db2rocm 1 DB2 db2inst1 0 START
DATA #2 : String, 7 bytes
SUCCESS

Kịch bản 3: Việc tiếp quản tiện ích lưu trữ cụm trong bộ nhớ nhanh (CF)

Trong kịch bản này, một cá thể DB2 pureScale Feature được cấu hình với hai CF. Một được chỉ định là CF chính và cái kia là CF phụ. Các thành viên DB2 tự động truyền hai chiều thông tin quan trọng, như trạng thái thay đổi khóa và các trang nhóm của bộ đệm nhóm, tới cả hai CF. Bởi vì vào lúc bắt đầu kịch bản này, CF phụ ở trạng thái ngang hàng, nên chúng ta biết rằng thông tin quan trọng đã được truyền hai chiều và cập nhật trên CF phụ. Nếu CF chính hỏng không hoạt động, CF phụ nhanh chóng tiếp quản các trách nhiệm của CF chính sao cho lỗi gần như là vô hình với các ứng dụng.

Ban đầu, có 4 máy chủ (hostA, hostB, HostC, hostD) có thể truy cập dữ liệu chia sẻ của cá thể DB2 db2inst1 thông qua một hệ thống tệp phân cụm. Thành viên 0 của DB2 đang chạy trên máy chủ nhà hostA, thành viên 1 của DB2 đang chạy trên máy chủ nhà HostC. Có một liên kết InfiniBand giữa các thành viên và CF, rất quan trọng cho cả các thành viên DB2 lẫn các CF và do đó các phụ thuộc vẫn tồn tại với InfiniBand tương đương từ cả các thành viên lẫn các CF.

Liệt kê 31. Kết quả đầu ra của db2instance hiển thị cấu hình
> db2instance -list
ID  TYPE   STATE      HOME_HOST CURRENT_HOST ALERT PARTITION_NUMBER LOGICAL_PORT NETNAME
--  ----   -----      --------- ------------ ----- ---------------- ------------ -------
0   MEMBER STARTED    hostA     hostA        NO    0                0            hostA-ib0
1   MEMBER STARTED    hostC     hostC        NO    0                0            hostC-ib0
128 CF     PRIMARY    hostB     hostB        NO    -                0            hostB-ib0
129 CF     PEER       hostD     hostD        NO    -                0            hostD-ib0
	
HOSTNAME             STATE                INSTANCE_STOPPED        ALERT
--------             -----                ----------------        -----
hostA                ACTIVE               NO                      NO
hostB                ACTIVE               NO                      NO
hostC                ACTIVE               NO                      NO
hostD                ACTIVE               NO                      NO

Nếu CF hỏng trên hostB, vai trò chính được chuyển đổi dự phòng sang cho một CF phụ, đang ở trong trạng thái ngang hàng. Các dịch vụ cụm DB2 sẽ phát hiện rằng các tiến trình CF không hoạt động trên một máy chủ nhà và gọi lệnh xóa CF trên các máy chủ có lỗi (IBM.RecoveryRM):

Liệt kê 32. Các dịch vụ cụm phát hiện ra các tiến trình CF không hoạt động và gọi kết thúc công việc
2011-04-21 11:17:49.485951 G(hostB) T(4124957600) _GBD Monitor detect OpState change for r
esource Name=ca_db2inst1_0-rs OldOpState=1 NewOpState=2 Handle=0x6028 0xffff 0x88a0f77a 0x
4444ff43 0x12168f02 0x33bd39f8
2011-04-21 11:17:49.547613 R(hostB) T(4118584224) _RCD Cleanup: 
Resource ca_db2inst1_0-rs/Concurrent/IBM.Application cleanup order for constituent 
a_db2inst1_0-rs/Fixed/IBM.Application/hostB

Các tệp bản ghi nhật ký db2diag chứa các mục về việc phát ra lệnh này và kết quả kết thúc công việc:

Liệt kê 33. Tệp bản ghi nhật ký db2diag hiển thị kết thúc công việc
2011-04-21-11.17.54.442397-240 I45376528E522         LEVEL: Event
PID     : 4287                 TID  : 46912733618560 PROC : db2rocme 128 [db2inst1]
INSTANCE: db2inst1             NODE : 128
HOSTNAME: hostB
FUNCTION: DB2 UDB, high avail services, db2rocm_main, probe:927
DATA #1 : SQLHA Event Recorder header data (struct sqlhaErPdInfo), PD_TYPE_SQLHA_ER_PDINFO
, 80 bytes
Original timestamp: 2011-04-21-11.17.50.333529000
DATA #2 : String, 34 bytes
db2rocme 1 CF db2inst1 128 CLEANUP
DATA #3 : String, 5 bytes
BEGIN
	
2011-04-21-11.17.54.450788-240 I45379976E525         LEVEL: Event
PID     : 4287                 TID  : 46912733618560 PROC : db2rocme 128 [db2inst1]
INSTANCE: db2inst1             NODE : 128
HOSTNAME: hostB
FUNCTION: DB2 UDB, high avail services, db2rocm_main, probe:1639
DATA #1 : SQLHA Event Recorder header data (struct sqlhaErPdInfo), PD_TYPE_SQLHA_ER_PDINFO
, 80 bytes
Original timestamp: 2011-04-21-11.17.54.442222000
DATA #2 : String, 34 bytes
db2rocme 1 CF db2inst1 128 CLEANUP
DATA #3 : String, 7 bytes
SUCCESS

Vai trò chính được khởi động trên CF phụ (trên hostD):

Liệt kê 34. db2instance cho thấy vai trò chính được khởi động trên CF phụ
> db2instance -list
ID  TYPE   STATE      HOME_HOST CURRENT_HOST ALERT PARTITION_NUMBER LOGICAL_PORT NETNAME
--  ----   -----      --------- ------------ ----- ---------------- ------------ -------
0   MEMBER STARTED    hostA     hostA        NO    0                0            hostA-ib0
1   MEMBER STARTED    hostC     hostC        NO    0                0            hostC-ib0
128 CF     RESTARTING hostB     hostB        NO    -                0            hostB-ib0
129 CF     BECOMING_PR.hostD   hostD        NO    -                0            hostD-ib0
	
HOSTNAME             STATE                INSTANCE_STOPPED        ALERT
--------             -----                ----------------        -----
hostA                ACTIVE               NO                      NO
hostB                ACTIVE               NO                      NO
hostC                ACTIVE               NO                      NO
hostD                ACTIVE               NO                      NO

IBM.RecoveryRM:

Liệt kê 35. IBM.RecoveryRM
2011-04-21 11:17:52.137049 G(hostB) T(4124760992) _GBD Stop command for application resour
ce "primary_db2inst1_900-rs" (handle 0x6028 0xffff 0x88a0f77a 0x4444ff43 0x12168f06 0xe30a
b210) succeeded with exit code 0
2011-04-21 11:17:52.537322 R(hostB) T(4118584224) _RCD Cleanup: Resource primary_db2inst1_
900-rs/Fixed/IBM.Application/hostD is dirty.
2011-04-21 11:17:52.539174 G(hostD) T(4128926624) _GBD Bringing application resource onlin
e: Name=primary_db2inst1_900-rs Handle=0x6028 0xffff 0x1802cd9b 0xb77f5380 0x12168f06 0xe3
85c1f8
2011-04-21 11:17:52.543773 R(hostB) T(4118584224) _RCD Resource::doRIBMAction Online Reque
st against primary_db2inst1_900-rs on node hostD.
2011-04-21 11:18:08.446049 G(hostD) T(4123556768) _GBD Start command for application res
ource "primary_db2inst1_900-rs" (handle 0x6028 0xffff 0x1802cd9b 0xb77f5380 0x12168f06 0xe
385c1f8) succeeded with exit code 0

Các tệp bản ghi nhật ký db2diag chứa sự kiện sau đây về khởi động lại vai trò chính:

Liệt kê 36. Tệp bản ghi nhật ký db2diag hiển thị sự kiện về việc khởi động lại vai trò chính
2011-04-21-11.17.52.784069-240 I45349553E400         LEVEL: Event
PID     : 2560                 TID  : 46912733618560 PROC : db2rocme 900 [db2inst1]
INSTANCE: db2inst1             NODE : 900
HOSTNAME: hostD
FUNCTION: DB2 UDB, high avail services, db2rocm_main, probe:927
DATA #1 : String, 63 bytes
/home/db2inst1/sqllib/adm/db2rocme 1 PRIMARY db2inst1 900 START
DATA #2 : String, 5 bytes
BEGIN
	
2011-04-21-11.18.08.440950-240 I46272100E403         LEVEL: Event
PID     : 2560            TID  : 46912733618560 PROC : db2rocme 900 [db2inst1]
INSTANCE: db2inst1        NODE : 900
HOSTNAME: hostD
FUNCTION: DB2 UDB, high avail services, db2rocm_main, probe:1639
DATA #1 : String, 63 bytes
/home/db2inst1/sqllib/adm/db2rocme 1 PRIMARY db2inst1 900 START
DATA #2 : String, 7 bytes
SUCCESS

Các dịch vụ cụm DB2 cố gắng khởi động lại các tiến trình CF có lỗi trên hostB. Sau khi CF được khởi động lại thành công, nó chuyển sang trạng thái CATCHUP (theo kịp), tiếp theo là trạng thái PEER (ngang hàng) khi việc chuyển đổi dự phòng hoàn tất.

Hình 2. Chuyển dịch trạng thái CF
Sơ đồ hiển thị các trạm làm việc của khách được nối đến máy chủ dữ liệu DB2, được nối tới tiện ích lưu trữ cụm trong bộ nhớ nhanh

Bản ghi nhật ký của Recovery RM cho thấy:

Liệt kê 37. Bản ghi nhật ký IBM.RecoveryRM
2011-04-21 11:17:53.885765 G(hostB) T(4124269472) _GBD Cleanup command for application res
ource "ca_db2inst1_0-rs" (handle 0x6028 0xffff 0x88a0f77a 0x4444ff43 0x12168f02 0x33bd39f8
) succeeded with exit code 0
2011-04-21 11:17:53.964794 R(hostB) T(4118584224) _RCD Resource::doRIBMAction Online Reque
st against ca_db2inst1_0-rs on node hostB.
2011-04-21 11:17:53.966743 G(hostB) T(4128926624) _GBD Bringing application resource onlin
e: Name=ca_db2inst1_0-rs Handle=0x6028 0xffff 0x88a0f77a 0x4444ff43 0x12168f02 0x33bd39f8
2011-04-21 11:18:08.947076 G(hostB) T(4124269472) _GBD Start command for app
lication resource "ca_db2inst1_0-rs" (handle 0x6028 0xffff 0x88a0f77a 0x4444ff43 0x12168f0
2 0x33bd39f8) succeeded with exit code 0

Các tệp bản ghi nhật ký db2diag cho thấy:

Liệt kê 38. Tệp bản ghi nhật ký db2diag
2011-04-21-11.17.54.442397-240 I45376528E522         LEVEL: Event
PID     : 4287                 TID  : 46912733618560 PROC : db2rocme 128 [db2inst1]
INSTANCE: db2inst1             NODE : 128
HOSTNAME: hostB
FUNCTION: DB2 UDB, high avail services, db2rocm_main, probe:927
DATA #1 : SQLHA Event Recorder header data (struct sqlhaErPdInfo), PD_TYPE_SQLHA_ER_PDINFO
, 80 bytes
Original timestamp: 2011-04-21-11.17.50.333529000
DATA #2 : String, 34 bytes
db2rocme 1 CF db2inst1 128 CLEANUP
DATA #3 : String, 5 bytes
BEGIN
	
2011-04-21-11.17.54.450788-240 I45379976E525         LEVEL: Event
PID     : 4287                 TID  : 46912733618560 PROC : db2rocme 128 [db2inst1]
INSTANCE: db2inst1             NODE : 128
HOSTNAME: hostB
FUNCTION: DB2 UDB, high avail services, db2rocm_main, probe:1639
DATA #1 : SQLHA Event Recorder header data (struct sqlhaErPdInfo), PD_TYPE_SQLHA_ER_PDINFO
, 80 bytes
Original timestamp: 2011-04-21-11.17.54.442222000
DATA #2 : String, 34 bytes
db2rocme 1 CF db2inst1 128 CLEANUP
DATA #3 : String, 7 bytes
SUCCESS

2011-04-21-11.17.54.787350-240 I45392043E395         LEVEL: Event
PID     : 4358                 TID  : 46912733618560 PROC : db2rocme 128 [db2inst1]
INSTANCE: db2inst1             NODE : 128
HOSTNAME: hostB
FUNCTION: DB2 UDB, high avail services, db2rocm_main, probe:927
DATA #1 : String, 58 bytes
/home/db2inst1/sqllib/adm/db2rocme 1 CF db2inst1 128 START
DATA #2 : String, 5 bytes
BEGIN
	
2011-04-21-11.18.09.512434-240 I46330550E398         LEVEL: Event
PID     : 4358                 TID  : 46912733618560 PROC : db2rocme 128 [db2inst1]
INSTANCE: db2inst1             NODE : 128
HOSTNAME: hostB
FUNCTION: DB2 UDB, high avail services, db2rocm_main, probe:1639
DATA #1 : String, 58 bytes
/home/db2inst1/sqllib/adm/db2rocme 1 CF db2inst1 128 START
DATA #2 : String, 7 bytes
SUCCESS

> db2instance -list
ID  TYPE   STATE      HOME_HOST CURRENT_HOST ALERT PARTITION_NUMBER LOGICAL_PORT NETNAME
--  ----   -----      --------- ------------ ----- ---------------- ------------ -------
0   MEMBER STARTED    hostA     hostA        NO    0                0            hostA-ib0
1   MEMBER STARTED    hostC     hostC        NO    0                0            hostC-ib0
128 CF     CATCHUP   hostB    hostB        NO    -                0            hostB-ib0
129 CF     PRIMARY    hostD     hostD        NO    -                0            hostD-ib0
	
HOSTNAME             STATE                INSTANCE_STOPPED        ALERT
--------             -----                ----------------        -----
hostA                ACTIVE               NO                      NO
hostB                ACTIVE               NO                      NO
hostC                ACTIVE               NO                      NO
hostD                ACTIVE               NO                      NO

> db2instance -list
ID  TYPE   STATE      HOME_HOST CURRENT_HOST ALERT PARTITION_NUMBER LOGICAL_PORT NETNAME
--  ----   -----      --------- ------------ ----- ---------------- ------------ -------
0   MEMBER STARTED    hostA     hostA        NO    0                0            hostA-ib0
1   MEMBER STARTED    hostC     hostC        NO    0                0            hostC-ib0
128 CF     PEER      hostB    hostB        NO    -                0            hostB-ib0
129 CF     PRIMARY    hostD     hostD        NO    -                0            hostD-ib0
	
HOSTNAME             STATE                INSTANCE_STOPPED        ALERT
--------             -----                ----------------        -----
hostA                ACTIVE               NO                      NO
hostB                ACTIVE               NO                      NO
hostC                ACTIVE               NO                      NO
hostD                ACTIVE               NO                      NO

Lưu ý rằng trong một kịch bản tương tự, nếu CF phụ không ở trạng thái PEER, thì tình hình còn phức tạp hơn. Trong trường hợp này, sẽ có một sự gián đoạn trong việc xử lý giao dịch và lỗi này sẽ ảnh hưởng đến các máy khách được kết nối với cơ sở dữ liệu. Khi CF phụ không ở trạng thái PEER, nó không có thông tin mới nhất về trạng thái của cá thể chia sẻ dữ liệu. Vì vậy, nếu CF chính bị lỗi, cá thể chia sẻ dữ liệu phải thực hiện một khởi động lại nhóm. Các dịch vụ cụm DB2 sẽ bắt đầu khởi động lại nhóm tự động.


Kết luận

Có rất nhiều nguồn thông tin quan trọng về trạng thái của cụm DB2 pureScale. Các dịch vụ cụm DB2 giám sát các sự kiện và viết các bản ghi nhật ký, ghi lại thông tin liên quan về những tình huống thành công và thất bại. Bạn có thể sử dụng các lệnh db2clusterdb2instance kết hợp với các thông tin ghi nhật ký của các dịch vụ cụm DB2 để hiểu những gì xảy ra trong cụm và chẩn đoán và sửa chữa các vấn đề.

Nếu bạn đang làm việc có sự hỗ trợ kỹ thuật của IBM, bạn cũng có thể sử dụng lệnh db2support để thu thập dữ liệu chẩn đoán, dò vết và các tệp bản ghi nhật ký cho các dịch vụ cụm của DB2 pureScale cùng với thông tin ghi nhật ký DB2. Các tệp kết quả đầu ra có thể được gửi đến bộ phận hỗ trợ kỹ thuật của IBM để điều tra thêm và tiếp tục xử lý sự cố.


Phụ lục A: Các đặc quyền truy cập cần phải có để đọc các dấu vết của các trình quản lý tài nguyên

Để định dạng và đọc các dấu vết của trình quản lý tài nguyên, ví dụ các dấu vết trong /var/ct/< domain_name >/log/mc/IBM.GblResRM/, hãy sử dụng lệnh sau:

rpttr -o dtic /var/ct/<domain_name>/log/mc/IBM.GblResRM/trace_summary*

Bạn cần có quyền truy cập đọc/viết vào thư mục /var/ct/< domain_name >/log/mc/IBM.GblResRM/ và cũng có quyền truy cập đọc vào các tệp bản ghi nhật ký có trong thư mục.

Nếu không được phép truy cập viết vào thư mục, thì truy cập đọc vào thư mục và các tệp bản ghi nhật ký có thể là đủ. Trong trường hợp này, bạn có thể sử dụng cách tiếp cận sau để đọc các bản ghi nhật ký:

Liệt kê 39. Cách tiếp cận để đọc các bản ghi nhật ký nếu không được phép truy cập viết
mkdir ~/gblresrm_logs_copy
cp /var/ct/<domain_name>/log/mc/IBM.GblResRM/trace_summary* ~/gblresrm_logs_copy

rpttr -o dtic ~/gblresrm_logs_copy/trace_summary*
rpttr -o dtic ~/gblresrm_logs_copy/trace_summary* > formatted_gblresrm.log

Lưu ý rằng theo mặc định, chỉ người dùng chủ (root) có quyền truy cập đọc/viết với các tệp ghi nhật ký. Do đó một quản trị viên phải cấp thêm cho một người dùng cụ thể các đặc quyền bổ sung cần thiết trên các tệp bản ghi nhật ký này.


Thông tin cơ bản

Thông tin tùy chọn sau được cung cấp chỉ làm tài liệu tham khảo.

Tivoli SA MP và các phiên bản trước đó của trình quản lý cơ sở dữ liệu DB2

Trình quản lý cơ sở dữ liệu DB2 đã được tích hợp với Tivoli SA MP một thời gian rồi. Các phiên bản 9.5 và 9.7 của hệ thống cơ sở dữ liệu DB2 được tích hợp với Tivoli SA MP để cung cấp chức năng phân vùng cơ sở dữ liệu, phân vùng duy nhất ESE và tính sẵn sàng cao và phục hồi sau thảm họa (HADR), nhưng không được mặc định để sử dụng Tivoli SA MP hay tự động hóa quản lý cụm. Có một số bước thủ công cần thiết cho việc tạo cụm ban đầu và cho việc thêm và gỡ bỏ các phân vùng DB2.

Xem phần Tài nguyên để biết các liên kết đến các sách và nhiều tài nguyên hơn để cung cấp thêm thông tin về tích hợp hệ thống cơ sở dữ liệu DB2 với SA MP Tivoli, trước khi có Phiên bản 9.8.


Các cộng tác viên

Ngoài các tác giả, các cá nhân sau đây cũng đã góp phần vào bài này:

  • Joyce Simmonds - Nhà phát triển Thông tin DB2
  • Nikolaj Richers Nhà phát triển Thông tin DB2

Tài nguyên

Học tập

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
ArticleID=823402
ArticleTitle=Giải quyết các vấn đề trong môi trường các dịch vụ cụm của DB2 pureScale
publish-date=06292012