Hi Wido,
Just curious how blocking IO to the final replica provides protection from data loss? I’ve never really understood why this is a Ceph best practice. In my head all 3 replicas would be on devices that have roughly the same odds of physically failing or getting logically corrupted in any given minute. Not sure how blocking IO prevents this.
On 12/7/16, 9:11 AM, "ceph-users on behalf of LOIC DEVULDER" <ceph-users-bounces@xxxxxxxxxxxxxx on behalf of loic.devulder@xxxxxxxx> wrote:
> -----Message d'origine-----
> De : Wido den Hollander [mailto:wido@xxxxxxxx]
> Envoyé : mercredi 7 décembre 2016 16:01
> À : ceph-users@xxxxxxxx; LOIC DEVULDER - U329683 <loic.devulder@xxxxxxxx>
> Objet : RE: 2x replication: A BIG warning
>
>
> > Op 7 december 2016 om 15:54 schreef LOIC DEVULDER
> <loic.devulder@xxxxxxxx>:
> >
> >
> > Hi Wido,
> >
> > > As a Ceph consultant I get numerous calls throughout the year to
> > > help people with getting their broken Ceph clusters back online.
> > >
> > > The causes of downtime vary vastly, but one of the biggest causes is
> > > that people use replication 2x. size = 2, min_size = 1.
> >
> > We are building a Ceph cluster for our OpenStack and for data integrity
> reasons we have chosen to set size=3. But we want to continue to access
> data if 2 of our 3 osd server are dead, so we decided to set min_size=1.
> >
> > Is it a (very) bad idea?
> >
>
> I would say so. Yes, downtime is annoying on your cloud, but data loss if
> even worse, much more worse.
>
> I would always run with min_size = 2 and manually switch to min_size = 1
> if the situation really requires it at that moment.
>
> Loosing two disks at the same time is something which doesn't happen that
> much, but if it happens you don't want to modify any data on the only copy
> which you still have left.
>
> Setting min_size to 1 should be a manual action imho when size = 3 and you
> loose two copies. In that case YOU decide at that moment if it is the
> right course of action.
>
> Wido
Thanks for your quick response!
That's make sense, I will try to convince my colleagues :-)
Loic
_______________________________________________
ceph-users mailing list
ceph-users@xxxxxxxxxxxxxx
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
_______________________________________________
ceph-users mailing list
ceph-users@xxxxxxxxxxxxxx
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
