[Rt-commit] rt branch, 4.4/mariadb-support, repushed
Brian Duggan
brian at bestpractical.com
Mon Mar 5 16:21:40 EST 2018
The branch 4.4/mariadb-support was deleted and repushed:
was d288d15af8a4dc22557ed9723b2f4091f210ea38
now d29ba50b1dcfc8c0689c23258c2c0f7566579761
1: d288d15af ! 1: d29ba50b1 Add MariaDB support to documentation and rt-setup-fulltext-index
@@ -19,90 +19,6 @@
Fixes: I#26828
-diff --git a/docs/UPGRADING.mysql b/docs/UPGRADING.mysql
---- a/docs/UPGRADING.mysql
-+++ b/docs/UPGRADING.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 from MySQL
-+4.0 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.
-
-@@
-
- =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
--- a/docs/backups.pod
+++ b/docs/backups.pod
@@ -114,10 +30,15 @@
-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
@@ -342,63 +263,26 @@
--- a/sbin/rt-setup-fulltext-index.in
+++ b/sbin/rt-setup-fulltext-index.in
@@
- 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}";
+ ."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?"
-+ $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"
++ ."still supported only on MySQL. Select 'mysql' indexing if you are using MariaDB.\n"
+ ."\n"
-+ ."Which indexing solution would you prefer? {$default|sphinx}";
++ ."Which indexing solution would you prefer? {mysql|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;
- }
-
+ while ( $index_type ne 'sphinx' and $index_type ne '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"
++ 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