Ceph PGs may exhibit several states based on what's happening inside the cluster at that point in time. To know the state of a PG, you can see the output of the command ceph status. In this recipe, we will cover these different states of PGs and understand what each state actually means:
- Creating: The PG is being created. This generally happens when pools are being created or when PGs are increased for a pool.
- Active: All PGs are active, and requests to the PG will be processed.
- Clean: All objects in the PG are replicated the correct number of times.
- Down: A replica with necessary data is down, so the PG is offline (down).
- Replay: The PG is waiting for clients to replay operations after an OSD has crashed.
- Splitting: The PG is being split into multiple PGs. Usually, a PG attains this state when PGs are increased for an existing pool. For example, if you increase the PGs of a pool
rbdfrom 64 to 128, the existing PGs will split, and some of their objects will be moved to new PGs. - Scrubbing: The PG is being checked for inconsistencies.
- Degraded: Some objects in the PG are not replicated as many times as they are supposed to be.
- Inconsistent: The PG replica is not consistent. For example, there is the wrong size of object, or objects are missing from one replica after recovery is finished.
- Peering: The PG is undergoing the Peering process, in which it's trying to bring the OSDs that store the replicas of the PG into agreement about the state of the objects and metadata in the PG.
- Repair: The PG is being checked, and any inconsistencies found will be repaired (if possible).
- Recovering: Objects are being migrated/synchronized with replicas. When an OSD goes down, its contents may fall behind the current state of other replicas in the PGs. So, the PG goes into a recovering state and objects will be migrated/synchronized with replicas.
- Backfill: When a new OSD joins the cluster, CRUSH will reassign PGs from existing OSDs in the cluster to the newly added OSD. Once the backfilling is complete, the new OSD will begin serving requests when it is ready.
- Backfill-wait: The PG is waiting in line to start backfill.
- Incomplete: A PG is missing a necessary period of history from its log. This generally occurs when an OSD that contains needed information fails or is unavailable.
- Stale: The PG is in an unknown state—the monitors have not received an update for it since the PG mapping changed. When you start your cluster, it is common to see the stale state until the peering process completes.
- Remapped: When the acting set that services a PG changes, the data migrates from the old acting set to the new acting set. It may take some time for a new primary OSD to service requests. So, it may ask the old primary OSD to continue to service requests until the PG migration is complete. Once data migration completes, the mapping uses the primary OSD of the new acting set.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.