Các tệp cấu hình YAML mẫu cho MongoDB?

Các tùy chọn cấu hình tài liệu MongoDB liệt kê tất cả các tùy chọn có sẵn mà có thể được chỉ định, nhưng không ai có một tập các ví dụ hình thành đầy đủ YAML định dạng cấu hình file cho trường hợp MongoDB trong vai trò khác nhau?

Một tập hợp các ví dụ cho các vai trò phổ biến sẽ là điểm khởi đầu rất hữu ích cho những người bắt đầu từ đầu hoặc muốn thử nghiệm với định dạng tệp cấu hình mới nhất.

Dưới đây là một số ví dụ về cấu hình YAML cho Linux (các đường dẫn và tùy chọn của Windows hơi khác một chút), về cơ bản rõ ràng là đặt một số mặc định và các cài đặt thường được sử dụng.

Đầu tiên, một độc lập mongodvới cổng, đường dẫn, cài đặt nhật ký mặc định - đây sẽ là loại cấu hình được sử dụng để thử nghiệm cục bộ, với một vài tính năng bổ sung để hiển thị kiểu chung:

storage:
    dbPath: "/data/db"
    directoryPerDB: true
    journal:
        enabled: true
systemLog:
    destination: file
    path: "/data/db/mongodb.log"
    logAppend: true
    timeStampFormat: iso8601-utc
processManagement:
    fork: true
net:
    bindIp: 127.0.0.1
    port: 27017
    wireObjectCheck : false
    unixDomainSocket: 
        enabled : true

Một số lưu ý về cấu hình này:

• Nói chung, bạn không muốn có đối tượng kiểm tra ( wireObjectCheck: false) trong sản xuất, nhưng với tải dữ liệu lớn cho mục đích thử nghiệm, nó sẽ tăng tốc mọi thứ lên một chút và là rủi ro tối thiểu trong môi trường như vậy
• Điều này sẽ không hoạt động để sao chép trừ khi tất cả các thành viên của bộ bản sao nằm trên địa chỉ IP loopback (vì đây là ràng buộc duy nhất được chỉ định), vì vậy hãy cẩn thận

Bây giờ, chúng ta hãy xem một tệp cấu hình mẫu cho một thành viên bộ bản sao sản xuất điển hình với xác thực được bật và chạy như một phần của cụm được phân tách:

storage:
    dbPath: "/data/db"
    directoryPerDB: true
    journal:
        enabled: true
systemLog:
    destination: file
    path: "/var/log/mongodb.log"
    logAppend: true
    timeStampFormat: iso8601-utc
replication:
    oplogSizeMB: 10240
    replSetName: "rs1"
processManagement:
    fork: true
net:
    bindIp: 192.0.2.1
    port: 27018
security:
    keyFile: "/data/key/rs1.key"
    authorization: "enabled"
sharding:
    clusterRole: "shardsvr"

Một số lưu ý về cấu hình này:

• Một lần nữa, có các tuyên bố rõ ràng về mặc định và cài đặt ngụ ý (ví dụ cổng được ngụ ý bởi clusterRole), nói chung điều này được khuyến nghị để tránh nhầm lẫn
• Liên kết IP bây giờ chỉ là địa chỉ IP bên ngoài, do đó giao tiếp trên IP loopback sẽ không thành công, nhưng sao chép có thể hoạt động với các máy chủ từ xa
• Các oplog mặc định là 5% không gian trống, do đó, thông thường trên các khối lượng lớn sẽ bảo thủ hơn và đặt rõ ràng kích thước được phân bổ

Tiếp theo, một mongoscấu hình mẫu :

sharding:
    configDB: "config1.example.net:27019,config2.example.net:27019,config3.example.net:27019"
    autoSplit: true
systemLog:
    destination: file
    path: "/var/log/mongos.log"
processManagement:
    fork: true
net:
    port: 27017
    bindIp: 192.0.2.2
    maxIncomingConnections: 5000
security:
    keyFile: "/data/key/mongos.key"
    authorization: "enabled"

Các thay đổi bắt buộc duy nhất ở đây là các loại bỏ không áp dụng cho mongos(vì nó không lưu trữ dữ liệu) và việc thêm configDBchuỗi, phải giống hệt nhau trên tất cả các mongosquy trình. Tôi đã thêm cài đặt kết nối tối đa làm ví dụ, không bắt buộc nhưng thường có thể là ý tưởng hay cho các cụm lớn hơn.

Làm tròn cụm phân đoạn, chúng ta có một máy chủ cấu hình mẫu, đây thực sự là một tập hợp con của thành viên bộ bản sao với một số thay đổi nhỏ:

storage:
    dbPath: "/data/db"
    journal:
        enabled: true
systemLog:
    destination: file
    path: "/var/log/mongodb.log"
    logAppend: true
    timeStampFormat: iso8601-utc
processManagement:
    fork: true
net:
    bindIp: 192.0.2.3
    port: 27019
security:
    keyFile: "/data/key/config.key"
    authorization: "enabled"
sharding:
    clusterRole: "configsvr"

Cuối cùng, MongoDB 3.0 (chưa được phát hành tại thời điểm viết bài này) sẽ giới thiệu một số tùy chọn mới, đặc biệt là với việc giới thiệu các công cụ lưu trữ mới. Do đó, đây là một ví dụ về cách định cấu hình cùng một thành viên bộ bản sao, nhưng lần này với công cụ lưu trữ WiredTiger và phương thức nén linh hoạt (mặc định) (lưu ý: đã thay đổi từ bản gốc vì SERVER-16266 và đã thêm mẫu engineConfig):

storage:
    dbPath: "/data/db"
    engine: "wiredTiger"
    wiredTiger:
        engineConfig: 
            cacheSizeGB: 8
        collectionConfig: 
            blockCompressor: snappy        
systemLog:
    destination: file
    path: "/var/log/mongodb.log"
    logAppend: true
    timeStampFormat: iso8601-utc
replication:
    oplogSizeMB: 10240
    replSetName: "rs1"
processManagement:
    fork: true
net:
    bindIp: "192.0.2.1,127.0.0.1"
    port: 27018
security:
    keyFile: "/data/key/rs1.key"
    authorization: "enabled"
sharding:
    clusterRole: "shardsvr"

Là một bổ sung phần thưởng cuối cùng, tôi đã chỉ ra cách liên kết nhiều địa chỉ IP bằng cách sử dụng danh sách, trong trường hợp này là IP bên ngoài và IP loopback.