2

You cannot have that. PITR requires a file system level backup and recovery, and both encompass the whole cluster. I am not saying it is theoretically impossible, but no such functionality exists.


2

just to note the issue is still there using mongoDB 4.2.6 and as it is said in this post is only solved by providing a FQDN when configuring the ReplicaSet


2

This looks like a non-issue, because, obviously, you will be using the same table definitions, including engine, on both servers. The example in the MariaDB Knowledge Base article you linked to has different storage engines: the slave server doesn't have InnoDB, so it defaults to MyISAM, which doesn't support foreign keys. MyISAM does tolerate foreign key ...


2

If you have synchronous replicas you typically have one with automatic failover. The most common reason not to is when the primary is hosted on a Failover Cluster Instance, and it's a rule that only the FCI can failover automatically in that configuration. But you could also have a scenario where you would prefer an outage over a failover, for instance if ...


2

I don't think this is necessarily a good fit for the SE Q&A model, but I sympathize with datadawg2000's pain so will add some words that may help. ...claiming poor performance on the main server due to too many processes running at once. When I open activity monitor at any given time, I see no more than 5% processor time, 1 mb/sec, etc. Let's be ...


1

There are no pros as such that motivates you to use this mode of failover. its completely dependent on the requirement of the business and requirement of availability or activation of secondary server. so may be you want to initiate a failover yourself just to satisfy your believe that failover works best this way or you can make yourself confident that ...


1

The other half of the version requirements is that your distributor be the highest SQL Server version in your Replication topography. In your case, you are replicating from SQL Server 2012 to SQL Server 2016, which works only if your distributor is also SQL Server 2016. If you are running your distribution database on your 2012 publisher, configuration ...


1

I think this is what they would call "working as designed". It is stated in the documentation for Aurora MySQL (emphasis mine): The tradeoff with having multiple Aurora Replicas is that replicas become unavailable for brief periods when the underlying database instances are restarted. These restarts can happen during maintenance operations, or when a ...


1

Yes, There is a setting for this which is called synchronous_standby_names. You can give expression like ANY 3 (r1, r2, r3, r4) which says "proceed commit as soon as at least any three standbys reply" If you want to specify exact replication name just name them like r1,r4. Here is sample usage; ALTER SYSTEM SET synchronous_standby_names TO 'ANY 3 (r1, ...


1

Several comments... Master-Master won't help much -- all writes to one master are 'replicated' to the other. Hence you don't get much write scaling. Two clients (or even N clients) could contend on a single master. But the contention is easily handled with transactions. A single UPDATE can grab the 100 tasks atomically. A suggestion: Loop: UPDATE ...


1

In short - yes, you will have to engineer your application in a way that makes it resistant to race conditions. Transactions won't help you with this.


1

No, it is not possible to have multiple read/write replicas in an Availability Group. For your requirement, you might consider Merge Replication which allows writes at multiple databases and merges the data across all databases involved in the replication. This doesn't allow for writing to that same DB, but the replication architecture works to keep both ...


1

No it should'nt. You misunderstood what synchronous replication means. Synchronous mean than you should have at least one copy at any time no matter what. If you don't then use asynchronous replication. Postgres is semi-sync replication by design if you use replication slots. Replication in Postgres is so much better than in MySQL, in fact MySQL has terrible ...


Only top voted, non community-wiki answers of a minimum length are eligible