I have a slave database that bears a different name than it's production counterpart. (We'll call prod database and slave database_slave.)
When I run a mysqldump from the slave (which I do for making dev copies), two of the database views have the database name attached to them. I cannot use the dump file to create another copy without manually editing it.
If I run the same mysqldump from the production copy, everything comes out clean. So for some reason the slave has created these two views incorrectly. (The other four views were created before replication was established, which I believe explains the difference. I have confirmed replication is in sync.)
Snippet of the mysqldump from the slave:
/*!50001 VIEW `database_slave`.`view_company` AS select `database`.`company`.`id` AS `id`,
`database`.`company`.`name` AS `name`,`database`.`company`.`state` AS `state`,
Same snippet of the mysqldump, but from production (nice and clean):
/*!50001 VIEW `view_company` AS select `company`.`id` AS `id`,
`company`.`name` AS `name`,`company`.`state` AS `state`,
Can I fix this without having to dump from prod to the slave?
We are using replicate-rewrite-db option.
In replication setup slave databases (and all database objects) are expected to be called the same as on master server.
In case anybody comes searching for this, what I learned is that mysql views are built with the database name intact. Therefore when using the replicate-rewrite-db option to give the slave a different name, the views will NOT work correctly.
The only way I've found to work around this is to avoid using the replicate-rewrite-db flag.
Related
I am using redis version 2.8.3. I want to build a redis cluster. But in this cluster there should be multiple master. This means I need multiple nodes that has write access and applying ability to all other nodes.
I could build a cluster with a master and multiple slaves. I just configured slaves redis.conf files and added that ;
slaveof myMasterIp myMasterPort
Thats all. Than I try to write something into db via master. It is replicated to all slaves and I really like it.
But when I try to write via a slave, it told me that slaves have no right to write. After that I just set read-only status of slave in redis.conf file to false. Hence, I could write something into db.
But I realize that, it is not replicated to my master replication so it is not replicated to all other slave neigther.
This means I could'not build an active-active cluster.
I tried to find something whether redis has active-active cluster capability. But I could not find exact answer about it.
Is it available to build active-active cluster with redis?
If it is, How can I do it ?
Thank you!
Redis v2.8.3 does not support multi-master setups. The real question, however, is why do you want to set one up? Put differently, what challenge/problem are you trying to solve?
It looks like the challenge you're trying to solve is how to reduce the network load (more on that below) by eliminating over-the-net reads. Since Redis isn't multi-master (yet), the only way to do it is by setting up each app server with a master and a slave (to the other master) - i.e. grand total of 4 Redis instances (and twice the RAM).
The simple scenario is when each app updates only a mutually-exclusive subset of the database's keys. In that scenario this kind of setup may actually be beneficial (at least in the short term). If, however, both apps can touch all keys or if even just one key is "shared" for writes between the apps, then you'll need to bake locking/conflict resolution/etc... logic into your apps to consolidate local master and slave differences (and that may be a bit of an overkill). In either case, however, you'll end up with too many (i.e. more than 1) Redises, which means more admin effort at the very least.
Also note that by colocating app and database on the same server you're setting yourself for near-certain scalability failure. What will happen when you need more compute resources for your apps or Redis? How will you add yet another app server to the mix?
Which brings me back to the actual problem you are trying to solve - network load. Why exactly is that an issue? Are your apps so throughput-heavy or is the network so thin that you are willing to go to such lengths? Or maybe latency is the issue that you want to resolve? Be the case as it may be, I recommended that you consider a time-proven design instead, namely separating Redis from the apps and putting it on its own resources. True, network will hit you in the face and you'll have to work around/with it (which is what everybody else does). On the other hand, you'll have more flexibility and control over your much simpler setup and that, in my book, is a huge gain.
Redis Enterprise has had this feature for quite a while, but if you are looking for an open source solution KeyDB is a fork with Active Active support (called Active Replica).
Setting it up is just a little more work than standard replication:
Both servers must have "active-replica yes" in their respective configuration files
On server B execute the command "replicaof [A address] [A port]"
Server B will drop its database and load server A's dataset
On server A execute the command "replicaof [B address] [B port]"
Server A will drop its database and load server B's dataset (including the data it just transferred in the prior step)
Both servers will now propagate writes to each other. You can test this by writing to a key on Server A and ensuring it is visible on B and vice versa.
https://github.com/JohnSully/KeyDB/wiki/KeyDB-(Redis-Fork):-Active-Replica-Support
I've got two SQL Servers, one of these servers (Server A) is backing up transaction logs on some database and uploading them to the other (Server B). Unfortunately I have no access to Server A, I simply have to trust that it is doing its job of periodically uploading its transaction logs to Server B.
Now, suppose Server B needs to recover the database for whatever reason. Doing this will break its ability to receive further transaction log backups.
Is there any way to copy/branch/backup the restoring database, so I can have one version of it that will continue to apply the transaction logs, and one version that will be recovered for reading/writing?
Unfortunately you can't use snapshot to bring a log-shipping backup instance online. You might be able to do it if the data resides on a san where you can force a fast lun copy and then mount a second copy of it real quick. Even without a SAN you can basically, between log loads or while you let them stack up for a bit, offline the DB, copy the files, and then bring up the copied version. Ugly but it gets the job done.
If you can get both DBs involved up to 2012 then I'd recommend you read up on AlwaysOn Availability Groups. http://technet.microsoft.com/en-us/library/hh510230.aspx They are cool because you can leave the second copy online in read-only mode while it is mirroring, all the time. Thus the stupid, almost repetitive, name for what should have been called something simple like "Live Mirroring".
Also, questions like this might better be asked on one of the sister sites like http://ServerFault.com or https://dba.stackexchange.com/
I am new with redis and I didn't figured out how to create and change to another redis database.
How do I do this?
By default there are 16 databases (indexed from 0 to 15) and you can navigate between them using select command. Number of databases can be changed in redis config file with databases setting.
By default, it selects the database 0. To select a specified one, use
redis-cli -n 2 (selects db 2)
Note: this is not a direct answer to the OP's question. However, this text is too long for a comment, and I thought I'd share it anyway, to clarify things to the OP. Hope I don't break too many SO rules by doing this...
Some extra info on multiple databases:
Please note that using multiple databases in one redis instance is discouraged.
It is a nice feature for playing around and getting to know redis.
In more serious setups, if you have multiple ports at your disposal, it's preferred and more performant to use separate instances. At our company, we run about 50 instances on the development/staging server, and about 5 on the production server.
The reason is, that redis transactions are only atomic within one db number anyway. Most (if not all) clients nicely seperate that for you in the connect() phase. And if you have to connect separately, it's just as easy to connect to a different port.
The core of redis is also single threaded. That's one of the things that makes redis so quick and simple. Everything is sequential. If you use multiple instances instead of just one, you gain the benefit of multi-processing (on multi-core machines).
redis-cli //connect server firstly
redis-cli info //show all existing database - at the bottom
//exit
redis-cli -n 1 //1 is the name of database
Not so far ago I was faced with the trouble of dynamically transferring data from one database to another.
The only reason to do that for me is when first database server go down, the system can use second server.
For this purpose i used Transaction Log Shipping service.
As far as i can see, it working fine now and copying logs from one server to another every 15 min.
My question is, when the critical moment comes, and the first server will down, how can i use the database on the second server?
As i can see now, the database says that it "Restoring..." and i can do nothing with it.
I understand that this is because it staying in sync with first server.
But when i need that database, how can i switch it into normal mode, when i can query it and modify ?
Thanks a lot!
It should not be in the restoring state. It should be in 'read-only' mode. As far as I remember setting this thing up. So you basically strip the read-only mode and use it as if it were your primary database.
I am adding a monitoring script to check the size of my DB files so I can deliver a weekly report which shows each files size and how much it grew over the last week. In order to get the growth, I was simply going to log a record into a table each week with each DB's size, then compare to the previous week's results. The only trick is where to keep that table. What are the trade-offs in using the master DB instead of just creating a new DB to hold these logs? (I'm assuming there will be other monitors we will add in the future)
The main reason is that master is not calibrated for additional load: it is not installed on IO system with proper capacity planning, is hard to move around to new IO location, it's maintenance plan takes backups and log backups are as frequent as needed for a very low volume of activity, its initial size and growth rate are planned as if no changes are expected. Another reason against it is that many troubleshooting scenarios you would want a copy of the database to inspect, but you'd have to attach a new master to your instance. These are the main reasons why adding objects to master is discouraged. Also many admins understandably prefer an application to use it's own database so it can be properly accounted for, and ultimately easily uninstalled.
Similar problems exist for msdb, but if push comes to shove it would be better to store app data in msdb rather than master since the former is an ordinary database (despite widespread believe that is system, is actually not).
The Master DB is a system database that belongs to SQL Server. It should not be used for any other purposes. Create your own DB to hold your logs.
I would refrain from putting anything in master, it could be overwritten/recreated on an upgrade.
I have put a DBA only ServerInfo database on each server for uses like this, as well as any application specific environmental things (things that differ between prod and test and dev).
You should add a separat database for the logging. It is not garanteed that the master database is not breaking the next patch of sql server if you leave your objects in there.
And microsoft itself does advise you to not do it.
http://msdn.microsoft.com/en-us/library/ms187837.aspx