I recently found out that Cassandra 3.0.0 and PrestoDB don't play well together.
I have a lot of data loaded into Cassandra 3.0 and I wouldn't like to rebuild the whole thing. Is there a safe way to downgrade to 2.x temporarily until Presto is updated, so then I can come back to 3.0?
I know downgrading is not officially supported, but I'm wondering whether more experienced S.O. Cassandra users could point me in the right direction here. I assume the answer will be "don't try it", but who knows, maybe there's a way. Thanks in advance.
Update 2016-11-05 : Using version 0.147 and newer of PrestoDB and this issue has been solved. In the end I did not need to downgrade Cassandra in order to use PrestoDB. Thanks for your replies.
If you've started with 3.0, the only way I can think of is to export all your data then reimport it. The storage format has massively changed and 2.x can't read the 3.0 tables.
Unfortunately sstable2json was removed in 3.0, so you'll probably need to export it all manually then import into a previous version.
Related
I just installed Dspace 4.2. I added some items. But when I access the Community, collection or item statistics in the JSPUI view it does not show any value to me.
Any help ?
Thanks in advance.
if it is a fresh installation I strongly suggest to use a more recent version. My recommendation is to use dspace 5.10
https://github.com/DSpace/DSpace/releases/tag/dspace-5.10
that is the best one in terms of stability, otherwise you can try dspace 6.3
Anyway, the latest version of the 4.x series is the 4.9 https://github.com/DSpace/DSpace/releases/tag/dspace-4.9
The issues is probably due to issue in the SOLR statistics core but without additional information, logs file, is difficult to guess. Take a look to what is logged in the ${dspace.dir}/log/dspace.log ${dspace.dir}/log/solr.log when you access the statistics page
how to monitor/log slow running queries in Apache Cassandra 2.2.X version without using any external monitoring tools? Is there is any parameter that we can set in YAML to log slow running queries? or any other approach?
Also in CASSANDRA-12403, i see they added parameter "slow_query_log_timeout_in_ms: 500" for this purpose. Can we add this parameter in Cassandra 2.2.X version's Cassandra.YAML file? or do we need to apply this patch for 2.2.X version in order to make it work?
Its a feature in a newer version, you can upgrade or apply the patch and go off of a custom build. In 2.2.x theres no support to do it by itself.
Its a bit of a long shot but you might be able to get https://github.com/smartcat-labs/cassandra-diagnostics with https://github.com/smartcat-labs/cassandra-diagnostics/blob/dev/cassandra-diagnostics-core/COREMODULES.md#slow-query-module to work. It also only supports 2.1 and 3.0 though, I dont see 2.2 there.
I need to upgrade my solr search from 4.7 version to 5.3.1 .
I am working on a linux platform.
Can you please provide me the steps that i need to follow .
Thank you!
I do not think that there is a definitive step by step guide for the upgrade that you are looking for.
I have a 4.3.x SOLR running in a production environment and I am contemplating the leap to upgrade to 5.x. However its clear that a lot has changed and that my upgrade is not going to be straight forward.
Also other priorities in my project have kept me from doing the upgrade.
So rest of the discussion is more a thought process than actual upgrade experience.
Last I researched I found the below links useful
https://support.lucidworks.com/hc/en-us/articles/203776523-How-to-upgrade-between-major-Solr-Versions
https://cwiki.apache.org/confluence/display/solr/Major+Changes+from+Solr+4+to+Solr+5
From the Major changes link you will notice that a lot has changed ..
Most notably there are changes to the index format, SolrJ removal of deprecated API and that the deployment is now as a standalone server instead of a war file.
So I would suggest that you ask yourself the following questions ...
Is it possible to recreate the index from scratch ? How much time does it take to create your complete index ? If your index can be recreated quickly then , I would suggest that you do that using 5.x engine on a separate machine, while your production environment is served by your existing server. Then plan a complete upgrade from 4.x to 5.x by simply pointing your Production instance to the new SOLR engine. This approach will give you a clean slate to start with and a brand new index (but with existing data).
If you have a very large index (e.g. it takes several days to recreate it from scratch), then you may want to perform an upgrade of the live index. In that case I suggest that you consider the following.
The SOLR upgrade guide mentions 4.10 as a version that is 4.x (so I assume its is easy to upgrade from any 4.x to 4.10) and has some features built in to help with the move to 5.x. So first upgrade to 4.10 ensure that your index continues to work properly. Then use the guides mentioned above to upgrade to 5.x
I've been trying to work through an issue that developed while attempting to upgrade our testing environment from 12.04 to 14.04 ubuntu on aws. Prior to this, the Package repository version of solr was 1.4.1 which matched our 1.4.1 solrj client integrated with our application.
Changing the base AMI to the 14.04 latest and running our default deploy caused solr 3.6.2 server to be installed. It appears it was accepting our configs without issue, however when our client tried to connect we received different errors:
The first was an unknown custom field, which we traced back to our deployment scripts not moving our schema.xml and solrconfig.xml to /etc/solr/conf/ but keeping it in the base directory.
We corrected this issue, and then ran into the following:
'exception: Invalid version or the data in not in 'javabin' format'
This was generated by a wrapper ontop of solrj, but I'll be honest and say I know nothing regarding Solr and that this may be on our end. I've asked our dev team to look at 2 options:
1) enabling: 'server.setParser(new XMLResponseParser());'
Which is the recommendation on the backwards compatibility for an older client.
2) updating our client in the application to 3.6.2
-I know less about the requirements on this.
My fall back is to revert to 1.4.1, but it appears it hasn't been touched since 2011, which makes me hesitant.
Any thoughts / suggestions would be appreciated!
Thanks!
I think the best option is to maintain the same version of Solr and Solrj.
I used for a lot of time Solr 1.4.1 and, while as you said, the most part of it works with newer versions without any problem, actually a lot of things have been changed since 1.4.*
I did your same porting last year, (from 1.4.1 to 3.6.1) and I can confirm you that the 2nd way is the right one: all changes you must do in your client code are just "formal" and very very quick.
Any workaround you could do for being able to communicate with a different version (between Solrj and Solr) is just, as the word says, a "workaround" and it could lead to unexpected (hidden) side-effects later.
I have a small code base using Subsonic 2.1 in my project. I would like to start using Subsonic 3.0 as soon as possible. But I don't currently have resources to convert the 2.1 implementation. Is it possible to start using 3.0 for new code and leave the 2.1 code running. Will I have any special conflicts. Anything I should watch for?
I'm pretty sure you can't do this. There would be too many conflicts with the naming of the namespaces and classes.
Very similar question asked a couple of days ago at
use subsonic 2.x and 3.x in the same project
No, you can't run them side by side. Depending on what you're using (ActiveRecord/RepositoryRecord and Query/SqlQuery) migration difficulty will vary. If you're using RepositoryRecord and only SqlQuery queries the migration to the LinqTemplates is not that complicated.