Moodle upgrade from 1.9 to 2.0

Moodle upgrade from 1.9 to 2.0

Rama Gundabhat -
回帖数:21

While upgrading moodle from 1.9 to 2.0 I got this error during the course conversion (I mean during upgrading Moodle database from version 1.9.16+ (Build: 20120127) (2010061900.08) to 2.0.9 (Build: 20120514) (2011033009)

Can some help to fix this issue please
 
 
Debug info: Illegal mix of collations (utf8_general_ci,IMPLICIT) and (utf8_unicode_ci,IMPLICIT) for operation '='
SELECT DISTINCT c.id AS courseid, ra.enrol, c.timecreated, c.timemodified
FROM mdl_course c
JOIN mdl_context ctx ON (ctx.instanceid = c.id AND ctx.contextlevel = 50)
JOIN mdl_role_assignments ra ON (ra.contextid = ctx.id AND ra.enrol <> '')
LEFT JOIN mdl_enrol e ON (e.courseid = c.id AND e.enrol = ra.enrol)
WHERE c.id <> ? AND e.id IS NULL
[array (
0 => '1',
)]
Stack trace:
  • line 391 of /lib/dml/moodle_database.php: dml_read_exception thrown
  • line 768 of /lib/dml/mysqli_native_moodle_database.php: call to moodle_database->query_end()
  • line 4093 of /lib/db/upgrade.php: call to mysqli_native_moodle_database->get_recordset_sql()
  • line 1393 of /lib/upgradelib.php: call to xmldb_main_upgrade()
  • line 273 of /admin/index.php: call to upgrade_core()

 

httpd debug log:

 

Default exception handler: Error reading from database Debug: Illegal mix of collations (utf8_general_ci,IMPLICIT) and (utf8_unicode_ci,IMPLICIT) for operation '='\nSELECT DISTINCT c.id AS courseid, ra.enrol, c.timecreated, c.timemodified\n                  FROM mdl_course c\n                  JOIN mdl_context ctx ON (ctx.instanceid = c.id AND ctx.contextlevel = 50)\n                  JOIN mdl_role_assignments ra ON (ra.contextid = ctx.id AND ra.enrol <> '')\n             LEFT JOIN mdl_enrol e ON (e.courseid = c.id AND e.enrol = ra.enrol)\n                 WHERE c.id <> ? AND e.id IS NULL\n[array (\n  0 => '1',\n)]\n* line 391 of /lib/dml/moodle_database.php: dml_read_exception thrown\n* line 768 of /lib/dml/mysqli_native_moodle_database.php: call to moodle_database->query_end()\n* line 4093 of /lib/db/upgrade.php: call to mysqli_native_moodle_database->get_recordset_sql()\n* line 1393 of /lib/upgradelib.php: call to xmldb_main_upgrade()\n* line 273 of /admin/index.php: call to upgrade_core()\n, referer: http://moodletest/moodle/admin/index.php?confirmupgrade=1&confirmrelease=1

 

 

回复Rama Gundabhat

Re: Moodle upgrade from 1.9 to 2.0

Colin Fraser -
Documentation writers的头像 Testers的头像

I seriously suggest you download a v2.2 then try upgrading with that. There were a number of database issues with v2.0 that took a while to get around, particularly when there were third-party plugins involved, and some types of questions and a number of hosts installer scripts, as well as a few other things. If you are really using v2.0, then this could be something new so I would use something different, like a later version. I would recommend here that you use your backups to restore your v1.9 and then recreate it on a stand-alone. Use the standalone as a test to upgrade in a number of different ways before you do anything at all to your production site. Make sure you know what can go wrong and how to get around it first. The environment does not have too much influence at this point, unless the environment is not up to the requirements of Moodle.   

Suggest what you do is to remove any non-core blocks or plugins, delete the v1.9 code from the Moodle, keeping the config.php file only, then paste in the new code. On a server, use FTP to delete and paste.Then run it and all things being equal, the database should be properly converted, the moodledata folder will be properly restructured and it will usuallly work as it should. This method updates your entire database and will allow you to access any legacy files that you may be using.   

回复Colin Fraser

Re: Moodle upgrade from 1.9 to 2.0

Rama Gundabhat -

Thanks Colin but before I saw this I fixed the issue but faced couple of more issues . RIght now I am stuck with "DDL sql execution error" while upgrading the database. Now, from this point can I download v2.2 and upgrade it.

Appreaciate the quick response

回复Rama Gundabhat

Re: Moodle upgrade from 1.9 to 2.0

Colin Fraser -
Documentation writers的头像 Testers的头像

Well, I suspect it is going to cascade from here, one problem leads to another then another then another, that is the usual thing for me. Can you restore your original database? If so, then stop and dump the lot, restore your original and begin afresh. Keep the database and moodledata folder just replace the code, using the old config.php file. This should upgrade without too much drama and allow you to retain any legacy files. 

This is why whenever I do things, I always use my test site first, that way any problems I am likely to encounter are resolved before I do anything. The other issue is I have no third-party plugins or blocks. Any tweaked code is recorded and can easily be replicated, if found of course..微笑 I use common themes, not locally created site specific themes so the problems I have are minimised. 

回复Colin Fraser

Re: Moodle upgrade from 1.9 to 2.0

Rama Gundabhat -

ok I will restore the 1.9 DB and use old config.php file. But What do you mean by "just replace the code ". I am sorry I am new to this system.

Here is what I am planning to do.

1. Restore the DB

2. Download latest 2.2 which is Moodle 2.2.4+

3. restore the old config.php . untar the build and run the upgrade through the browser.

Do I need to take care of anything else. I have all the required environment ready.

回复Rama Gundabhat

Re: Moodle upgrade from 1.9 to 2.0

Colin Fraser -
Documentation writers的头像 Testers的头像

First, check to make sure that everything is working as it should be. Then using your FTP program to "delete the code" which means precisely that. Do not delete the database, do not delete the moodledata folder, do not delete the config.php file - delete the code in the moodle folder, all the files, all the existing folders. Then untar the Moodle you have just downloaded on your local machine and FTP it into the Moodle folder that you have just emptied. add in the config.php file then go to your site in your browser.  

Dan, that was my first thought, but why was the v1.9 working if it had changed the charset? Or perhaps the installer of the v2.0 was cPanel or Fantastico, in which case, the ALTER command has not always done what it needs to have done in MySQL, and has also generated other problems. These seemed to happen with v2.0, but not with later versions. Then the other issues started coming up as we saw when v2.0 was originally introduced. Rather than waste any more time, I suggest this is a quicker, if less tidy, option. 

回复Colin Fraser

Re: Moodle upgrade from 1.9 to 2.0

Rama Gundabhat -

here is what I did,

1. Deleted the moodle code.

2. took a copy of config.ohp

3. tar  v 2.2 and copied over the config.php

4. started the moodle on the browser

5. it shows me that Server checks is all ok and then shows the list of plugins and when I click on upgrade on this page I get below error. I am doing this upgrade with v1.9 DB

Table "upgrade_log" already exists

More information about this error

Stack trace:
  • line 469 of /lib/ddl/database_manager.php: ddl_exception thrown
  • line 93 of /lib/db/upgrade.php: call to database_manager->create_table()
  • line 1394 of /lib/upgradelib.php: call to xmldb_main_upgrade()
  • line 236 of /admin/index.php: call to upgrade_core()
回复Rama Gundabhat

Re: Moodle upgrade from 1.9 to 2.0

Rama Gundabhat -

I think I bypassed this error. I created a new blank database and restored it with copy of my v1.9 Db and started the upgrade. I am at "Migrate course files" . Will update how it goes

回复Rama Gundabhat

Re: Moodle upgrade from 1.9 to 2.0

Rama Gundabhat -

now I got collation error  Illegal mix of collations (utf8_general_ci,IMPLICIT) and (utf8_unicode_ci,IMPLICIT) for operation '=

and resolved this by the solution below but now I am stuck with below error while "updating tags itemtype". Any ideas please

 

Error writing to database

More information about this error

Debug info: Table 'moodleDB.mdl_context_temp' doesn't exist
DELETE FROM mdl_context_temp
[array (
)]
Stack trace:
  • line 397 of /lib/dml/moodle_database.php: dml_write_exception thrown
  • line 1096 of /lib/dml/mysqli_native_moodle_database.php: call to moodle_database->query_end()
  • line 1613 of /lib/dml/moodle_database.php: call to mysqli_native_moodle_database->delete_records_select()
  • line 6756 of /lib/accesslib.php: call to moodle_database->delete_records()
  • line 5346 of /lib/accesslib.php: call to context_block::build_paths()
  • line 1413 of /lib/upgradelib.php: call to context_helper::build_all_paths()
  • line 236 of /admin/index.php: call to upgrade_core()
回复Rama Gundabhat

Re: Moodle upgrade from 1.9 to 2.0

Colin Fraser -
Documentation writers的头像 Testers的头像

Go back to your earlier post, you said that you ran the ALTER table command. If you have a copy of phpMyAdmin, look to see which tables are utf8_general.ci and change them with the same command. I am somewhat dubious with the idea of using the ALTER database command, that does not always work. You have gotten this far you might as well keep going. As far as the error message is involved, I would suspect that temp tables are created during the process of changing the database. If all the tables are the same type, InnoDB and use the right charset, then it should work.

回复Colin Fraser

Re: Moodle upgrade from 1.9 to 2.0

John Anderson -

To add some credit to this idea - I just upgraded a 1.9M to 2.2M with no DB errors like seen on this thread. Seems to be a lot smarter upgrade code.

Thanks for this suggestion !

回复Rama Gundabhat

Re: Moodle upgrade from 1.9 to 2.0

Rama Gundabhat -

resolved this by

SELECT CONCAT('ALTER TABLE `', t.`TABLE_SCHEMA`, '`.`', t.`TABLE_NAME`, '` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;') as stmt
FROM `information_schema`.`TABLES` t
WHERE 1
AND t.`TABLE_SCHEMA` = 'moodledb'
ORDER BY 1 ;

and

ALTER TABLE `mdl_course` CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;

ALTER TABLE `mdl_context` CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;

ALTER TABLE `mdl_role_assignments` CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;

ALTER TABLE `mdl_enrol` CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;

 

回复Rama Gundabhat

Re: Moodle upgrade from 1.9 to 2.0

Dan Poltawski -
Hi Rama,

It sounds like your default mysql database collation has changed between when your moodle was installed and when it was upgraded (and new tables were created).

You need ensure that the tables are all created with the same collation, this means your mysql client/server configuration needs to stay the same.
回复Rama Gundabhat

Re: Moodle upgrade from 1.9 to 2.0

Howard Miller -
Core developers的头像 Documentation writers的头像 Particularly helpful Moodlers的头像 Peer reviewers的头像 Plugin developers的头像
This is quite common... your collations aren't all the same throughout your database. You need to fix this before you upgrade.

The actuall answer is to run....

ALTER TABLE tablename CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;

...on *every* table, just to be sure. You can automate that with a bit of imagination.
回复Howard Miller

MySQL collation should always be utf8_unicode_ci

Martin Dougiamas -
Core developers的头像 Documentation writers的头像 Moodle HQ的头像 Particularly helpful Moodlers的头像 Plugin developers的头像 Testers的头像

Some work has been done recently to make Moodle be a little smarter about coping with odd collations MDL-34271 but as Howard said, best to just make sure everything is utf8_unicode_ci as recommended in the install docs.

回复Martin Dougiamas

Re: MySQL collation should always be utf8_unicode_ci

AL Rachels -
Core developers的头像 Particularly helpful Moodlers的头像 Plugin developers的头像 Testers的头像

Unfortunately, this is something that needs to be checked on after every "change" to the database. For instance, just yesterday I added some new activities, and when I just read Martin's entry above, I went and looked even though I KNOW I set every table to utf8_unicode_ci just a few days ago. Sure enough one of the new activities had created tables with a different collation...utf8_general_ci.

回复AL Rachels

Re: MySQL collation should always be utf8_unicode_ci

Dan Poltawski -
AL,

After MDL-34271 is integrated (this week) this should no longer be necessary as Moodle will sort it out automatically. We will also have a commandline tool to fix your table collations if previously been incorrectly configured.

(Although this is a server configuration option, you can prevent it by ensuring your mysql settings have consistent collation defaults).
回复Martin Dougiamas

Re: MySQL collation should always be utf8_unicode_ci

Ken Task -
Particularly helpful Moodlers的头像

Strongly suggest that documentation at:
http://docs.moodle.org/23/en/Converting_your_MySQL_database_to_UTF8

Section: Converting a database containing tables
which shows/uses utf8_general_ci to utf8_unicode_ci

'spirit of sharing', Ken

回复Ken Task

Re: MySQL collation should always be utf8_unicode_ci

Ken Task -
Particularly helpful Moodlers的头像

Just to follow up ... and just in case anyone else besides me didn't 'do it right' 伤心 ...

found a php script that will convert all tables in given DB to desired utf8_unicode_ci:

http://stackoverflow.com/questions/105572/a-script-to-change-all-tables-and-fields-to-the-utf-8-bin-collation-in-mysql

Tested on new install of a 2.3.1 and worked without issue.

Wonder if such a script could be included in tools?

Now I get to go back and do 'oodles of Moodles' on multiple servers to get it right. ;)

'spirit of sharing', Ken

回复Ken Task

Re: MySQL collation should always be utf8_unicode_ci

Dan Poltawski -

Hi Ken,

Wonder if such a script could be included in tools?

As I mentioned above, a script will be in 2.2 and 2.3 weekly builds at the end of this week to do just that.

回复Dan Poltawski

Re: MySQL collation should always be utf8_unicode_ci

Ken Task -
Particularly helpful Moodlers的头像

Thanks, Dan.  Saw your previous posting just after 'sharing'.  Looking forward to have a true Moodle integrated tool.  Discovered that placing a home-grown script in moodle/local/ could be executed via CLI or via web without login makes one concerned.

'spirit of sharing', Ken