Suppose I have 2 harbor repositories, 1 A and 1 B. A has set up replication rules in replication management to replicate mirrors to B via push mode.
So I want to ask when I push the mirror like A, when the push is done, does it also mean that A syncs successfully like B?
Related
Some of the AWS Services give the ability to replicate between regions. e.g. S3 (CRR), RDS (Read Replica) etc.
In S3-CRR, what happens if the destination Region goes down? Does the replication catch up automatically, once the Region is backup?
EDITED
2. Can CRR be enabled both ways? e.g. active-active
Similarly for RDS-MySQL Read Replica (RR) hosted in a different region what happens when
If the RR instance/Destination Region goes down, does it affect the MASTER in the other Region?
Once the instance is either replaced or Once the region in back up, does the RR catches up on the Missed changes that the MASTER have during the gap/outage?
How Aurora will be different from RDS-MySQL in the above areas?
In S3 cross-region replication, if the destination region goes down, or connectivity is disrupted, replication of objects is delayed until the issue is resolved, then recovers.
Cross-region can be used as active/active, but there is no conflict resolution, so if you wrote different objects with the same key to both regions at about the same time, which version would be the "final current version" in each region is undefined. As long as you aren't doing that, there's no problem. What you can't do is configure more than 2 regions in a ring, because A > B > C > A would only replicate one hop. Objects created in A would replicate A > B, but not B > C, because when an object is created by the replication process, it is not replicated further. That is, objects replicated into a bucket are never also replicated out of the bucket. Objects created directly in B would replicate B > C but not C > A.
If an RDS cross-region replica fails or becomes inaccessible, the master is unaffected. Under the hood, the replica is listening to a stream of change messages from the master, but not acknowledging actually having applied the changes to its local data set, so if a replica disappears, it's a non-event from the master's perspective. Because there are sequencing/positioning pointers/markers in the replication stream, the replica knows where it left off and asks for the stream from the correct starting pointer when it reconnects.
The replica will catch up when service/connectivity is restored, but not instantaneously. The time required depends on the amount of changed data that needs to replicate, and the capacity of the replica. This is true for standard RDS as well as Aurora -- cross-region replication is asynchronous.
Here is a use case:
I have version 1 of a web app deployed.
It uses couple Ignite-powered distributed (configured for replication) Maps, Sets and other data structures.
I'm going to deploy v2 of this application and once data is replicated I'm going to shutdown v1 of this app and re-route users (using nginx) to new instance (v2).
I can see that Ignite on v1 and v2 can discover each other and automatically perform replication of data structures.
My intention: I don't want to shutdown 1st instance (v1) before all data is replicated to 2nd instance (v2).
Question is: how do I know if initial replication is completed? Is there any event that is fired in such cases, or maybe some other way to accomplish this task?
If you configure you caches to use synchronous rebalancing [1], second node will not complete start process before rebalancing is completed. This way you will guarantee that all the data is replicated to the second node (of course, assuming that you're using fully replicated caches).
[1] https://apacheignite.readme.io/docs/rebalancing#section-rebalance-modes
I am interested in creating backups (snapshots) for data being stored in consul. I am using it as my backend storage for my service. I found few tools like consulate, consul-backup which take snapshots for the data which consul stores on the disk. Imagine, I have a 5 node set up where consul is running on all the 5 hosts and we have a quorum of 3. One of them is going to be the leader. With different back up strategies implemented, which backup the data on every single host, does it make more sense to back up only the leader ? The leader would be expected to maintain the most latest state of data. Then why do we need to back up every single host? And if we decide to back up just the leader, then if the leadership changes while the data was being backed up, would that result into any issues ?
I have 3 replicated Redis instances running on 3 different machines: A, B and C.
I initially choose A as my master.
I also have 3 sentinels (1 on each machine) monitoring A.
In case A goes down, I want sentinels to choose a specific master to failover to (say B).
Is there a way to choose a specific master instead of leaving it to the election mechanism of the sentinels?
Since I couldn't find this question anywhere, I reckon it's not standard procedure so I'll explain the reason behind it:
My application is running on A, B and C behind a load balancer.
The master uses its local Redis db which is replicated to the other two slaves.
When A fails, the load balancer could choose B as master while Redis sentinels could elect C as Redis master.
As I just said, I need the instance to be local, so that's why I need to specify B as the Redis master.
There's a Redis configuration setting called 'slave-priority' that may help you out.
Reference:
http://download.redis.io/redis-stable/redis.conf
I want to keep two instances of Redis ( server A and B ) which are installed on different hardware to keep data synchronized. When data "X" is written to server A, I want it to be synchronized to server B as well.
The reason for that is that from my client application, whenever I need to read data I can randomly pick between the two servers, load-balancing connection from multiple requests. This also allows to have a high-availability architecture so that if one server goes down the data is still on the other's cache.
How I am performing the above is through client code only. Whenever I write, I write to both servers ( A and B).
Is there a way to specify at server configuration level that server A will be in charge of replicating data writes to B ? Something like a trigger on any writes that replicates to server B and vice versa ( writes to server B get replicated to A ) ?
It is all right here Redis replication
You might instead want to implement local caching in the application, it is way faster than fetching from redis(which is in fact pretty fast too), and if you're hosting a half decent place, the uptime is like 99,9%, so availability shouldn't be a problem.