New answers tagged replication
3
The client inserts data to the primary database (replication cannot be done because of disconnection) that committed.
That can only happen if you configure the replica to be in Asynchronous-commit mode;
Asynchronous-commit mode is a disaster-recovery solution that works
well when the availability replicas are distributed over considerable
distances. ...
0
I think, first you need to identity what causes disconnection between Primary replica and Secondary replica, also you must have alerts in place which notify as soon as the synchronization stopped with any error.
For troubleshooting and making stable connection between Primary - Secondary replicas..
Alerts:
USE [msdb]
GO
-- Alert when Always-On Data ...
2
Very simplified, but when the connection between primary and the replica is lost, one of them (primary or replica) will no longer have a quorum. AlwaysOn is designed that way that you should be able to have only one quorum at the time.
Node without the quorum will become not available for connections and wait until it can belong to quorum and data are synced....
0
Looks like this issue:
https://jira.mariadb.org/browse/MDEV-20247
Body must be 30 characters.
4
The SQL Server error log only captures errors having a significant severity (generally 19-25, with exceptions). See the documentation here:
https://docs.microsoft.com/en-us/sql/relational-databases/errors-events/database-engine-error-severities
Imagine if all divide by zero, ambiguous column, or syntax errors flooded the error log? That log would quickly ...
1
I had the same issue when i cloned a VM to make the arbiter. Similar to what aldwinaldwin said, I had to change the ip address in this line in my /etc/hosts file "192.168.1.103 mongodb-arbiter.domain.local mongodb1-arbiter" to match the ip address of the server.
0
Long running and locking queries on subscriber databases wouldn't typically cause performance issues on the publisher. The distributer can be run separately if you are worried about them affecting the performance of your SQL server.
The Log Reader Agent will take the changes from the Publisher and store them in the distribution database. The Distribution ...
0
What is the usual rate at which data sync happens in your cluster?
Have you stopped the write to the secondaries from which the new member is syncing?
Alternate approach:
If your business allows, try to bring down one of the secondary node and then perform the sync from it
Thank you!
-Anban
0
Please check your connection time out settings on your mongo servers
Please try increasing the ulimit settings on your servers
Please implement retry logic in your driver level so the driver can handle this
Thank you!
-Anban
0
The way you perform the resync isn't right. To perform resync of the secondary member (assuming it is already a member of the replica set), bring down (stop mongod process) the secondaray node, delete all the folders from the /data directory including journal and restart the node so it re-joins the replica set again
Once it re-joins the replica set, mongodb ...
0
It sounds like maybe the MariaDB server is trying to "resolve" an IP address through DNS. Either turn off this feature (see below) or maybe use resolvable host names instead of IP addresses in your configuration.
To turn off, edit your /etc/my.cnf.d/server.cnf files or similar for both servers and add the below, and then restart the MariaDB servers.
[...
0
Yes, you can use a sequentially generated UUID as a primary key. SQL Server even has it built in:
CREATE TABLE dbo.keytest
(
kt_guid uniqueidentifier NOT NULL
CONSTRAINT keytest_pk
PRIMARY KEY
CLUSTERED
CONSTRAINT keytest_kt_guid_df
DEFAULT (NEWSEQUENTIALID())
);
Insert some rows, and SELECT them:
INSERT INTO ...
3
Is there a reason, other than tradition, that you need SQL01 to return to being the "primary"? You could do just a single flip, and skip the confusing mess of short-term log shipping:
Original state: Primary database on SQL01, set up to replicate all tables to SQL02.
When you do maintenance on SQL02, replication will queue up changes in the distribution ...
4
Separate from your Replication solution, could use a Failover Cluster Instance or Basic Availability Group for HA of your publisher.
Or, if you have a stomach for obscure replication solutions, you could implement Bidirectional Transactional Replication, which is similar to Peer-to-Peer replciation, but older and available on Standard Edition.
0
archive_mode is used for for archiving, regardless of standby configuration. It can be used for point in time recovery. So when you perform DML on any table, it will generate WAL.
For cleaning up you can use archive_cleanup_command from recovery.conf
0
If the binary logs contain absolutely everything that created that master (including grants, create database, create table, INSERTs, UPDATEs, and DELETEs), then yes it is possible.
The log position you need is not 0 or 1. It is 4 (See my post Question on having a MySQL 5.1 replicate from a MySQL 5.6 DB)
3
The way to go is a plain format pg_basebackup.
Just make sure that --wal-method=stream, and the backup will contain all required WAL files.
Then start the server on the backup directory, and it will perform recovery and come up.
There is no need to mess with pg_receivewal.
4
Your option 1, pg_dump | psql does have the limitations you describe.
Your option 2 doesn't make much sense. You need to start out with a clone in order to set up streaming, and by the time you have the clone then you don't need the streaming, as you already have the clone. Also, you don't have to "reconfigure both to disable replication again". When you ...
0
In my experience, a regular backup or dump, plus an on-demand restore gives your Developers the most flexibility, being able to refresh their databases as and when they please.
However, under GDPR, the use of Live data in non-Live systems really ought to be covered by your organisation's Privacy Notice. Check with your Data Protection Officer (or ...
1
I also had the same issue using Mariadb 10.4 master-slave replication.
I was using the setting innodb_thread_concurrency in the config file with a non-zero value. I updated it to:
innodb_thread_concurrency = 0
And now it's working again.
0
Consider:
Make it a 4-node Galera Cluster. Have gcache set large enough to handle more than 30 minutes' worth of changes. Then let Galera take care of the rest.
Meanwhile, your clients should not connect just to galera4, but via a proxy to any node. (You may want to tell the proxy that "galera4" is preferred.)
But the real problem comes when you try to ...
0
Need to be sure that your Replicaset name is the correct.
Ensure to at least add the ip or hostname of the master in the replicaset.
Ensure to add the correct port of the master node in the replicaset.
Check that you are using the correct keyfile defined in mongos and rs.
After that you just need to use:
sh.addShard("your_rs_name/rs_master_ip_or_hostname:...
0
if you are using Oracle Data guard, then it will not work since Oracle doesn't support it by default.
using OracleGate middleware might do the trick for you assuming there is no Data guard. and install version is Enterprise. but I advise you to check Oracle support to see if it will work perfectly if you implement it.
1
Please consult the Oracle Update and Migration Guide
There is no direct upgrade path, for your data a export/import might work.
Your old Forms application will not work, Oracle 10.1 was the last version that could run old 6i Client/Server Forms,IIRC
0
If you had a lot of concurrent heavy queries, the replica could help spread the workload. Or if the heavy query was interfering with other work the master database needs to do. But if you don't run multiple queries at the same time and the problem is only that they take too long, there is no reason to think a replica would help that situation.
make the ...
0
The variable innodb_optimize_fulltext_only was ON in master but OFF in slave. As a result, the OPTIMIZE TABLE commands were being skipped in Master server.
0
I have not used Amazon Cloud for my servers, but assuming the replication works , Replication will be a good solution for your requirements. Just need to be sure that your tables have a primary key.
In the case of replication since you can choose which tables to replicate, it could help for your performance (log shipping the whole DB vs replication just ...
0
Is such conversion considered a safe operation?
Converting a standalone node to a replica set is a straightforward procedure, but if you do not have a backup of your deployment (and this data is important) I would definitely prioritise creating and testing a backup. If you only have a single copy of your data (the one being used!) you will have very limited ...
0
You could consider Availability Groups for your databases. Since you are using them for reporting/read-only already then you already have licenses for your secondary instances.
This will allow better access to your secondaries as it does not need to take the database offline for updates - your data will also be more up to date as it is a constant flow of ...
0
check it out the scripts on this question:
Replication Monitor Information using T-SQL
Just make sure you run them in the right place - publisher, distributor or subscriber.
Recently, I noticed that the data in my subscriber is not synced up
with the database on the publisher server.
first thing is to find out what is there to be replicated that has ...
0
I have used a Domain Account for Snapshot Agent and Log Reader Agent,
called SQLAgent.
If you check this answer:
The process could not connect to Subscriber
you will see that the SQLAgent account must have a login on your ServerB and must be a db_owner on your subscription database there.
It does not need to be a sysadmin on your ServerA.
It has ...
0
Just to complement or add to the other answer
there are times you get a really hairy message
first thing I do is to turn on the verbose:
Turn on verbose history (Replication monitor->Agent Profile->Verbose History) and use the -output parameter and select a destination for the output file (Subscriber Replication Job -> Edit Run Agent Job -> In ...
0
I can see on your error messages that data validation could not be done, although as you said the publisher and the subscriber tables have the exact same rowcount.
I don't think it would be a conflict, though you could check for that.
for any errors related to could not be verified on merge replication in sql 2005
something like this:
Error messages: • ...
0
This is the article that helped me with replication. So the database that you are sending from is your publisher and you'll need to go to replication/local publications and create a new publisher with the databases you want to send.
You may or may not use a middleman/distributor but the subscriber is where you want the database(s) to end up and you will ...
0
The answer is that all 3 machines must have the same version 4.0
1
It sounds like you'd benefit from using procedural replication for those stored procedures. That way, SQL Server will just run the procedures on the replicated instance rather than replicating all the DELETE and INSERT operations. I'll wager that will be much faster and will reduce latency in addition to fixing the issue you're seeing where the destination ...
Top 50 recent answers are included
