I upgraded my dev server with mysql 8.0.24 but it doesn't work for me. I keep getting a fatal crash every time a query uses GROUP_CONCAT(DISTINCT... and there are no rows because of the WHERE. Anyway, I'd like to rollback to 8.0.23. Was the file format upgraded? Can I safely go back to 8.0.23?
Thank you.
After some reading, it's not easy to downgrade mysql. Mysql itself says it's not possible: https://dev.mysql.com/doc/refman/8.0/en/downgrading.html
I found some possible solution: https://subscription.packtpub.com/book/big_data_and_business_intelligence/9781788395809/1/ch01lvl1sec18/downgrading-from-mysql-8-0
But in the end, I decided to revert the whole dev server to the last backup; that was easier, just a few clicks and back on my feet.
Related
We have Oracle11gR1 and Oracle18c.
Perl clients(11.7.0.1) have to access to both version so far.
But Oracle client(11.7.0.1) were recommended to upgrade to new one(12.1.0.2)
according to Doc ID 207303.1 - 'Client / Server Interoperability Support Matrix '
I'd like to hava 2 version of DBD:Oracle on the same clinet.
one for 11.7.0.1.
another for 12.1.0.2.
Because We can back to stable one immediately if new one caused problems.
How can I do that?
or
Impossible? Why?
I was successfully to install the following,
oracle-instantclient12.1-devel-12.1.0.2.0-1.i386.rpm
oracle-instantclient12.1-basic-12.1.0.2.0-1.i386.rpm
After re-install DBD::Oracle,V$SESSION_CONNECT_INFO shows them to '12.1.0.2'.that's I expected.
My Question is
How to switch back and force between 2 version of Oracle clinet of DBD::Oracle for just in case.
Because We can back to stable one immediataly if new one caused problems.
Ideally, By changing $ORACLE_HOME or $LD_LIBRARY_PATH could be achieved I hope.
Otherwise, A lot of task will be needed like that changing $ORACLE_HOME or $LD_LIBRARY_PATH and re-complile DBD:Oracle to switch them in everytimes.
Does anyone have good advise?
Thanks in advance.
I have a CodeIgniter setup that has been running fine for the past 2 months and recently I keep getting:
CodeIgniter error- unable to connect to database using the provided settings
I've recently added a new domain that has a landing page for the database login (zPanel), but I don't see how that could have caused a problem--maybe the page keeps getting directory attacked or something, but I'm not sure.
Is there a way to check if this is the problem through logs? I'm at dead ends with this problem, as when I restart the server (DigitalOcean) it works fine again.
Really not sure. If anyone else has had a similar problem, I'd love to hear your solution.
Thanks.
I think your mysql is going down so Codeigniter can't connect to your database settings.
Please login to SSH and check processes by "TOP" comment. See what is using resources ram or cpu.
And check your mysql conf settings, be sure that everything written if its empty it will cause alot of problems.
Some example :
http://www.maxwhale.com/how-to-optimize-mysql-for-1gb-memory-vps/
I'm setting up a new website and the site uses asp.net membership. This was working fine but today when I try and log in or do anything such as add a new user/role in the asp.net configuration wizard I get:
Warning: Fatal error 9001 occurred at Jul 30 2012 7:52PM. Note the error and time, and contact your system administrator.
Searching online, it seems to suggest that the logs are full, but I'm advised by the website host that there is ample free space, so I dont really know what to try next.
Has anyone come accross this before and if so, how did you manage to resolve it?
Thanks
I have had this problem recently too and after mountains of research it appears to be common when a database is set to AUTO CLOSE. I set all the databases to AUTO CLOSE = FALSE. This started with one database then went over to two and the next it was on all of them. I simply restarted the SQL Server Instance Service instead of restoring databases. Another way to fix the symptom is to take the problematic database offline and bring it back online again.
As it turns out this was a database issue. I couldn't even create a new table or drop a table and ultimately had to get the database restored, which solved everything.
Here is how setup looks like:
ApplicationServer - GlassFish
Database Server - Oracle 10g2
Persistance Library - EclipseLink
Faces Framework - IceFaces
My Problem is that everytime I change the database connection the application/eclipselink stops working, failing to find the Persistance Unit.
After loosing a whole day trying to figure it out. I decided to delete all the information about connections and persistance units and use only one new created.
Building the project was not a problem, but running it I get an error, pointing that the there is a validationexception and a persistance unit with a given name was not found. That name is deleted and is't descriped in the persistance.xml nor in the sun-resources.xml. There is no such entry in the Services in Netbeans.
Have you seen such an error, and how can I make sure, that netbeans doesn't store information on places I can't reach from the IDE? How is it so that my application is looking for something that isn't listed anywhere...
Okay next time I have to think more, instead of asking the question here. So my problem was the cache directory of Netbeans 6.9.1.
Deleted the cache directory and everything started working again.
I hope that this problem is fixed in the next releases. it can be real pain in ... :)
I am upgrading an existing magento website for 1.4 to 1.6.1.0.
I had dumped the existing database,
Copied all the required custom extension in the blank magento version 1.6.1.0
and after running the installation got the following error:
Error in file:
"/app/code/core/Mage/Customer/sql/customer_setup/mysql4-upgrade-1.5.9.9-1.6.0.0.php"
- SQLSTATE[HY000]: General error: 1025 Error on rename of './sales_flat_order' to './#sql2-3af-a7' (errno: 152)
How can I fix this issue?
Upgrading magento is very painful process. I suggest you to import-export data from old to new shop.
I just went through the same heartburn. I found that letting the page try to load until the script got an error or timed out and then trying again eventually worked. The upgrade script will attempt to start where it last stopped.
Before you do that, make a backup of you site and database. If it continually errors in the same spot, restore and try again.
These tips may help improve the odds of a quicker success:
Put the site in maintenance mode (by adding the maintenance.flag file
to the root directory) before starting.
Increase server and php timeouts by a very large amount (3-5minutes).
Cleanup temp and log database tables that you don't care about
(carefully, everybody has different needs here)
I tried several different methods and that is the only thing that worked. It took probably 10 reloads (waiting for a 3min timeout each time). In the end, everything upgraded correctly. No matter what method you choose, if you want to keep your store data, you will have to run the bulky db upgrade scripts that take forever.
I had similar issues when updating from 1.4.2 to latest.
I built a custom maintenance script included in my index.php that only allowes to access my ip. But the update process via shell replaced my index.php so it was accessible for everyone.
That was the cause that the final sql scripts where run by several clients and caused errors like "can't move table" etc. because those steps where already done.
--> Summing it up: Be sure that the site gets called only once, until the upgrade was successful!
The very best way to migrate magento in my opinion, is to import your entire db to an environment that you have your new magento. Then magento will run all scripts and updates and keep your data.
Maybe you find some problems on the upgrade scripts, but it's easier to fix them than fix the problems regarding model/eav's problems on the fly.
I have succeed by doing this on migrate from 1.4.1 to 1.8.1.