New answers tagged replication
1
Seconds_behind_master doesn't exactly measure the replication lag. It measures the difference between the timestamp of the last binlog event fetched by the IO thread, versus the timestamp of the last binlog event executed by the SQL thread.
This can become misleading for example if the master has more binlogs that the replica hasn't fetched yet. If the ...
1
These are out of the box features of SQL Server so you'll essentially need to follow the Microsoft Books Online and other resources on setting them up. Replication has a lot of small steps and basic prerequisites but it's essentially a wizard, so it's rather simple if you just follow the documentation carefully.
Here's some helpful references for setting up ...
0
Easy, just change host in primary_conninfo and restart the standby.
This replication parameter can be found in recovery.conf before v12 and in postgresql.conf after that.
1
Whether you use GTID or not, any replica needs a continuous stream of binlogs to keep in sync.
If any of the binlogs needed for the replica to catch up are gone, then it's trash. It can never catch up.
You need to reinitialize the replica. As if you were creating a new replica: make a new backup from the master, and use it to overwrite the replica. Then the ...
0
Yes, the data you read from SECONDARY might not be up-to-date. The obvious solution if you are no fine with it: read from the PRIMARY.
However, one hour sounds a lot. Did you configure a Delayed Member or did you configure storage.oplogMinRetentionHours?
1
Yes. If your primary instance crashes and restarts it will be empty; at this point your replica will also become empty, that would be a disaster.
Have a read of the replication docs https://redis.io/topics/replication . It suggests if you really want to avoid writing to storage in your primary (which really shouldn’t be a big deal with modern hardware), you ...
0
When you managed to get that A running, it will roll-back all those transactions what are not on B, because now B have newer transactions and it's Primary. That you get when you "force" Secondary to be primary against replica sets will.
1
maybe it's a bug in the SSMS; try to scritp the @schema_option and verity the proper value based on the list here:
https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sp-addarticle-transact-sql?view=sql-server-ver15
2
While it's theoretically possible for replication on the Publishing database to be affecting your application's write performance to that database (dependent on many factors) it's less likely that's your issue.
When you change servers, even if it's an exact replica server to the same specs (hardware and software) and same exact version of SQL Server, there's ...
0
I found this solution:
https://www.youtube.com/watch?v=7QI1VjbS0YI&t=460s&ab_channel=RajasekharReddyBolla
In case you need to migrate with zero downtime from Azure VM to Azure SQL Database
Top 50 recent answers are included
