We just stared migration test on some medium sized moodle sites, about 6-7k user and 15GB moodledata, about 200 courses.
As a first test, we are trying with http upgrade. Course file migration (abut 15 minutes) ok, Blog attachment migration ok, then after about 5 minutes without messages, migration stopped with the following error: "Error reading from the database".
The docs link in the error message points to "dmlreadexception", which is void. Anyone experienced a similar issue?
Yes. Exactly the same with us with all our instances. Some similar size some smaller.
Have you got debugging turned up to the highest level, and if so, do you get more information and/or a stack trace?
It looks something related to syntax:
Notice: Undefined property: stdClass::$siteadmins in /var/www/moodle20/lib/datalib.php on line 79
Error reading from database
Notice: Undefined property: stdClass::$siteadmins in /var/www/moodle20/lib/datalib.php on line 79
Error reading from database
Debug info: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ')' at line 3
SELECT u.*
FROM mdl_user u
WHERE u.deleted = 0 AND u.id IN ()
[array (
)]
SELECT u.*
FROM mdl_user u
WHERE u.deleted = 0 AND u.id IN ()
[array (
)]
Stack trace:
- line 378 of /lib/dml/moodle_database.php: dml_read_exception thrown
- line 632 of /lib/dml/mysqli_native_moodle_database.php: call to moodle_database->query_end()
- line 81 of /lib/datalib.php: call to mysqli_native_moodle_database->get_records_sql()
- line 59 of /lib/datalib.php: call to get_admins()
- line 1208 of /lib/db/upgrade.php: call to get_admin()
- line 1233 of /lib/upgradelib.php: call to xmldb_main_upgrade()
- line 256 of /admin/index.php: call to upgrade_core()
Thanks Eloy, according to tracker it should now be fixed, just done a CVS update and tried again the update. Error changed to the following:
DDL sql execution error
DDL sql execution error
Debug info: Data truncated for column 'blockname' at row 93
ALTER TABLE mdl_block_instances MODIFY COLUMN blockname VARCHAR(40) NOT NULL DEFAULT '' after id
ALTER TABLE mdl_block_instances MODIFY COLUMN blockname VARCHAR(40) NOT NULL DEFAULT '' after id
Stack trace:
- line 384 of /lib/dml/moodle_database.php: ddl_change_structure_exception thrown
- line 493 of /lib/dml/mysqli_native_moodle_database.php: call to moodle_database->query_end()
- line 86 of /lib/ddl/database_manager.php: call to mysqli_native_moodle_database->change_database_structure()
- line 73 of /lib/ddl/database_manager.php: call to database_manager->execute_sql()
- line 634 of /lib/ddl/database_manager.php: call to database_manager->execute_sql_arr()
- line 670 of /lib/ddl/database_manager.php: call to database_manager->change_field_type()
- line 1936 of /lib/db/upgrade.php: call to database_manager->change_field_notnull()
- line 1233 of /lib/upgradelib.php: call to xmldb_main_upgrade()
- line 256 of /admin/index.php: call to upgrade_core()
Uhm,
afaik that only can happen if your DB still has some records in the block_instances table with their blockname field being null (as far as that SQL only tries to make the column not null).
Can you try to execute this (in your "broken" site) and post results in the Tracker (referencing to this discussion?).
Ciao
afaik that only can happen if your DB still has some records in the block_instances table with their blockname field being null (as far as that SQL only tries to make the column not null).
Can you try to execute this (in your "broken" site) and post results in the Tracker (referencing to this discussion?).
SELECT *
FROM mdl_block_instances
WHERE coalesce(blockname, 'NULLFOUND') = 'NULLFOUND'
Ciao
The original error has gone (thanks!), but I now get an error during the wiki upgrade section. Any thoughts?
Hi Michael,
afaik that happens when you have different encodings/collations in your tables. Moodle don't set those collations at all but they are defined based in the default encoding/collation set at DB level.
So, at some time in the live of your site... I guess you've had 'utf8_general_ci' as default database encoding (so all the tables and fields were created with it) and later, at some time, it changed to 'utf8_unicode_ci', so tables and fields started being created with that.
And everything works ok BUT when tables having different encodings/collations are used in the same query, throwing the error above.
So I'd suggest you to:
1) look for your current default database encoding/collation.
2) Alter all tables and modify all fields to use it (this is a manual process afaik).
Note: it's not real important when you choose one or the other if your site is english based. In other cases, you should try to find the best one suiting your language ordering exceptions and so.
Ciao
afaik that happens when you have different encodings/collations in your tables. Moodle don't set those collations at all but they are defined based in the default encoding/collation set at DB level.
So, at some time in the live of your site... I guess you've had 'utf8_general_ci' as default database encoding (so all the tables and fields were created with it) and later, at some time, it changed to 'utf8_unicode_ci', so tables and fields started being created with that.
And everything works ok BUT when tables having different encodings/collations are used in the same query, throwing the error above.
So I'd suggest you to:
1) look for your current default database encoding/collation.
2) Alter all tables and modify all fields to use it (this is a manual process afaik).
Note: it's not real important when you choose one or the other if your site is english based. In other cases, you should try to find the best one suiting your language ordering exceptions and so.
Ciao
Just confirming that I'm getting what appears to be the same debug messages.
Thanks Eloy for the tracker reference.
Thanks Eloy for the tracker reference.
