TencentDB for MySQL v5.6以降は、オンラインDDLをサポートしています。5.5バージョンではテーブル構造の変更を行う時に、ロックテーブルによるビジネスへの影響を回避するため、ユーザーがpt-online-schema-changeなどのオープンソースツールを使用してこの操作を完了することをお勧めしていますが、多くのユーザーがCVMによりpt-online-schema-changeを使用してMySQLテーブル構造を変更すると、問題が発生する場合があります。
一般的なエラーメッセージ:Use of uninitialized value $host in string eq at /usr/local/percona-toolkit-3.0.3/bin/pt-online-schema-change line 4284.
対応するソースコードの表示:
sub _find_slaves_by_processlist {
my ( $self, $dsn_parser, $dbh, $dsn ) = @_;
my @slaves = map {
my $slave = $dsn_parser->parse("h=$_", $dsn);
$slave->{source} = 'processlist';
$slave;
}
grep { $_ }
map {
my ( $host ) = $_->{host} =~ m/^([^:]+):/;
if ( $host eq 'localhost' ) {
$host = '127.0.0.1'; # Replication never uses sockets.
}
$host;
} $self->get_connected_slaves($dbh);
return @slaves;
}
コードが示すように、processlistの方法によりslaveの情報を探していますが、TencentDBがコピーアカウント関連の情報を処理したため、processlistによりslaveの情報を取得できません。
ソリューション:
pt-oscを使用する時に以下のパラメーターを追加し、slaveの状態を確認しないようにします。
--recursion-method=none
エラーが表示される原因:
クライアントがCVMコマンドラインによりTencentDB for MySQLインスタンスにXXXX.sqlファイルをインポートする時、「Specified key was too long」というエラーメッセージを返します。
エラーメッセージ「ERROR 1071 (42000): Specified key was too long; max key length is 767 bytes」の意味は、「インデックスフィールドが長すぎで、767バイトを超えています」です。
768/2=384の2バイトまたは767/3=255の3バイトのフィールド(GBKは2バイトで、UTF8は3バイトで、UTF8MB4は4バイト)
MySQL 5.6以上のバージョンは、すべてのmyisamテーブルが自動的にinnodbテーブルに変換されるため、自己構築データベース上には767バイトを超える連結インデックス列がありますが、自己構築データベース上にmyisamストレージエンジンがあるため、同じテーブル作成ステートメントを自己構築データベースで実行しても問題ありませんが、MySQL 5.6以上では問題が発生します。
ソリューション:
create table test(test varcahr(255) primary key)charset=utf8;
-- 成功create table test(test varcahr(256) primary key)charset=utf8;
-- 失敗ERROR 1071(42000):Specified key was too long; max key length is 767 bytes
2. TencentDB 5.5バージョンを使用すると、myisamエンジンはinnodbに自動変換されません。
プラットフォームの安全性の理由により、file権限をアクティブにすることができず、select into outfile方式でデータをエクスポートすることができません。その他の方法でデータをエクスポートすることをお勧めします。
MySQLインスタンス内部、クライアント、MySQLインスタンスへの接続の3つの面について、統一して使用していないか、またはutf8mb4文字セットをサポートしているかを調査する必要があります。
絵文字のMySQLインスタンスへの保存を実現するには、MySQLインスタンス内部、クライアント、MySQLインスタンスへの接続の3つの面について、統一して使用するかutf8mb4文字セットをサポートする必要があります。
character_set_server
パラメーターを変更することができます。このパラメーターを変更すると、データベースが再起動されます。不要な損失が発生することを回避するため、事前にデータベースをバックアップすることをお勧めします。
String query = “set names utf8mb4”;
stat.execute(query);
MySQLは既に公式のデフォルト値に基づき最適化を行っていますが、お客様のビジネスシナリオごとに、インスタンスを購入後、自身のビジネスシーンに基づき以下のパラメーターを適切に配置することをお勧めします。
NO_ENGINE_SUBSTITUTION(5.6バージョン),ONLY_FULL_GROUP_BY、STRICT_TRANS_TABLES、NO_ZERO_IN_DATE、NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO、NO_AUTO_CREATE_USER、NO_ENGINE_SUBSTITUTION(5.7バージョン)
NO_ENGINE_SUBSTITUTION
で、使用するストレージエンジンが無効または未コンパイルの場合、エラーがスローされることを表します。5.7バージョンのデフォルトパラメーター値はONLY_FULL_GROUP_BY、STRICT_TRANS_TABLES、NO_ZERO_IN_DATE、NO_ZERO_DATE、ERROR_FOR_DIVISION_BY_ZERO、NO_AUTO_CREATE_USER、NO_ENGINE_SUBSTITUTION
です。ONLY_FULL_GROUP_BY
はGROUP BYの集計操作時に、SELECT中の列、HAVINGまたはORDER BY節の列の場合、GROUP BY中に現れるまたはGROUP BY列に依存する関数列である必要があります。STRICT_TRANS_TABLES
は厳格モードを有効にすることです。NO_ZERO_IN_DATE モードは、年の部分は非ゼロであるが月または日の部分が0である日付をサーバーが許可するかどうかに影響します。NO_ZERO_DATE
データベースは0の日付を挿入することができず、かつ厳格モードを有効にしたかの影響を受けます。ERROR_FOR_DIVISION_BY_ZERO
は厳格モードにおいて、INSERTまたはUPDATEの過程で、データが0により除算された場合、警告でなくエラーが発生します。非厳格モードではデータが0により除算された場合、MySQLがNULLを戻します。NO_AUTO_CREATE_USER
はGRANTが空のパスワードのユーザーを作成することを禁止します。NO_ENGINE_SUBSTITUTION
は使用するストレージエンジンが無効または未コンパイルの場合、エラーがスローされます。
この記事はお役に立ちましたか?