AnsweredAssumed Answered

Gfsck: repair containers with unknown master?

Question asked by dannyman on Jun 21, 2016
Latest reply on Jun 21, 2016 by dannyman

We had a disk fail in the CLDB the other day and I promoted a new CLDB.  Now there is Volume Data Unavailable Alarm. I run gfsck and note:

 

  containers that need repair --

    cid = 19676 noMasterServer = true fixedByFsck = false nameContainer = false

    cid = 19663 noMasterServer = true fixedByFsck = false nameContainer = false

    cid = 19773 noMasterServer = true fixedByFsck = false nameContainer = false

    cid = 21278 noMasterServer = true fixedByFsck = false nameContainer = false

    cid = 21252 noMasterServer = true fixedByFsck = false nameContainer = false

    cid = 21058 noMasterServer = true fixedByFsck = false nameContainer = false

    cid = 21087 noMasterServer = true fixedByFsck = false nameContainer = false

    cid = 21098 noMasterServer = true fixedByFsck = false nameContainer = false

 

Okay, what does that mean? maprcli dump volumeinfo -json ...

 

            {
                    "ContainerId":19676,
                    "Epoch":11,
                    "Master":"unknown ip (0)-0-VALID",
                    "ActiveServers":{
                          
                    },
                    "InactiveServers":{
                            "IP:Port":[
                                    "10.10.4.65:5660--10",
                                    "10.10.4.47:5660--9"
                            ]
                    },
                    "UnusedServers":{
                            "IP:Port":"10.10.4.55:5660--11"
                    },
                    "OwnedSizeMB":"15.77 GB",
                    "SharedSizeMB":"14.32 GB",
                    "LogicalSizeMB":"19.5 GB",
                    "TotalSizeMB":"15.77 GB",
                    "NumInodesInUse":174,
                    "Mtime":"Mon Jun 20 06:25:29 PDT 2016",
                    "NameContainer":"false",
                    "CreatorContainerId":0,
                    "CreatorVolumeUuid":"",
                    "UseActualCreatorId":false
            },

 

That UnusedServer is the old CLDB that had trouble. Is it safe to believe that gfsck -r can "repair" this situation by making one of the other servers master? Or am I facing data loss?

Outcomes