Hi Rich, Thank you for your feedback , as always greatly appreciate when comes from 389-DS RH support. We are not using vm just plain hardware, here is the description I got from developers team related to the issues they are seeing when running integration tests with multimaster replication : "index corruption: put content, run tests: OK, do more stuff (reads, writes, etc), ru tests: FAIL, notice "missing attributes", rebuild index(ices), run tests: OK. " Unfortunately, I understood this cases/issue can not be reproduce on regular basis, no mode details can be provide at this time All reads and writes are going to only the master replication DS, not slave . I totally agree with your this is the way to cfg and maintain Directory Server in a operation critical env: multmaster replication only one master for writes. Here is the DS version: rpm -qa | grep 389-ds 389-ds-console-doc-1.2.6-1.el6.noarch 389-ds-base-libs-1.2.11.15-34.el6_5.x86_64 389-ds-1.2.2-1.el6.noarch 389-ds-base-1.2.11.15-34.el6_5.x86_64 389-ds-console-1.2.6-1.el6.noarch Thank you Isabella FWD: We have cfg multimaster replication /fractional replication memberof plugging excluded , we are seeing from time to time index corruption with some indexes , there is a strong feeling from developers this are related to DS multimaster replication internal settings. What version of 389? rpm -q 389-ds-base I'm assuming you are not using IPA. What does "index corruption" mean? What exactly do you see? Are you running in virtual machines? If so, what kind? vmware? kvm? Are you using virtual disks or dedicated physical devices/paravirt? We are writing to only one DS , same server at all time but reading from all DS 's cfg for mutlmaster. Are you seeing "index corruption" on the write master or on all servers? Are other people seen this kind of issues with multimaster rep cfg , should we start avoiding this replication cfg at all ? This is the recommended way to deploy. If this is not working for you, either you have a configuration problem, or there is some sort of vm or hardware problem, or there is a serious bug that requires fixing ASAP. We choose the multimaster for the fast and reliable option to switch between master DS's , moving one step down to master/slave may require some down time when switching DS's back. Isabella Hi Rich, Thank you for your feedback , as always greatly appreciate when comes from 389-DS RH support. We are not using vm just plain hardware, here is the description I got from developers team related to the issues they are seeing when running tests with multimaster replication :index corruption: put content, run tests: OK, do more stuff (reads, writes, etc), ru tests: FAIL, notice "missing attributes", rebuild index(ices), run tests: OK. I belive we the reads and writes right now are only the master replication DS , not slave . I totally agree with your this is the way to cfg and maint DS in a operation env: multmaster replication with one master for writes. More comments , imput I appreciate rpm -qa | grep 389-ds 389-ds-console-doc-1.2.6-1.el6.noarch 389-ds-base-libs-1.2.11.15-34.el6_5.x86_64 389-ds-1.2.2-1.el6.noarch 389-ds-base-1.2.11.15-34.el6_5.x86_64 389-ds-console-1.2.6-1.el6.noarch 389-dsgw-1.1.11-1.el6.x86_64 ________________________________________ From: ghiureai [isabella.ghiurea@xxxxxxxxxxxxxx] Sent: Monday, November 09, 2015 1:05 PM To: 389-users@xxxxxxxxxxxxxxxxxxxxxxx Subject: multimaster replication and index corruption Hi List, We have cfg multimaster replication /fractional replication memberof plugging excluded , we are seeing from time to time index corruption with some indexes , there is a strong feeling from developers this are related to DS multimaster replication internal settings. We are writing to only one DS , same server at all time but reading from all DS 's cfg for mutlmaster. Are other people seen this kind of issues with multimaster rep cfg , should we start avoiding this replication cfg at all ? We choose the multimaster for the fast and reliable option to switch between master DS's , moving one step down to master/slave may require some down time when switching DS's back. Isabella -- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users
