P.S.: piwik-2.15.0-b8 is the first I tried after piwik-2.14.3, so I don't know which beta this issue occurred with first.

More details (including ERROR backtrace below): Same error can be observed after installation on following test procedure:

1. Do a successful installation, i.e.:
   • Start with an empty DB
   • Install piwik-2.14.3 over FTP
   • Remove files of piwik-2.14.3 over FTP
   • Install piwik-2.15.0-b8 over FTP
2. Log into Piwik
3. Call image tracker ([...]/p/piwik.php?idsite=1&rec=1) directly in the browser address bar (I felt too lazy to add a tracker to a website.)
4. Reload the dashboard page
5. Reload the image tracker a few more times
6. Reload the dashboard page

Actual results:
4. The "Visitors in Real Time" widgets shows the visit, but the "Visitors Over Time", "Length of Visits", "Visitor Browser" and "Search Engines" all show SQLSTATE[42000]: Syntax error or access violation: 1286 Unknown table engine 'InnoDB'.

6. Same as in 4, but additionally 6 following errors are shown at the top of the dashboard:

ERROR: Failed to get data from API: SQLSTATE[42000]: Syntax error or access violation: 1286 Unknown table engine 'InnoDB' #0 /srv/www/httpd/[...]/web/p/libs/Zend/Db/Statement.php(300): Zend_Db_Statement_Pdo->_execute(Array) #1 /srv/www/httpd/[...]/web/p/libs/Zend/Db/Adapter/Abstract.php(479): Zend_Db_Statement->execute(Array) #2 /srv/www/httpd/[...]/web/p/libs/Zend/Db/Adapter/Pdo/Abstract.php(238): Zend_Db_Adapter_Abstract->query('CREATE TABLE pi...', Array) #3 /srv/www/httpd/[...]/web/p/core/Db/Adapter/Pdo/Mysql.php(245): Zend_Db_Adapter_Pdo_Abstract->query('CREATE TABLE pi...', Array) #4 /srv/www/httpd/[...]/web/p/core/DataAccess/Model.php(230): Piwik\Db\Adapter\Pdo\Mysql->query('CREATE TABLE pi...') #5 /srv/www/httpd/[...]/web/p/core/DataAccess/ArchiveTableCreator.php(51): Piwik\DataAccess\Model->createArchiveTable('piwik_archive_n...', 'archive_numeric') #6 /srv/www/httpd/[...]/web/p/core/DataAccess/ArchiveTableCreator.php(39): Piwik\DataAccess\ArchiveTableCreator::createArchiveTablesIfAbsent('piwik_archive_n...', 'archive_numeric') #7 /srv/www/httpd/[...]/web/p/core/DataAccess/ArchiveTableCreator.php(25): Piwik\DataAccess\ArchiveTableCreator::getTable(Object(Piwik\Date), 'numeric') #8 /srv/www/httpd/[...]/web/p/core/DataAccess/ArchiveSelector.php(56): Piwik\DataAccess\ArchiveTableCreator::getNumericTable(Object(Piwik\Date)) #9 /srv/www/httpd/[...]/web/p/core/ArchiveProcessor/Loader.php(170): Piwik\DataAccess\ArchiveSelector::getArchiveIdAndVisits(Object(Piwik\ArchiveProcessor\Parameters), 1442779783) #10 /srv/www/httpd/[...]/web/p/core/ArchiveProcessor/Loader.php(66): Piwik\ArchiveProcessor\Loader->loadExistingArchiveIdFromDb() #11 /srv/www/httpd/[...]/web/p/core/Archive.php(894): Piwik\ArchiveProcessor\Loader->prepareArchive('DevicesDetectio...') #12 /srv/www/httpd/[...]/web/p/core/Archive.php(708): Piwik\Archive->prepareArchive(Array, Object(Piwik\Site), Object(Piwik\Period\Day)) #13 /srv/www/httpd/[...]/web/p/core/Archive.php(660): Piwik\Archive->cacheArchiveIdsAfterLaunching(Array, Array) #14 /srv/www/httpd/[...]/web/p/core/Archive.php(598): Piwik\Archive->getArchiveIds(Array) #15 /srv/www/httpd/[...]/web/p/core/Archive.php(369): Piwik\Archive->get('DevicesDetectio...', 'blob', NULL) #16 /srv/www/httpd/[...]/web/p/plugins/DevicesDetection/API.php(36): Piwik\Archive->getDataTable('DevicesDetectio...') #17 /srv/www/httpd/[...]/web/p/plugins/DevicesDetection/API.php(236): Piwik\Plugins\DevicesDetection\API->getDataTable('DevicesDetectio...', '1', 'day', '2015-09-20', false) #18 [internal function]: Piwik\Plugins\DevicesDetection\API->getBrowsers('1', 'day', '2015-09-20', false) #19 /srv/www/httpd/[...]/web/p/core/API/Proxy.php(208): call_user_func_array(Array, Array) #20 /srv/www/httpd/[...]/web/p/core/Plugin/Visualization.php(259): Piwik\API\Proxy->call('\\Piwik\\Plugins\\...', 'getBrowsers', Array) #21 /srv/www/httpd/[...]/web/p/core/Plugin/Visualization.php(180): Piwik\Plugin\Visualization->loadDataTableFromAPI() #22 /srv/www/httpd/[...]/web/p/core/Plugin/ViewDataTable.php(414): Piwik\Plugin\Visualization->buildView() #23 /srv/www/httpd/[...]/web/p/core/Plugin/Report.php(338): Piwik\Plugin\ViewDataTable->render() #24 /srv/www/httpd/[...]/web/p/plugins/CoreHome/Controller.php(78): Piwik\Plugin\Report->render() #25 [internal function]: Piwik\Plugins\CoreHome\Controller->renderReportWidget(Object(Piwik\Plugins\DevicesDetection\Reports\GetBrowsers)) #26 /srv/www/httpd/[...]/web/p/core/FrontController.php(494): call_user_func_array(Array, Array) #27 /srv/www/httpd/[...]/web/p/core/FrontController.php(94): Piwik\FrontController->doDispatch(NULL, NULL, NULL) #28 /srv/www/httpd/[...]/web/p/core/dispatch.php(34): Piwik\FrontController->dispatch() #29
/srv/www/httpd/[...]/web/p/index.php(27): require_once('/srv/www/httpd/...') #30 {main}

As with any other Piwik version before, I patch Piwik by prepending "@" to ini_set() in all cases where it is missing. (Simply by searching for "ini_set" if all files.) I.e. with piwik-2.15.0-b8:

@Joey3000 if you get an error or warning when ini_set is not pre-pended by @ maybe you could issue a pull request for this improvement? (this would avoid you patching Piwik each time)

Usually this error message should mean that the innodb table type is not setup in your mysql. could you double check http://stackoverflow.com/questions/7303133/unknown-table-engine-innodb mysql> show variables like 'have_innodb'; returns YES?

Usually this error message should mean that the innodb table type is not setup in your mysql. could you double check http://stackoverflow.com/questions/7303133/unknown-table-engine-innodb mysql> show variables like 'have_innodb'; returns YES?

It's have_innodb DISABLED. Enabling it is not an option for me - it's a server/DB with its $MYSQL_INSTALL_DIRECTORY/my.ini out of my control. But Piwik 2.14.3 runs without problems with exact same server/DB configuration. (And it also has type = InnoDB in /config/global.ini.php.) Has there been a change requiring have_innodb for Piwik 2.15.0?

I could switch the PHP configuration to MySQLi instead of PDO/MySQL though - would that help?

Has there been a change requiring have_innodb for Piwik 2.15.0?

No there shouldn't be a change that affects this... I don't understand it so far.

Does anyone else experience the issue?

When you mean you install via ftp you mean you install the downloaded version from the piwik.org website right? You already mentioned the config, can you change it to anything else but InnoDB? Does it change anything? See eg http://piwik.org/faq/how-to-install/faq_20200/

Another idea: Maybe it's not due to an update in code but due to some dead locks that suddenly appear. Eg we lock additional infos when there is a deadlock and INNODB is hardcoded there and it can trigger such an error see https://github.com/piwik/piwik/blob/2.15.0-b13/core/Db.php#L712 Feel free to comment this line and try again. Maybe we're lucky and it helps

I've checked the betas and the issue first occurs in piwik-2.15.0-b3. (piwik-2.15.0-b0, piwik-2.15.0-b2 install without a problem; piwik-2.15.0-b3, piwik-2.15.0-b4, piwik-2.15.0-b8, piwik-2.15.0-b13 fail.)

When you mean you install via ftp you mean you install the downloaded version from the piwik.org website right?

Right. I use the .zip files from https://builds.piwik.org/.

You already mentioned the config, can you change it to anything else but InnoDB? Does it change anything? See eg http://piwik.org/faq/how-to-install/faq_20200/

Changing https://github.com/piwik/piwik/blob/2.15.0-b13/config/global.ini.php#L22 from type = InnoDB to type = TokuDB shows similar results:
SQLSTATE[42000]: Syntax error or access violation: 1286 Unknown table engine 'TokuDB'

Whereas removing that line results in:
SQLSTATE[42000]: Syntax error or access violation: 1064 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 'DEFAULT CHARSET=utf8' at line 11

Another idea: Maybe it's not due to an update in code but due to some dead locks that suddenly appear. Eg we lock additional infos when there is a deadlock and INNODB is hardcoded there and it can trigger such an error see https://github.com/piwik/piwik/blob/2.15.0-b13/core/Db.php#L712 Feel free to comment this line and try again. Maybe we're lucky and it helps

Nope, no luck with that line commented out - the error still there:
SQLSTATE[42000]: Syntax error or access violation: 1286 Unknown table engine 'InnoDB'

Is there anything else I could check?

Just in case it helps, here are the backtraces on piwik-2.15.0-b13:

• A standard Piwik backtrace (activated by returning true in https://github.com/piwik/piwik/blob/2.15.0-b13/core/testMinimumPhpVersion.php#L85):
  https://gist.github.com/Joey3000/24eda4245641f931c70d
• A backtrace with all arrays "walked" (i.e. including all array values; using https://gist.github.com/Joey3000/f995df4015a977d07913 function, whose return was added to the above file's error message):
  https://gist.github.com/Joey3000/3937d22edb1c896ee84c

Which MySQL engine are you using? Can you configure the one you're using here in global.ini.php instead of InnoDB or TokuDB:

Changing https://github.com/piwik/piwik/blob/2.15.0-b13/config/global.ini.php#L22 from type = InnoDB to type = TokuDB shows similar results:
SQLSTATE[42000]: Syntax error or access violation: 1286 Unknown table engine 'TokuDB'

Maybe it should be MYISAM?

@tsteur: SHOW ENGINES outputs following:

Engine      Support     Comment                                                 Transactions    XA      Savepoints
InnoDB      NO          Supports transactions, row-level locking, and fore...   NULL            NULL    NULL
MRG_MYISAM  YES         Collection of identical MyISAM tables                   NO              NO      NO
BLACKHOLE   YES         /dev/null storage engine (anything you write to it...   NO              NO      NO
CSV         YES         CSV storage engine                                      NO              NO      NO
MEMORY      YES         Hash based, stored in memory, useful for temporary...   NO              NO      NO
FEDERATED   NO          Federated MySQL storage engine                          NULL            NULL    NULL
ARCHIVE     YES         Archive storage engine                                  NO              NO      NO
MyISAM      DEFAULT     Default engine as of MySQL 3.23 with great perform...   NO              NO      NO

Changing https://github.com/piwik/piwik/blob/2.15.0-b13/config/global.ini.php#L22 from type = InnoDB to type = MyISAM makes the issue disappear.

Questions, just to understand the current behaviour:

1. Why did Piwik versions before piwik-2.15.0-b3 work with type = InnoDB? (I guess some issue which made the type setting in global.ini.php being ignored was fixed in piwik-2.15.0-b3?)
2. Shouldn't global.ini.php use type = MyISAM instead of type = InnoDB, to ensure widest compatibility (also under [database_tests])? Because according to https://dev.mysql.com/doc/refman/5.1/en/show-engines.html:

All MySQL servers support MyISAM tables, because MyISAM is the default storage engine. It is not possible to disable MyISAM.

I'm on the outdated MySQL 5.1.73, but https://piwik.org/docs/requirements/ states that Piwik requires MySQL version 4.1 or greater.

For MySQL 5.5 - 5.7, the default apparently changed from MyISAM to InnoDB, but https://dev.mysql.com/doc/refman/5.7/en/show-engines.html still states for version 5.7:

All MySQL servers support MyISAM tables. It is not possible to disable MyISAM.

Or maybe the engine could be configurable on installation (as a text input box)? With MyISAM as default value.

Notes:

• Since MySQL 5.1.5, there is an ENGINES table - see https://dev.mysql.com/doc/refman/5.1/en/engines-table.html. That would probably allow using a drop-down for engine selection on installation (instead of a text box). With the suggested value corresponding to the DEFAULT one in the ENGINES table. But it would not be compatible with MySQL before 5.1.5.
• To please everybody, a combined solution could be possible (on a new page after the database configuration one): Check MySQL version and:
  • If 5.1.5 or higher: Use a drop-down (as in the above note)
  • Otherwise: Use a text input box, with MyISAM as default value

1. It must be because of 3d20b1e since it was introduced in 2.15.0-b3. Is one of those modes maybe restricted to InnoDB or so?

2. I'd say InnoDB is nowadays most used in "modern" applications etc. MyISAM would be more safe that's true. Here's clearly some work to do. We should possibly add this to the system check but the system check is done before one enters the database connection details. So we should check for it during installation when entering DB data and fall back to MyISAM if InnoDB is not present.

@tsteur

So we should check for it during installation when entering DB data and fall back to MyISAM if InnoDB is not present.

True, that would be better than juggling with menus and unneeded choices.

1. It must be because of 3d20b1e since it was introduced in 2.15.0-b3. Is one of those modes maybe restricted to InnoDB or so?

yes, NO_ENGINE_SUBSTITUTION -> http://dev.mysql.com/doc/refman/5.6/en/sql-mode.html#sqlmode_no_engine_substitution

Control automatic substitution of the default storage engine when a statement such as CREATE TABLE or ALTER TABLE specifies a storage engine that is disabled or not compiled in.
Because storage engines can be pluggable at runtime, unavailable engines are treated the same way:
With NO_ENGINE_SUBSTITUTION disabled, for CREATE TABLE the default engine is used and a warning occurs if the desired engine is unavailable. For ALTER TABLE, a warning occurs and the table is not altered.
With NO_ENGINE_SUBSTITUTION enabled, an error occurs and the table is not created or altered if the desired engine is unavailable.

@Joey3000 can you try if removing NO_ENGINE_SUBSTITUTION from core/Db.php fixes the issue? it's a nice find.

@Joey3000 can you try if removing NO_ENGINE_SUBSTITUTION from core/Db.php fixes the issue? it's a nice find.

Yes, that fixes the issue. Nice find indeed, and nice team work. :)

@mattab should we maybe remove NO_ENGINE_SUBSTITUTION from SQL mode as others might have this problem as well? I'm not sure if there's a huge benefit by having it set

For sure we should remove it. Don't know why I closed it without removing the code!