service mysql start
mysqlマスタースレーブレプリケーション
mysql ビデオ チュートリアル マスター/スレーブ レプリケーションを紹介するコラム
##関連する無料学習の推奨事項:データベース レプリケーションは、システムの高可用性とハイ パフォーマンスを向上させる上で非常に重要な役割を果たします。この記事では、mysql マスター/スレーブ レプリケーションに関連する関連知識をまとめています。この分野に携わっている方は、ぜひ参考にしていただければと思います。もっと詳しく知ることができます。役に立ちました。 1 メイン ライブラリ構成1.1 my.cnf 構成: メイン ライブラリ構成ファイル my.cnf で次の基本構成を構成します:
log-bin = mysql-bin //二进制日志文件名称主体 log-bin-index = mysql-bin.index //二进制日志文件索引文件 server-id = 1 //唯一的服务器ID,为了保持唯一性,可以去ip的尾部 binlog-format = mixed //控制复制基于的方式,有基于语句(statement),基于行(row),混合(mixed),**主从库需要保持一致** #sync_binlog=1 //推荐配置,开启该选项,mysql每次在事务提交前会将二进制日志同步到磁盘上,保证在服务器崩溃时不会丢失事件。
比如说要指定db1和db2两个数据库进行主从复制: binlog-do-db = db1 binlog-do-db = db2
mysql> grant replication slave, replicatin client on \*.\* to repl@'172.16.226.192' identified by 'repl123456'; //其中repl是用户名,repl123456为账户密码,172.16.226.168为备库的地址。 mysql> flush privileges; //在不重启mysql服务的情况下完成权限的更新
relay-log = slave-relay-bin //中继日志文件名称主体 relay-log-index = slave-relay-bin.index //中继日志文件索引文件 server-id = 2 //唯一的服务器ID,必须要异于主库 #read_only = 1 //限制备库为只读,可选 log_slave_updates = 1 //控制是否在中继日志执行之后,将同步过来的数据添加到自己的binlog中去,1代表是 skip_slave_start // 该选项能够阻止备库在崩溃后自动启动复制,建议开启 即使开启了建议的选项,备库仍然可能在崩溃后被中断,因为master.info和中级日志文件都不是崩溃安全的,所以建议开启一下选项: sync_master_info = 1 sync_relay_log = 1 sync_relay_log_info = 1
mysql> grant reload, lock tables, replication client on \*.\* to backup@'%' identified by 'backup123'; mysql> flush privileges; //在不重启mysql服务的情况下完成权限的更新
innobackupex-1.5.1 --defaults-file=/etc/mysql/my.cnf --user=backup --password=backup123 /mysqlbackup --defaults-file:选择默认的配置文件 --user和--password:分别为进行备份的用户名和密码 /mysqlbackup:目标目录
innobakupex コマンドの --apply-log オプションを使用して、上記の機能を実装できます。たとえば、次のコマンド:
innobackupex-1.5.1 --apply-log --user=backup --password=backup123 /mysqlbackup/2017-01-11_21-20-57 如果执行正确,其最后输出的几行信息通常如下: xtrabackup: starting shutdown with innodb_fast_shutdown = 1 120407 9:01:36 InnoDB: Starting shutdown... 120407 9:01:40 InnoDB: Shutdown completed; log sequence number 92036620 120407 09:01:40 innobackupex: completed OK!
scp -r /mysqlbackup/ copyer@192.168.1.192:/data/
データ回復の前に、まずスレーブ サーバーの mysql サービスを閉じ、次の xtrabackup_binlog_info ファイルからデータを取得します。バックアップ フォルダー 現在使用されているバイナリ ログ ファイル、およびこの時点までのバイナリ ログ イベントがバックアップされる場所。 datadir ディレクトリが空でない場合は、datadir ディレクトリもクリアする必要があります。 innobackupex コマンドの --copy-back オプションは、リカバリ操作を実行するために使用され、すべてのデータ関連ファイルを mysql サーバーの datadir ディレクトリにコピーすることによってリカバリ プロセスを実行します。 innobackupex は、backup-my.cnf を通じて datadir ディレクトリに関する関連情報を取得します (--defaults-file を通じて my.cnf ディレクトリを指定し、datadir パスが空であることを確認することもできます)
innobackupex-1.5.1 --copy-back /mysqlbackup 如果执行正确,其输出信息的最后几行通常如下: innobackupex: Starting to copy InnoDB log files innobackupex: in '/backup/2012-04-07_08-17-03' innobackupex: back to original InnoDB log directory '/mydata/data' innobackupex: Finished copying back files. 120407 09:36:10 innobackupex: completed OK!
chown -R mysql:mysql /var/lib/mysql/
service mysql start
ログイン後にコピー
mysql を開くのに失敗した場合は、エラーを確認することで失敗の理由を見つけることができます。ログ。 4.2 マスター/スレーブ接続を確立するスレーブ ライブラリは、レプリケーション アカウントを介してマスター ライブラリに接続します: (次の接続を有効にするには、スレーブが停止状態である必要があります)service mysql start
mysql> change master to master_host='192.168.1.208',master_user='repl', master_password='repl123456',master_log_file='mysql-bin.000001'(备份时得到的活动日志),master_log_pos=0(备份时得到的活动日志中事件的位置);
注 : マスター/スレーブ接続中にマスターをここに接続できない場合、考えられる理由の 1 つは、ローカル マシンが my.cnf 構成ファイル (つまり、bind-address) でバインドされていることです。 = 127.0.0.1. やるべきこと コメントアウトするだけで、そうしないと外部マシンがアクセスできなくなります。
オープン スレーブ:mysql> start slave;
mysql> show slave status; Slave_IO_Running: Yes //表示IO线程运行正常 Slave_SQL_Running: Yes //表示SQL线程运行正常 Seconds_Behind_Master: 0 //表示在网络条件较好的情况下,从库能够及时同步上主库
mysql> show processlist\G; //查看数据库服务线程情况
mysql> show master/slave status\G; //查看主备库状态
mysql> flush logs; //强制轮换(rotate)二进制日志,从而得到一个完整的二进制日志文件
mysql> show binlog events in '指定二进制日志文件名称' from (从指定位置开始显示) limit (需要显示的事件数量)\G; //查看binlog中事件
mysql> show binary logs; //显示所有的binlogs
mysql> reset master; //删除所有二进制日志文件并清空索引文件
mysql> reset slave; //删除slave上复制用的所有文件重新开始
mysql> show slave hosts; //查看主库所拥有的从库信息
ログイン後にコピー
mysql> show processlist\G; //查看数据库服务线程情况 mysql> show master/slave status\G; //查看主备库状态 mysql> flush logs; //强制轮换(rotate)二进制日志,从而得到一个完整的二进制日志文件 mysql> show binlog events in '指定二进制日志文件名称' from (从指定位置开始显示) limit (需要显示的事件数量)\G; //查看binlog中事件 mysql> show binary logs; //显示所有的binlogs mysql> reset master; //删除所有二进制日志文件并清空索引文件 mysql> reset slave; //删除slave上复制用的所有文件重新开始 mysql> show slave hosts; //查看主库所拥有的从库信息
0:每隔一秒,把事务日志缓存区的数据写到日志文件中,以及把日志文件的数据刷新到磁盘上; 1:每个事务提交时候,把事务日志从缓存区写到日志文件中,并且刷新日志文件的数据到磁盘上; 2:每事务提交的时候,把事务日志数据从缓存区写到日志文件中;每隔一秒,刷新一次日志文件,但不一定刷新到磁盘上,而是取决于操作系统的调度;
取1时的IO耗费最大,虽然一致性和完整性方面效果最好,但是写入效率最低,而这也是导致从库延迟较大的原因(如果服务器配置较高或许会好些)。取0时mysql写入性能很好,但如果 mysqld 进程崩溃,通常会导致最后 1s 的日志丢失 。取2时的写入性能也很好,每次事务提交会写入日志文件,但并不会立即刷写到磁盘,日志文件会每秒刷写一次到磁盘。这时如果 mysqld 进程崩溃,由于日志已经写入到系统缓存,所以并不会丢失数据;在操作系统崩溃的情况下,通常会导致最后 1s 的日志丢失。
6 混合模式复制
正常情况下使用使用基于语句的复制,而对不安全的语句则切换到基于行的复制。主要有以下几种情况:
- 该语句调用了:
- UUID函数
- 用户自定义函数
- CURRENT_USER或USER函数
- LOAD_FILE函数
- 一个语句同时更新了两个或者两个以上含有AUTO_INCREMENT列的表
- 语句使用了服务器变量
- 存储引擎不允许使用基于语句的复制,例如,mysql cluster引擎
7 复制过滤
有时候我们不需要对数据库中所有的库进行复制,或者不想对指定库中的某些表进行复制操作,那么我们就需要对复制进行一定的过滤配置,以达到更合理的复制效果。
1. 基于master
**binlog-do-db=mysql**:主库只是将指定库(mysql)发生的变化记录到二进制日志中。 **binlog-ignore-db=mysql**:主库取消将指定库(mysql)发生的变化记录到二进制日志中。
2. 基于slave
针对数据库进行的过滤:
**replicate-do-db=mysql**:从库只是将指定库(mysql)发生的变化进行重现。 **replicate-ignore-db=mysql**:从库取消将指定库(mysql)发生的变化进行重现。 针对表进行的过滤: **replicate-wild_do-table=mysql.learn**:从库只是将指定库(mysql)中指定表(learn)发生的变化进行重现。 **replicate-wild_ignore-table=mysql.learn**:从库取消将指定库(mysql)中指定表(learn)发生的变化进行重现。
以上复制过滤方式乍一看没有问题,其实还是有需要注意的地方。因为这些过滤方式的效果与复制方式有关系。如果是基于语句的复制,binlog-do-db、binlog-ignore-db、replicate-do-db、replicate-ignore-db与跨库(如use库内和use外)有关系,这一点需要注意。
8 日志清理
暴力清理:(没有主从复制的情况下)
1、重启mysql服务器即可关闭bin日志的记录 2、通过reset master命令进行清理
条件清理
如果存在主从复制关系,则应当使用purge的方式来清理bin日志,语法如下:
purge {master|binary} logs to 'log_name' purge {master|binary} logs before 'date'
用户删除列于在指定的日志或日期之前的日志索引中的所有二进制日志,同时这些日志也会从日志索引文件的清单中删除。
eg. purge master logs to 'mysql-bin.000005'; purge master logs before '2014-08-30 00:00:00';//清除指定日期之前的日志 purge master logs before date_sub(now(),Interval 3 day);清除三天前的日志
定时清理
参数:expire_logs_days
说明:二进制日志自动删除/过期的天数。默认值为'0',即没有过期的
示例:expire_logs_days = 5,代表日志的有效时间为5天
什么时候会删除过期日志?
每次进行log flush的时候会自动删除过期的日志
什么时候会触发log flush?
1、重启 2、binlog文件的大小达到了最大限制 3、手动执行flush logs命令
写在最后
本文只是结合自己的学习以及实践过程进行了相关总结,如有不妥之处望您批评指正。推荐大家学习《高可用MYSQL》、《高性能MYSQL》两本书,最重要的还是实践实践再实践,欢迎交流,共同进步。
想了解更多编程学习,敬请关注php培训栏目!
以上がmysqlマスタースレーブレプリケーションの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。

ホットAIツール

Undresser.AI Undress
リアルなヌード写真を作成する AI 搭載アプリ

AI Clothes Remover
写真から衣服を削除するオンライン AI ツール。

Undress AI Tool
脱衣画像を無料で

Clothoff.io
AI衣類リムーバー

AI Hentai Generator
AIヘンタイを無料で生成します。

人気の記事

ホットツール

メモ帳++7.3.1
使いやすく無料のコードエディター

SublimeText3 中国語版
中国語版、とても使いやすい

ゼンドスタジオ 13.0.1
強力な PHP 統合開発環境

ドリームウィーバー CS6
ビジュアル Web 開発ツール

SublimeText3 Mac版
神レベルのコード編集ソフト(SublimeText3)

ホットトピック









MySQLがテーブル構造を変更すると、メタデータロックが通常使用され、テーブルがロックされる可能性があります。ロックの影響を減らすために、次の測定値をとることができます。1。オンラインDDLでテーブルを使用できます。 2。バッチで複雑な変更を実行します。 3.小規模またはオフピーク期間中に操作します。 4. PT-OSCツールを使用して、より細かい制御を実現します。

MySQLデータベースでは、ユーザーとデータベースの関係は、アクセス許可と表によって定義されます。ユーザーには、データベースにアクセスするためのユーザー名とパスワードがあります。許可は助成金コマンドを通じて付与され、テーブルはCreate Tableコマンドによって作成されます。ユーザーとデータベースの関係を確立するには、データベースを作成し、ユーザーを作成してから許可を付与する必要があります。

MySQLには、無料のコミュニティバージョンと有料エンタープライズバージョンがあります。コミュニティバージョンは無料で使用および変更できますが、サポートは制限されており、安定性要件が低く、技術的な能力が強いアプリケーションに適しています。 Enterprise Editionは、安定した信頼性の高い高性能データベースを必要とするアプリケーションに対する包括的な商業サポートを提供し、サポートの支払いを喜んでいます。バージョンを選択する際に考慮される要因には、アプリケーションの重要性、予算編成、技術スキルが含まれます。完璧なオプションはなく、最も適切なオプションのみであり、特定の状況に応じて慎重に選択する必要があります。

MySQLデータベースパフォーマンス最適化ガイドリソース集約型アプリケーションでは、MySQLデータベースが重要な役割を果たし、大規模なトランザクションの管理を担当しています。ただし、アプリケーションのスケールが拡大すると、データベースパフォーマンスのボトルネックが制約になることがよくあります。この記事では、一連の効果的なMySQLパフォーマンス最適化戦略を検討して、アプリケーションが高負荷の下で効率的で応答性の高いままであることを保証します。実際のケースを組み合わせて、インデックス作成、クエリ最適化、データベース設計、キャッシュなどの詳細な主要なテクノロジーを説明します。 1.データベースアーキテクチャの設計と最適化されたデータベースアーキテクチャは、MySQLパフォーマンスの最適化の基礎です。いくつかのコア原則は次のとおりです。適切なデータ型を選択し、ニーズを満たす最小のデータ型を選択すると、ストレージスペースを節約するだけでなく、データ処理速度を向上させることもできます。

データ統合の簡素化:AmazonrdsmysqlとRedshiftのゼロETL統合効率的なデータ統合は、データ駆動型組織の中心にあります。従来のETL(抽出、変換、負荷)プロセスは、特にデータベース(AmazonrdsmysQlなど)をデータウェアハウス(Redshiftなど)と統合する場合、複雑で時間がかかります。ただし、AWSは、この状況を完全に変えたゼロETL統合ソリューションを提供し、RDSMYSQLからRedshiftへのデータ移行のための簡略化されたほぼリアルタイムソリューションを提供します。この記事では、RDSMysQl Zero ETLのRedshiftとの統合に飛び込み、それがどのように機能するか、それがデータエンジニアと開発者にもたらす利点を説明します。

1.正しいインデックスを使用して、データの量を削減してデータ検索をスピードアップしました。テーブルの列を複数回検索する場合は、その列のインデックスを作成します。あなたまたはあなたのアプリが基準に従って複数の列からのデータが必要な場合、複合インデックス2を作成します2。選択した列のみを避けます。必要な列のすべてを選択すると、より多くのサーバーメモリを使用する場合にのみサーバーが遅くなり、たとえばテーブルにはcreated_atやupdated_atやupdated_atなどの列が含まれます。

MySQLのユーザー名とパスワードを入力するには:1。ユーザー名とパスワードを決定します。 2。データベースに接続します。 3.ユーザー名とパスワードを使用して、クエリとコマンドを実行します。

MySQLは、インストールが簡単で、強力で管理しやすいため、初心者に適しています。 1.さまざまなオペレーティングシステムに適した、単純なインストールと構成。 2。データベースとテーブルの作成、挿入、クエリ、更新、削除などの基本操作をサポートします。 3.参加オペレーションやサブクエリなどの高度な機能を提供します。 4.インデックス、クエリの最適化、テーブルパーティション化により、パフォーマンスを改善できます。 5。データのセキュリティと一貫性を確保するために、バックアップ、リカバリ、セキュリティ対策をサポートします。
