We have to upgrade our Nexus OSS ver 2.14.2 which is currently running on Windows to the latest Nexus OSS version 3.2.1 but on Linux machine.
What our plan to upgrade is
First 2.14.2 to 2.14.3
Then 2.14.3 to 3.2.1
After that Migration.
Does it sound a proper plan or we should re-consider it? Is there any potential risk? Suggestions are welcome.
Please share your experiences while Upgrading and Migration.
Your plan is good, upgrade to 2.14.3 first, then go to 3.2.1. Both upgrades are very safe. And in fact, in the case of the 3.2.1 upgrade your existing 2.14.3 will be left intact. The upgrade from 2 to 3 imports the configuration and data from Nexus 2 while leaving the original instance untouched.
Related
Im trying to install mysql on SUSE 15 Sp2 :
Followed steps from official documentation :
https://dev.mysql.com/doc/mysql-sles-repo-quick-guide/en/
But when i tried to install the mysql getting following error :
Problem: nothing provides 'libc.so.6(GLIBC_2.28)(64bit)' needed by the
to be installed mysql-community-server-8.0.29-1.sl15.x86_64
Solution
1: do not install mysql-community-server-8.0.29-1.sl15.x86_64
Solution 2: break mysql-community-server-8.0.29-1.sl15.x86_64 by
ignoring some of its dependencies
According to the list of platforms that are supported by this version of MySQL, version 15.3 of openSUSE is required. That's probably what's going wrong here: The version of glibc which is provided by the repositories of your openSUSE 15.2 is too old for this MySQL version. If possible, I would recommend you backup your system and then upgrade to 15.3 and then to 15.4, see these instructions. Especially when you intend to do development, it's really wise to first upgrade your OS to the latest version, because only then will you have the latest versions of the technologies you're learning – otherwise, some things you learn will be outdated from day one.
How should we plan Nexus Oss 2.14.3 upgrade to Nexus Oss 3.2.1 if Version 2.14.3 and version 3.2.1 running on the same server??
Please share your suggestions
Use the upgrade instructions here: http://books.sonatype.com/nexus-book/reference3/upgrading.html#upgrade-version-two-three since they are both on the same server I'd recommend using the "File System Hard Linking" transfer method, that will be far faster than any other method.
I am trying to start a new application Ruby on Rails 3.1 on Debian Squeeze with MySQL Server 5.1 (the latest supported by Debian stable version).
I have problem with the mysql2 gem. When I use mysql2 gem version 0.2.6 rake migrations fail with error undefined method rows for nil class. I gooogled and everybody says that this error is resolved when one upgrades mysql2 gem to 0.3.X. However, when I do this upgrade I get another error about gem having been compiled for 5.5 mysql client and not 5.1.
Any help would much appreciated. Maybe the answer is "NO. YOU CANNOT DO IT". Even then, I want to know that.
Thanks in advance
Panayotis
Well, this is a tricky question. My current rails package latest version is 2.3.5-1.2+squeeze2 and the current mysql-server package is 5.1.49-3, both from the stable debian repositories.
However, you're trying to install RoR 3.1. That means you're not on stable or you are not trying to install it from any of the official debian repository at all (it is not wheeze nor sid).
If you can install the stable version of rails, go ahead and I bet you won't have any trouble. Otherwise, if you want the most current release I'm pretty sure you'll have to go for the dirty way. It might probably involve download a 5.5 MySQL (not from the repositories, because it isn't there) and messing with the libraries.
Remember if you require newer packages (such as newer libraries) and you don't want to use the testing repositories, you can always give debian backports a try.
I've read through a number of pages detailing the version differences between the different MySQL versions, but none of them have given me a real clear picture as to what is best for the application I am making. I'm in the process of building a CRM which will handle 20,000 customers at launch and built on a LAMP stack. The OS will either be CentOS or FreeBSD.
Right now for test purposes we've been using a MySQL 5.0 server for the database, but we are wondering which version we should use for production. If anyone could give some thoughts as to the pros and cons of using 5.0 vs 5.1 vs 5.5 vs 5.6 in the context of a CRM application, it would be most appreciated.
TL;DR 5.5
For a new software rollout, it makes sense to integrate and do final testing with the latest generally available (GA) release of your infrastructure components.
Right now that's 5.5.20 of the MySQL community server. 5.6.x is considered a development release. It probably doesn't make sense for you to try to do integration and final testing with such a release, unless it offers a new feature that's a critical success factor for your new software. (But then you should ask yourself whether it makes sense to make your product dependent on exotic new features in unfinished dbms releases.)
EDIT... #rkosegi has a good point. If you're going to deploy on an enterprise grade linux server distro like Red Hat Enterprise Linux (rhel) use the version it supports. 5.1 works fine.
I think better you should use v5.1.XX because it's in active development state and stable too.
MySQL has stopped working on v5.0 i guess extend support also will expire soon.
http://dev.mysql.com/doc/refman/5.0/en/
MySQL 6.0 is for production. Can I use it for database storage of a large project?
MySQL 5.1 is the latest stable version, I'd recommend sticking with that. 6.0 will be quite unstable at this point.
EDIT as of 2011-05-26 MySQL 5.5.12 is the latest stable version. See this link for the lastest stable version: http://dev.mysql.com/downloads/
MySQL 6.0 in this moment is a alpha version, so I suggest you to use the current stable release -> MySQL 5.1
Here you can find some info about the table size limit depending on operating System. MySQL has not internal limit.
Only if there are critical enhancements that your site requires. And even then I'd hold back and use workarounds until it at least gets to beta.
We tried to use the latest PHP and MySQL 5.1 with failure on an IIS7 machine. I am sure if you download the source of PHP and compile it, it would have support for 5.1, but out of the box it seems to support 5.0. So, we replaced 5.1 with 5.0 and everything worked flawlessly.
Short story is use what works well. I would try it in development and avoid it in production until everything works well.