This page documents settings for configuring a MYSQL service as a target for Bucket Notifications. See Publish Events to MySQL for a tutorial on using these settings. You can establish or modify settings by defining: an environment variable on the host system prior to starting or restarting the AIStor Server. Refer to your operating system’s documentation for how to define an environment variable. a configuration setting using mc admin config set. If you define both an environment variable and the similar configuration setting, AIStor uses the environment variable value.

The mc version commands enable, disable, and retrieve the versioning status for an AIStor bucket. For more information about object versioning in MinIO, see Bucket Versioning. mc version includes the following subcommands: Subcommand Description version Display version information for the deployment or client. enable Enable versioning on the specified bucket. info Return the versioning status for the specified bucket. suspend Disable versioning on the specified bucket.

The mc watch command watches for events on the specified AIStor bucket or local filesystem path. For S3 services, use mc event add to configure bucket event notifications on S3-compatible services. You can also use mc watch against a local filesystem directory to produce similar results to running the inotify -e modify,create,delete,move command. Syntax Example The following command watches for events on any object or prefix in the mydata bucket on the myaistor AIStor deployment:

Metrics version 2 provides metrics organized into four categories: Cluster metrics Bucket metrics Resource metrics Node metrics Each v2 endpoint returns all metrics for its category. For example, scraping the following endpoint returns all cluster metrics: http://HOSTNAME:PORT/minio/v2/metrics/cluster The base endpoint alone, /minio/v2/metrics/, returns cluster metrics. For more flexible scraping and a wider range of metrics, use version 3 metrics. Existing deployments can continue to use version 2 metrics.

AIStor supports expanding an existing distributed cluster by adding a new server pool. Each pool expands the total available storage capacity of the cluster. AIStor does not support increasing storage through logical volume expansion, rolling drive replacement, or other filesystem-level approaches. Expansion does not provide Business Continuity/Disaster Recovery (BC/DR)-grade protections. While each pool is an independent set of servers with distinct erasure sets for availability, the complete loss of one pool results in MinIO stopping I/O for all pools in the cluster. Similarly, an erasure set which loses quorum in one pool represents data loss of objects stored in that set, regardless of the number of other erasure sets or pools.

AIStor supports publishing bucket notification events to PostgreSQL. AIStor supports PostgreSQL 9.5 and later only. Prerequisites PostgreSQL 9.5 and later AIStor relies on features introduced with PostgreSQL 9.5. The AIStor mc Command Line Tool This procedure uses the mc command line tool for certain actions. See the mc Quickstart for installation instructions.

AIStor Server publishes its server logs to the system console. These logs can include errors, information output, or other information useful during troubleshooting or debugging. Server logs do not emit for all operations and cannot support audit trail or similar compliance requirements. If you require such a trail, configure and use audit logging instead. You can read the server logs using any of the following methods: Run journalctl -u minio from any host machine. Run mc admin logs against the AIStor deployment. Publish server logs to HTTP webhook AIStor supports publishing logs to a webhook consumer through an HTTP PUT operation, where the body of the request is the log as a JSON document.

AIStor supports publishing an audit log of all operations to a remote receiver. The audit logging feature meets security and compliance requirements around granular tracking of operations within an AIStor deployment. AIStor does not by default publish audit logs to any destination. Audit logs can contain private and internal details such as hostnames, IP addresses, and object names. The remote receiver takes responsibility for processing, storing, and securing all incoming audit logs.

Healing is AIStor’s ability to restore an object that has been damaged, corrupted, or partially lost. The loss can come from multiple types of corruptions or loss, such as but not limited to: drive-level errors or failure OS or filesystem errors or failure bit rot Healing and erasure coding AIStor can restore a damaged object depending on the following variables;

AIStor requires authentication and authorization for every operation on the object store. Human users and client applications must authenticate, and can perform only operations on resources explicitly allowed by the access policies assigned to them. Authentication verifies the identity of a user or client application. User credentials take the form of a username and password. Application credentials can take the form of an access key and secret key, or an application can call the appropriate STS endpoint. Which endpoint depends on your identity provider.