I need to configure my single node cassandra with a global replication factor for all keyspaces I've and keyspaces I will create,
AFAIK replication factor can be configured per keyspace or in cassandra.yaml file for all keyspaces.
did anyone try to configure Replication Factor in cassandra.yaml file ? and how ?
I don't think it's possible to configure the replication factor in cassandra.yaml.
This is always done on a per keyspace basis. Since you only have a single node, you will need to configure a replication factor of 1 for your keyspaces.
Related
I have a running RDS Aurora MySQL 8.0.23 cluster running in production. The database is unencrypted and I need to enable encryption for it. As far as I understand, this is not possible to do directly. The procedure I am evaluating is:
Create a read replica on the current cluster.
Stop replication on replica and annotate binlog filename and
position.
Promote the read replica to a new encrypted cluster (maybe it
requires to do a snapshot before).
Set up back replication with the original cluster using binlog file
and position annotated before.
Wait until replication lag is zero.
Redirect production traffic to the new cluster.
Stop replication.
[Optional] Delete old cluster.
I have two issues with the above procedure:
Once created the replica, running commands like SHOW SLAVE STATUS
or SHOW REPLICA STATUS return empty set, so I can't annotate
binlog file and position. Please note that replication is enabled on
the original cluster (binlog_format is set to ROW).
It seems I can't promote the Aurora read replica to a new cluster,
the option is missing on the available actions. But according to the documentation it should be possible.
Has anyone have feedback about the issues above? What is the current up-to-date procedure to encrypt an Aurora MySQL cluster with minimum downtime and no data loss?
I have setup a small cluster using two MariaDB 10.2 databases, one is (active) master and the other standby (passive master). I have enabled GTID and semi-synchronous replication. Say that MDB1 is master and MDB2 is standby, therefore MDB2 replicates MDB1 binlog and MDB1 replicates MDB2 binlog. Of course I write only on MDB1 to avoid conflicts.
My concern is about JDBC parameter: I cannot really understand the difference between failover, replication and sequence.
jdbc:mariadb:replication://localhost:3306,localhost:3307/mydb
Using replication as above it seems to write always on MDB1 (:3306) and to read both from MDB1 and MDB2, right?
In the case I want to write and read always to from MDB1, unless it becomes unavailable, which is the correct setup?
And how can I avoid inconsistencies when MDB1 became available again? Is this guaranteed by the usage of GTID?
I have followed those guides:
Availability with MariaDB TX: The Definitive Guide p11
Failoverand High availability with MariaDB Connector/J
What you should use is sequential
According to the documentation,
'''
if the failover and load-balancing mode is set to replication, then the connector assumes that the first host is master, and the others are slaves by default, if their types are not explicitly mentioned.
'''
I'm kind of lost there, I want to setup a common MASTER/SLAVE replication on a MariaDB database. I choose MASTER/SLAVE over MASTER/MASTER to avoid complexifying things. The SLAVE will be used only if the MASTER server is down.
I've setup MariaDB 10.0.x, but when I start reading on how to achieve this replication, they introduce Galera, which, if I understand correctly, replaces MariaDB.
What do you use to tell the SLAVE server to take the relay if the MASTER server is down ? Is it handled automatically via the Galera Cluster ?
If possible, I don't want my application to be aware of the slave server : I just want to configure it with the IP of MariaDB MASTER, and if it can't be reached, to use the SLAVE instead. (But I do not want to specify this fallback in the application level)
Thanks
What you are looking for can be achieved. I just completed a setup of MariaDB 10 using asynchronous replication (not Galera). To ensure maximum uptime I setup master / master replication and used mysql-mmm to monitor the setup. This tool will manage a virtual IP and point it at one of the two masters for writing purposes. This ensures consistent writes against a single master as to avoid corruption of the data. If one master fails the virtual IP will be mapped to the other master. This provides the high availability aspect. The instructions stated below were very clear and easy to follow.
http://mysql-mmm.org/mmm2:guide
Good luck!
I run a service that needs to be able to support about 4000+ IOPS and keep replica lag <=1 second to function properly.
I am using AWS RDS MySQL instances and have 2 read replica's. My service was experiencing giant replica lag spikes on the read replica's so I was in contact with AWS support for a week trying to understand why I was experiencing the lag--I had 6000 IOPS provisioned and my instances were very powerful. They gave me all kinds of reasons.
After changing instance types, upgrading to MySQL 5.6 from 5.5 to take advantage of multi-threading, and them replacing underlying hardware I was still seeing significant replica lag randomly.
Eventually I decided to start tinkering with the parameter groups changing my configs for just the read replica's on anything I could find that was involved in the replication process and am now finally experiencing <= 1 second of replica lag.
Here are the settings I changed and their values that appear to be successful (I copied the default mysql 5.6 param group and changed these values applying the updated paramater group to just the read replicas):
innodb_flush_log_at_trx_commit=0
sync_binlog=0
sync_master_info=0
sync_relay_log=0
sync_relay_log_info=0
Please read about each of these to understand the impact of the modifications: http://dev.mysql.com/doc/refman/5.6/en/innodb-parameters.html
Other things to make sure you take care of:
Convert any MyISAM tables to InnoDB
Upgrade from MySQL < 5.6 to MySQL >= 5.6
Ensure that your provisioned IOPS are > the combined read/write IOPS you require
Ensure that your read replica instances are >= master instance
If anyone else has any additional parameters that could be modified on the read replica's or master DB to get the best replication performance I'd love to hear more.
UPDATE 7-8-2014
To take advantage of Mysql 5.6 multi-thread replication I've set:
slave_parallel_workers=5 (Set it to the number of read replica DBs you have running)
I found this in this here:
https://blogs.oracle.com/MySQL/entry/benchmarking_mysql_replication_with_multi
Mysql replication executes all the transactions on a single database in order , and master - can execute those transactions in parallel.
You probably have most of the updates executed on a single DA, and that is what not allowing you to get advantage of multithreaded replication.
Check the iostat on your replica server. Most of the time those problem occurs because of high IO on the machine.
In order to decrease the IO on a machine - there are several additional changes that you can do:
Increase innodb_buffer_pool_size - this is the first thing you should change from default. If this instance runs only mysql - you can allocate about 80% of your available the memory here.
Verify also the following parameters:
log_slave_updates = false
binlog_format = STATEMENT
(if you have MIXED or ROW binlog_format configured - verify that you understand what does that means from here http://dev.mysql.com/doc/refman/5.6/en/binary-log-setting.html
If you have a lot of data that is being changed for several times - increasing
innodb_max_dirty_pages_pct to 90 or 95% can be worth checking.
Is it possible to configure slave in-memory database?
Master db is common, slave for read only operation could suit well into in-memory storage.
If it is not possible with MySQL, what are other database to use such scheme?
It might work for 'simple' slave, such as data size and replication, as well as tolerate lots of limits with the in-memory storage engine.