Re: Expected Write/Read Behavior in a Supplier/Consumer scenario...

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 07/03/2018 10:25 AM, David Boreham wrote:


On 7/2/2018 2:54 PM, Artur Lojewski wrote:
Question: If I issue a delete operation to a read-only replica, and the delete request ist properly resend to the actual supplier, can I expect (?) that an immediate read to the consumer does not find the deleted object?
Note : you wrote "ist" above. I'm assuming this should be "is" (not "isn't") No. Nothing will have changed in the consumer's database (hence : read-only).
Or do I have to wait until the supplier initiated replication (immediate) has taken place?
Yes.

The current behavior his that I still can read back the "deleted" object from the read-only replica until the replication is over. Is that correct behavior?
Yes.
Or can I 'tweak' things that even on a read-only replica a deleted object is immediately not available, even before replication starts.

No.

The servers implement "async" or "eventually consistent" replication. Clients have to deal with stale reads.
What you can do is instead of having a read-only consumer is you could just use two masters.  Then the delete would be intimidate on that server, but you'd still have to wait for replication to send the delete to the other master.

The issue is if you plan to add a lot of replicas.  You don't want to have 20 masters, although people do it.  It's just a lot of repl agreements and changelog contention, etc.

Regards,
Mark


_______________________________________________
389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/389-users@xxxxxxxxxxxxxxxxxxxxxxx/message/GY4FQ3R6G4UOJ4INRWNEW3IYIMFKBOMR/
_______________________________________________
389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/389-users@xxxxxxxxxxxxxxxxxxxxxxx/message/K4AV3PAY7YTDKEX7XZ6EPKUPNRW3MDSG/




[Index of Archives]     [Fedora User Discussion]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora News]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora QA]     [Fedora Triage]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Yosemite Photos]     [Linux Apps]     [Maemo Users]     [Gnome Users]     [KDE Users]     [Fedora Tools]     [Fedora Art]     [Fedora Docs]     [Maemo Users]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Fedora ARM]

  Powered by Linux