[Rt-commit] rt branch, 4.4/mariadb-support, created. rt-4.4.1-332-gd29ba50b1

Brian Duggan brian at bestpractical.com
Mon Mar 5 16:21:38 EST 2018


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

- Log -----------------------------------------------------------------
commit d29ba50b1dcfc8c0689c23258c2c0f7566579761
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/backups.pod b/docs/backups.pod
index 768e7d5e8..0f9507e30 100644
--- a/docs/backups.pod
+++ b/docs/backups.pod
@@ -5,9 +5,17 @@ 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...
+
+=over 4
+
+=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
+
+=back
 
 Make sure your backup cronjobs notify someone if they fail instead of failing
 silently until you need them.
@@ -29,22 +37,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 +84,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 52db66f8c..7e2bb0fb5 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 47c3a096f..39f8de0bf 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 limited date
+range (usually 1970-2038).
 
 =head2 Oracle
 
diff --git a/docs/full_text_indexing.pod b/docs/full_text_indexing.pod
index 189c346cf..5b94399eb 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 10.0 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 23ce51e3a..f34a10e36 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 cbd3fe1d1..f85a015f7 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 5bf42919c..734ef50a0 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 616cf4052..03863fbfa 100644
--- a/sbin/rt-setup-fulltext-index.in
+++ b/sbin/rt-setup-fulltext-index.in
@@ -146,9 +146,11 @@ if ($DB{'type'} eq "mysql") {
               ."Using Sphinx will require recompiling MySQL.  Which indexing solution would you\n"
               ."prefer?"
     } 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?"
+        $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 'mysql' indexing if you are using MariaDB.\n"
+              ."\n"
+              ."Which indexing solution would you prefer? {mysql|sphinx}"
     }
 
     while ( $index_type ne 'sphinx' and $index_type ne 'mysql' ) {
@@ -165,7 +167,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 table that will be used to store the\n"
                  . "full-text content and indexes:",
         default => $DEFAULT{'table'},
         silent  => !$OPT{'ask'},

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


More information about the rt-commit mailing list