[Rt-commit] rt branch, 4.4/mariadb-support, created. rt-4.4.1-308-gd584741

Brian Duggan brian at bestpractical.com
Wed Feb 15 09:50:26 EST 2017


The branch, 4.4/mariadb-support has been created
        at  d5847418bb1562bf77a545ccd5f380aa3e8f5353 (commit)

- Log -----------------------------------------------------------------
commit d5847418bb1562bf77a545ccd5f380aa3e8f5353
Author: Brian C. Duggan <brian at bestpractical.com>
Date:   Mon Feb 13 16:07:19 2017 -0500

    Add MariaDB support to documentation and rt-setup-fulltext-index
    
    Modify all documentation that mentions MySQL to note that MariaDB is
    also supported. Where a specific version of MySQL is mentioned, note
    whether MariaDB also supports the mentioned feature. Update mentions
    of MySQL and links to its documentation, where appropriate. Add
    matching links for MariaDB.
    
    Leave upgrade documentation unchanged where text on MySQL is
    historically locked, like specifying that the user is upgrading from
    an RT and MySQL version. Update upgrade documentation where text
    specifies upgrading to a version of MySQL to also mention MariaDB
    
    Update user prompt text and options in sbin/rt-setup-fulltext-index to
    reflect current supported options. Remove an outdated comment from
    that file.
    
    Fixes: I#26828

diff --git a/docs/UPGRADING.mysql b/docs/UPGRADING.mysql
index b0e6cc3..68023e5 100644
--- a/docs/UPGRADING.mysql
+++ b/docs/UPGRADING.mysql
@@ -15,45 +15,47 @@ of MySQL
 
 =item 2.
 
-You are migrating from MySQL 4.0 to MySQL 4.1 or above
+You are migrating from MySQL 4.0 to MySQL 4.1 or above or to MariaDB
 
 =back
 
 If neither of the above cases apply, your should upgrade as per the
 instructions in the README.
 
-These changes are necessary because MySQL 4.1 and greater changed some aspects
-of character set handling that may result in RT failures; this will manifest
-as multiple login requests, corrupted binary attachments, and corrupted image
-custom fields, among others.  In order to resolve this issue, the upgrade
-process will need to modify the schema.
+These changes are necessary because MySQL 4.1 and greater changed some
+aspects of character set handling that may result in RT
+failures. MariaDB also contains these changes. This will manifest as
+multiple login requests, corrupted binary attachments, and corrupted
+image custom fields, among others.  In order to resolve this issue,
+the upgrade process will need to modify the schema.
 
 =over
 
 =item 1.
 
-If you are moving the database and/or upgrading MySQL
+If you are moving the database and/or upgrading to MariaDB or a newer
+version of MySQL
 
 =over
 
 =item 1a.
 
-Dump the database; with MySQL 4.1 and greater be sure to pass the mysqldump
-command the --default-character-set=binary option.  This is necessary because
-the data was originally encoded in Latin1.
+Dump the database. With MySQL 4.1 and greater and MariaDB, be sure to
+pass the mysqldump command the --default-character-set=binary option.
+This is necessary because the data was originally encoded in Latin1.
 
 =item 1b.
 
-Configure the new MySQL to use Latin1 as the default character set everywhere,
-not UTF-8.  This is necessary so the import in the next step assumes the data
-is Latin1.
+Configure the new MySQL or MariaDB to use Latin1 as the default
+character set everywhere, not UTF-8.  This is necessary so the import
+in the next step assumes the data is Latin1.
 
 =item 1c.
 
-Import the dump made in step 1a into the new MySQL server, using the
---default-character-set=binary option on restore.  This will ensure that the
-data is imported as bytes, which will be interpreted as Latin1 thanks to step
-1b above.
+Import the dump made in step 1a into the new MySQL or MariaDB server
+using the --default-character-set=binary option on restore.  This will
+ensure that the data is imported as bytes, which will be interpreted
+as Latin1 thanks to step 1b above.
 
 =item 1d.
 
@@ -136,9 +138,9 @@ everything that may contain characters other than ASCII
 
 =item 10.
 
-If you were upgrading from MySQL 4.0, you may now, if you wish, reconfigure
-your newer MySQL instance to use UTF-8 as the default character set, as step 7
-above adjusted the character sets on all existing tables to contain UTF-8
-encoded data, rather than Latin1.
+If you were upgrading from MySQL 4.0, you may now, if you wish,
+reconfigure your newer MySQL or MariaDB instance to use UTF-8 as the
+default character set, as step 7 above adjusted the character sets on
+all existing tables to contain UTF-8 encoded data, rather than Latin1.
 
 =back
diff --git a/docs/backups.pod b/docs/backups.pod
index 768e7d5..8d815c6 100644
--- a/docs/backups.pod
+++ b/docs/backups.pod
@@ -5,9 +5,10 @@ absolutely necessary to ensure you can recover quickly from an incident.
 
 Make sure you take backups.  Make sure they I<work>.
 
-There are many issues that can cause broken backups, such as a
-C<max_allowed_packet> too low for MySQL (in either the client or server), or
-encoding issues, or running out of disk space.
+There are many issues that can cause broken backups, such as...
+=item * a C<max_allowed_packet> too low for MySQL or MariaDB in either the client or server
+=item * encoding issues
+=item * running out of disk space
 
 Make sure your backup cronjobs notify someone if they fail instead of failing
 silently until you need them.
@@ -29,22 +30,25 @@ You should put the example commands into a shell script for backup and setup a
 cronjob.  Make sure output from cron goes to someone who reads mail!  (Or into
 RT. :)
 
-=head3 MySQL
+=head3 MySQL and MariaDB
 
     ( mysqldump rt4 --tables sessions --no-data --single-transaction; \
       mysqldump rt4 --ignore-table rt4.sessions --single-transaction ) \
         | gzip > rt-`date +%Y%m%d`.sql.gz
 
-The dump will be much faster if you can connect to the MySQL server over
-localhost.  This will use a local socket instead of the network.
+The dump will be much faster if you can connect to the MySQL or
+MariaDB server over localhost.  This will use a local socket instead
+of the network.
 
-If you find your backups taking far far too long to complete (this point should
-take quite a long time to get to on an RT database), there are some alternate
-solutions.  Percona maintains a highly regarded hot-backup tool for MySQL
-called L<XtraBackup|http://www.percona.com/software/percona-xtrabackup/>.  If
-you have more resources, you can also setup replication to a slave using binary
-logs and backup from there as necessary.  This not only duplicates the data,
-but lets you take backups without putting load on your production server.
+If you find your backups taking far far too long to complete (this
+point should take quite a long time to get to on an RT database),
+there are some alternate solutions.  Percona maintains a highly
+regarded hot-backup tool for MySQL and MariaDB called
+L<XtraBackup|http://www.percona.com/software/percona-xtrabackup/>.  If
+you have more resources, you can also setup replication to a slave
+using binary logs and backup from there as necessary.  This not only
+duplicates the data, but lets you take backups without putting load on
+your production server.
 
 =head4 Restoring from backups
 
@@ -73,14 +77,14 @@ enough rights to handle creating tables.
 
 If something terrible happened this morning and you want to roll back to
 your backups, or if you want to update a dev server using your backups,
-this is straightforward on MySQL.
+this is straightforward on MySQL and MariaDB.
 
     gunzip -c rt-20141014.sql.gz | mysql -uroot -p rt4
 
-MySQL will drop any existing tables before recreating and repopulating
-them.  It will leave the database and the rt_user untouched.  This is
-not suitable for restoring on a fresh database install since there will
-be no rt4 database or rt_user user.
+MySQL and MariaDB will drop any existing tables before recreating and
+repopulating them.  It will leave the database and the rt_user
+untouched.  This is not suitable for restoring on a fresh database
+install since there will be no rt4 database or rt_user user.
 
 =back
 
diff --git a/docs/charts.pod b/docs/charts.pod
index 52db66f..7e2bb0f 100644
--- a/docs/charts.pod
+++ b/docs/charts.pod
@@ -61,9 +61,10 @@ across English, many western european languages, Chinese (Traditional and
 Simplified), and Japanese.  If you prefer to use a different font, you can
 change the L<< "C<%ChartFont>"|RT_Config/ChartFont >> option.
 
-There is also an option to use database timezone conversion for PostgreSQL
-and MySQL to enable timezone conversion for time-based reports. See
-F<docs/customizing/timezones_in_charts.pod> for details.
+There is also an option to use database timezone conversion for
+PostgreSQL, MySQL, and MariaDB to enable timezone conversion for
+time-based reports. See F<docs/customizing/timezones_in_charts.pod>
+for details.
 
 Search for "Chart" entries in L<< C<RT_Config> >> for more information on these
 options.
diff --git a/docs/customizing/timezones_in_charts.pod b/docs/customizing/timezones_in_charts.pod
index 47c3a09..cfcbd53 100644
--- a/docs/customizing/timezones_in_charts.pod
+++ b/docs/customizing/timezones_in_charts.pod
@@ -13,21 +13,25 @@ C<$ChartsTimezonesInDB> configuration option.
 
 =head1 DATABASE SPECIFIC NOTES
 
-=head2 mysql
+=head2 MySQL and MariaDB
 
 The time adjustment cannot simply be converted using a numeric time
 shift, as this shift value depends on the daylight saving time
 properties of the time zone.
 
-mysql since 4.1.3 supports named timezones, but you have to fill special
-tables with up-to-date timezone data. On modern systems, this is usually
-a simple case of:
+MariaDB and MySQL 4.1.3 and later support timezones. The database
+administrator must fill special tables with up-to-date timezone
+data. On modern systems, this is usually a simple case of:
 
     mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root mysql
 
-mysql's doc recommends you restart server after running this; you can
-read more about mysql's timezone support at
-L<http://dev.mysql.com/doc/refman/5.0/en/time-zone-support.html>
+MySQL's documentation recommends restarting the server after running this.
+
+You can read more about MySQL's timezone support at:
+L<https://dev.mysql.com/doc/refman/5.7/en/time-zone-support.html>
+
+You can read more about MariaDB's timezone support at:
+L<https://mariadb.com/kb/en/mariadb/time-zones>
 
 =head2 PostgreSQL
 
@@ -68,14 +72,15 @@ L<http://www.postgresql.org/docs/7.4/static/functions-datetime.html#FUNCTIONS-DA
 and
 L<http://www.postgresql.org/docs/7.4/static/datatype-datetime.html#DATATYPE-TIMEZONES>
 
-=head2 mysql
+=head2 MySQL and MariaDB
 
 Once timezone information is loaded into tables on the server,
 we have all the same set of named timezones in the system
 and DateTime (DateTime project has copy of the TZ data in a module).
 
-CONVERT_TZ(TS, from, to) exists since mysql 4.1.3. Note that it takes a
-timestamp, so it only supports limitted date range (usuall 1970-2038).
+MariaDB and MySQL 4.1.3 and later support CONVERT_TZ(TS, from,
+to). Note that it takes a timestamp, so it only supports limitted date
+range (usually 1970-2038).
 
 =head2 Oracle
 
diff --git a/docs/full_text_indexing.pod b/docs/full_text_indexing.pod
index 189c346..a4bb9df 100644
--- a/docs/full_text_indexing.pod
+++ b/docs/full_text_indexing.pod
@@ -56,17 +56,21 @@ C<cron>:
 
     /opt/rt4/sbin/rt-fulltext-indexer --quiet
 
-=head1 MYSQL
+=head1 MYSQL and MariaDB
 
 On MySQL, full-text search can either be done using native support
 (which may use MyISAM tables on pre-5.6 versions of MySQL), or RT can
 integrate with the external Sphinx full-text search engine.
 
-=head2 Native MySQL
+RT supports native full-text search on MariaDB versions 5.5 and
+greater. It does not support Sphinx integration on MariaDB.
 
-As RT marks attachment data as C<BINARY>, MySQL cannot index this
-content without creating an additional table.  To create the required
-table (which is InnoDB on versions of MySQL which support it), run:
+=head2 Native MySQL and MariaDB
+
+As RT marks attachment data as C<BINARY>, MySQL and MariaDB cannot
+index this content without creating an additional table.  To create
+the required table (which is InnoDB on versions of MySQL and MariaDB
+which support it), run:
 
     /opt/rt4/sbin/rt-setup-fulltext-index
 
@@ -126,6 +130,8 @@ distribution-provided packages for MySQL do not include SphinxSE
 integration, merely the external Sphinx tools; these are not sufficient
 for RT's needs.
 
+RT does not support MariaDB with Sphinx.
+
 =head3 Compiling MySQL and SphinxSE
 
 MySQL 5.1 supports adding pluggable storage engines; after compiling
diff --git a/docs/hacking.pod b/docs/hacking.pod
index 23ce51e..f34a10e 100644
--- a/docs/hacking.pod
+++ b/docs/hacking.pod
@@ -183,7 +183,7 @@ before running tests.  To do this in place without installing:
     make fixdeps
 
 Adjust the relevant database options as necessary if you want to test on
-Postgres, Oracle, or SQLite.  The default is MySQL.
+Postgres, Oracle, or SQLite.  The default is MySQL/MariaDB.
 
 To run the test suite:
 
diff --git a/docs/network-diagram.svg b/docs/network-diagram.svg
index cbd3fe1..f85a015 100644
--- a/docs/network-diagram.svg
+++ b/docs/network-diagram.svg
@@ -4621,7 +4621,7 @@
            style="font-size:14.93165874px"
            y="384.14932"
            x="548.99976"
-           sodipodi:role="line">PostgreSQL, MySQL, Oracle</tspan></text>
+           sodipodi:role="line">PostgreSQL, MySQL, MariaDB, Oracle</tspan></text>
       <text
          sodipodi:linespacing="125%"
          id="text14938-2"
diff --git a/docs/security.pod b/docs/security.pod
index 5bf4291..734ef50 100644
--- a/docs/security.pod
+++ b/docs/security.pod
@@ -62,10 +62,10 @@ CGIs or access the server where RT is running.
 =item *
 
 Be sure to protect your database.  If it does not need to talk to the
-world, then don't allow it to listen for remote connections.  With MySQL
-this can be accomplished via C<skip-networking>.  If you use your
-database for other things and must allow remote connections, be sure to
-use a strong, hard to guess password for RT.
+world, then don't allow it to listen for remote connections.  With
+MySQL and MariaDB, this can be accomplished via C<skip-networking>.
+If you use your database for other things and must allow remote
+connections, be sure to use a strong, hard to guess password for RT.
 
 
 =item *
diff --git a/sbin/rt-setup-fulltext-index.in b/sbin/rt-setup-fulltext-index.in
index 616cf40..dc022e7 100644
--- a/sbin/rt-setup-fulltext-index.in
+++ b/sbin/rt-setup-fulltext-index.in
@@ -136,28 +136,39 @@ $dbh->{'PrintError'} = 1;
 if ($DB{'type'} eq "mysql") {
     my $index_type = lc($OPT{'index-type'} || '');
 
-    # Default to sphinx on < 5.6, and error if they provided mysql
+    my $default;
     my $msg;
     if ($RT::Handle->dbh->{mysql_serverversion} < 50600) {
-        $msg = "Complete support for full-text search requires MySQL 5.6 or higher.  For prior\n"
-              ."versions such as yours, full-text indexing can either be provided using MyISAM\n"
-              ."tables, or the external Sphinx indexer.  Using MyISAM tables requires that your\n"
-              ."database be tuned to support them, as RT uses InnoDB tables for all other content.\n"
-              ."Using Sphinx will require recompiling MySQL.  Which indexing solution would you\n"
-              ."prefer?"
+        $default = "myisam";
+        $msg = "Complete support for full-text search requires MySQL 5.6 or higher, or MariaDB\n"
+              ."10.0 or higher. Prior versions, such as yours, can use MyISAM tables for full-text\n"
+              ."indexing. Using MyISAM tables requires tuning your database to support them, since\n"
+              ."RT uses InnoDB tables for all other content.\n"
+              ."\n"
+              ."RT also supports using the external Sphinx indexer with MySQL. You may need to\n"
+              ."recompile MySQL to use Sphinx.\n"
+              ."\n"
+              ."Select '$default' if you are using MariaDB.\n"
+              ."\n"
+              ."Which indexing solution would you prefer? {$default|sphinx}";
     } else {
-        $msg = "MySQL 5.6 and above support native full-text indexing; for compatibility\n"
-              ."with earlier versions of RT, the external Sphinx indexer is still supported.\n"
-              ."Which indexing solution would you prefer?"
+        $default = "native";
+        $msg = "MySQL 5.6 and above, and MariaDB 10.0 and above, support native full-text indexing.\n"
+              ."For compatibility with earlier versions of RT, the external Sphinx indexer is\n"
+              ."still supported only on MySQL. Select $default indexing if you are using MariaDB.\n"
+              ."\n"
+              ."Which indexing solution would you prefer? {$default|sphinx}";
     }
 
-    while ( $index_type ne 'sphinx' and $index_type ne 'mysql' ) {
+    while ( $index_type ne 'sphinx' and $index_type ne $default ) {
         $index_type = lc prompt(
             message => $msg,
-            default => 'mysql',
+            default => $default,
             silent  => !$OPT{'ask'},
         );
     };
+
+    $index_type = 'mysql' if $index_type eq $default;
     $DB{'type'} = $index_type;
 }
 
@@ -165,7 +176,7 @@ if ( $DB{'type'} eq 'mysql' ) {
     # MySQL 5.6 has FTS on InnoDB "text" columns -- which the
     # Attachments table doesn't have, but we can make it have.
     my $table = $OPT{'table'} || prompt(
-        message => "Enter the name of a new MySQL table that will be used to store the\n"
+        message => "Enter the name of a new MySQL or MariaDB table that will be used to store the\n"
                  . "full-text content and indexes:",
         default => $DEFAULT{'table'},
         silent  => !$OPT{'ask'},
@@ -187,7 +198,7 @@ if ( $DB{'type'} eq 'mysql' ) {
 } elsif ($DB{'type'} eq 'sphinx') {
     check_sphinx();
     my $table = $OPT{'table'} || prompt(
-        message => "Enter name of a new MySQL table that will be used to connect to the\n"
+        message => "Enter name of a new MySQL or MariaDB table that will be used to connect to the\n"
                  . "Sphinx server:",
         default => $DEFAULT{'table'},
         silent  => !$OPT{'ask'},

-----------------------------------------------------------------------


More information about the rt-commit mailing list