いくつかの重要な注意事項：
- MariaDB構成ファイルは/etc/my.cnfにあります。このファイルを変更するたびに、MySQLサービスを再起動して、新しい変更を有効にする必要があります。
20ブラックフライデーとサイバーマンデーのチューニングに関する推奨事項
1。 InnoDBバッファープールサイズ
InnoDBバッファープールサイズこれは、InnoDBを使用したインストールを確認するための最も重要な設定です。バッファプールは、データとインデックスがキャッシュされる場所です。可能な限り大きくすることで、ほとんどの読み取り操作にディスクではなくメモリを使用できるようになります。
2。 InnoDBログファイルサイズ
innodb_log-file-sizeは、REDOログのサイズであり、書き込みが高速で耐久性があることを確認するために使用されます。 InnoDBのログファイルのサイズ設定には、次の2つの一般的な提案があります。
- InnoDBログファイルの合計サイズをInnoDBバッファプールサイズの25〜50％より大きく設定します
または
- 合計InnoDBログファイルのログサイズを、ピーク負荷時の1時間分のログエントリに等しく設定します
ログファイルが大きいと、サーバーがクラッシュした場合のリカバリが遅くなる可能性があります。ただし、必要なチェックポイントの数も減り、ディスクI/Oも減ります。
運用負荷がかかっている状態で、1時間分のバイナリログのサイズを評価してから、InnoDBログファイルのサイズを増やすかどうかを決定します。
innodbログファイルのサイズを正しく取得することは、優れたシステムパフォーマンスを実現するために重要です。 MariaDBのInnoDBストレージエンジンは、固定サイズ（循環）のREDOログスペースを使用します。サイズは、innodb_log_file_sizeおよびinnodb_log_files_in_group（デフォルトは2）によって制御されます。これらの値を乗算して、使用可能なREDOログスペースを取得します。技術的には、innodb_log_file_size変数とinnodb_log_files_in_group変数のどちらを使用してREDOスペースのサイズを制御するかは重要ではありませんが、ほとんどの人はinnodb_log_file_sizeを使用して、innodb_log_files_in_groupをそのままにします。
InnoDBのREDOスペースサイズは、書き込みが集中するワークロードにとって最も重要な構成オプションの1つです。ただし、トレードオフが伴います。構成されたREDOスペースが多いほど、InnoDBは書き込みI/Oを最適化できます。ただし、REDOスペースを増やすと、他の理由でシステムの電源が切れたりクラッシュしたりした場合の回復時間が長くなります。
3。 InnoDBログバッファーサイズ
InnoDBログバッファーサイズが大きいほど、トランザクションが大きい場合のディスクI/Oが少なくなります。すべてのサーバーでこれを64Mに設定することをお勧めします。
4。 InnoDBログフラッシュ間隔
innodb_flush_log_at_trx_commit変数は、ログバッファのディスクへのフラッシュがいつ発生するかを制御します。 innodb_flush_log_at_trx_commit =1（デフォルト）は、トランザクションがコミットされるたびにログバッファをディスクにフラッシュします。これは最も安全ですが、パフォーマンスが最も低いオプションでもあります。
innodb_flush_log_at_trx_commit =0は、ログバッファを毎秒ディスクにフラッシュしますが、トランザクションのコミットでは何もフラッシュしません。最大1秒（おそらくプロセスのスケジューリングのためにそれ以上）が失われる可能性があります。クラッシュが発生した場合、MySQLまたはサーバーはデータを失う可能性があります。これは最速ですが安全性が最も低いオプションです。
innodb_flush_log_at_trx_commit =2は、コミットごとにログバッファーをファイルに書き込みますが、1秒ごとにディスクにフラッシュします。ディスクキャッシュにバッテリーバックアップがある場合（たとえば、バッテリーでバックアップされたキャッシュRAIDコントローラー）、これは通常、パフォーマンスと安全性の最適なバランスです。 MySQLのクラッシュはデータを失うべきではありません。サーバーのクラッシュや停電により、最大1秒かかる可能性があります（プロセスのスケジュール設定が原因で、さらに長くなる可能性があります）。バッテリーでバックアップされたキャッシュは、この可能性を減らします。
5。 InnoDBIO容量
innodb_io_capacityは、基盤となるストレージが処理できるIOPSのほぼ最大数に設定する必要があります。
デフォルトでは、これは1000に設定されています。ストレージのベンチマークを行って、この値をさらに増やすことができるかどうかを判断することをお勧めします。
6。スレッドキャッシュサイズ
Threads_createdの値を監視します。 1分あたり数スレッドを超えて増加し続ける場合は、thread_cache_sizeの値を増やしてください。
現在のデフォルト構成では、スレッドキャッシュサイズは200に設定されています。
7。テーブルキャッシュとテーブル定義キャッシュ
table_open_cache変数とtable_defintion_cache変数は、すべてのスレッドに対して開いたままにするテーブルと定義の数を制御します。
Open_tables、Open_table_defintitions、Opened_tables、Opened_table_definitionsを監視して、最適な値を決定します。一般的な提案は、table_open_cache（およびその後のtable_definition_cache）を、Opened_tables（およびOpened_table_definitions）ステータス値の増加率を下げるのに十分なだけ高く設定することです。
デフォルト設定では、table_open_cacheとtable_defintion_cacheの両方が2048に設定されています。
8。クエリキャッシュ
クエリキャッシュはよく知られたボトルネックであり、同時実行性が中程度の場合でも見られます。最良のオプションは、query_cache_size =0（MariaDB 10のデフォルト）を設定して初日から無効にし、他の方法を使用して読み取りクエリを高速化することです。適切なインデックス作成、レプリカの追加による読み取り負荷の分散、外部キャッシュの使用（たとえば、memcacheまたはredis）。クエリキャッシュを有効にしてMariaDBアプリケーションを既に構築していて、問題に気付いたことがない場合は、クエリキャッシュが役立つ場合があります。その場合、無効にする場合は注意が必要です。
9。一時テーブル、tmp_table_size、およびmax_heap_table_size
MySQLは、max_heap_table_sizeとtmp_table_sizeの小さい方を使用して、メモリ内の一時テーブルのサイズを制限します。これらはクライアント変数ごとです。この値を大きくすると、ディスク上に作成される一時テーブルの数を減らすことができますが、これはクライアントごとであるため、サーバーのメモリ容量に達するリスクも高まります。通常、32Mから64Mは、両方の変数について最初に推奨される値であり、必要に応じて調整します。
一時テーブルは、GROUP BY、ORDER BY、DISTINCT、UNION、サブクエリなどによく使用されます。理想的には、MySQLはこれらをメモリ内に作成し、ディスク上に可能な限り少なくする必要があります。
結合を適切に使用せず、大きな一時テーブルを作成するクエリは、ディスク上の一時テーブルの数が多い理由の1つである可能性があることに注意してください。もう1つの理由は、メモリストレージエンジンが固定長の列を使用し、最悪のシナリオを想定していることです。列のサイズが正しくない場合（たとえば、短い文字列の場合はVARCHAR（255））、これはメモリ内のテーブルのサイズに影響を与え、本来よりも早くディスクに移動する可能性があります。また、メモリストレージエンジンはそれらをサポートしていないため、blob列とテキスト列を含む一時テーブルはすぐにディスクに移動します。
現在、両方ともデフォルトで64Mに設定されています。
10。警告ログレベル
11。最大接続数
「接続が多すぎます」というエラーが頻繁に発生する場合は、max_connectionsが低すぎます。多くの場合、アプリケーションはデータベースへの接続を正しく閉じないため、デフォルトの151接続よりもはるかに多くの接続が必要になります。 max_connectionsの値が高い場合（たとえば、1,000以上）の主な欠点は、サーバーがその数のアクティブなトランザクションを実行する必要がある場合、サーバーが応答しなくなることです。ここでは、アプリケーションレベルで接続プールを使用するか、MariaDBレベルでスレッドプールを使用すると役立ちます。
12。トランザクションの分離
利用可能なトランザクション分離レベルを調査し、サーバーのユースケースに最適なトランザクション分離を決定します。
13。バイナリログ形式
14。自動インクリメントオフセット
2つのマスター間の衝突が同時に書き込まれる可能性を減らすために、自動インクリメントと自動インクリメントのオフセット値をそれに応じて調整する必要があります。
15。同期Binlog
デフォルトでは、OSはbinlogのディスクへのフラッシュを処理します。サーバーがクラッシュした場合、バイナリログからトランザクションが失われ、レプリケーションが同期しなくなる可能性があります。 sync_binlog =1に設定すると、コミットごとにbinlogファイルがフラッシュされます。
これは低速ですが、最も安全なオプションです。
16。クラッシュセーフ（r）スレーブ
スレーブクラッシュ後のレプリケーションエラーを回避するには、リレーログの回復と、リレーログおよびリレーログ情報ファイルのディスクへの同期を有効にします。
17。スレーブの更新をログに記録する
チェーンレプリケーション（マスター->スレーブ->スレーブ）を使用するには、log_slave_updatesを有効にする必要があります。これにより、スレーブはレプリケートされたトランザクションを独自のバイナリログに書き込み、スレーブログからスレーブにレプリケートできるようになります。
18。読み取り専用スレーブ
スレーブは、データが誤って書き込まれないように、読み取り専用にする必要があります。
注 ：サーバーが読み取り専用の場合でも、スーパー権限を持つユーザーは書き込みを行うことができます。
19。スレーブネットタイムアウト
slave_net_timeout変数は、スレーブが再接続を試みる前にマスターからのパケットを待機する秒数です。デフォルトは3600（1時間）です。つまり、リンクがダウンして検出されない場合、スレーブが再接続するまでに最大1時間かかる可能性があります。これにより、スレーブが突然マスターから最大1時間遅れる可能性があります。
slave_net_timeoutを30や60などのより適切な値に設定することをお勧めします。
20。ブラックフライデーとサイバーマンデーの準備に関するウェビナーをご覧ください
オンデマンドのウェビナー–ブラックフライデーとサイバーマンデーの準備–を見て、データベースの準備の4つの重要な原則を学びましょう。セキュリティ対策 悪意のある攻撃からデータベースを保護するには、パフォーマンスの調整 スムーズなユーザーエクスペリエンスを確実に提供するために、高可用性戦略 1回の販売と拡張性を見逃さないようにするため 予想される成長と予想外の急上昇の両方に備えるため。