이 기사에서는 MySql 마스터-슬레이브 복제가 무엇인지 소개합니다. 구현을 구성하는 방법은 무엇입니까? 도움이 필요한 친구들이 참고할 수 있기를 바랍니다.
MySQL 마스터-슬레이브 복제는 가장 중요한 기능 중 하나입니다. 마스터-슬레이브 복제는 하나의 서버가 마스터 데이터베이스 서버 역할을 하고 다른 서버 또는 여러 서버가 슬레이브 데이터베이스 서버 역할을 하는 것을 의미합니다. 마스터 서버의 데이터가 슬레이브 서버에 자동으로 복사됩니다. 다중 레벨 복제의 경우 데이터베이스 서버는 마스터 또는 슬레이브 역할을 할 수 있습니다. MySQL 마스터-슬레이브 복제의 기본은 마스터 서버가 데이터베이스 수정 사항에 대한 바이너리 로그를 기록하고, 슬레이브 서버가 마스터 서버의 바이너리 로그를 통해 자동으로 업데이트를 수행한다는 것입니다.
마스터 서버에서 실행된 명령문이 실행됩니다. 슬레이브 서버에서 한 번 실행해 보세요. MySQL-3.23 이상 버전에서 지원됩니다.
기존 문제: 시간이 완전히 동기화되지 않아 편차가 발생할 수 있으며, 명령문을 실행하는 사용자도 다른 사용자일 수 있습니다.
어떤 문으로 인해 내용이 변경되었는지 신경쓰지 않고 수정된 내용을 메인 서버에 직접 복사합니다.
기존 문제: 예를 들어 급여 테이블에 10,000명의 사용자가 있다고 가정합니다. 각 사용자의 급여에 1,000을 더하면 행 기반 복제는 10,000행의 내용을 복사하므로 오버헤드가 상대적으로 커집니다. 반면 명령문 기반 복제에는 하나의 명령문만 필요합니다.
MySQL은 기본적으로 명령문 기반 복제를 사용합니다. 자동으로 선택됩니다.
MySQL 마스터-슬레이브 복제 아키텍처에서 읽기 작업은 모든 서버에서 수행할 수 있지만 쓰기 작업은 마스터 서버에서만 수행할 수 있습니다. 마스터-슬레이브 복제 아키텍처는 읽기 작업에 대한 확장을 제공하지만 쓰기 작업이 더 많은 경우(여러 슬레이브 서버가 마스터 서버의 데이터를 동기화해야 함) 단일 마스터 복제에서 마스터 서버는 필연적으로 성능 병목 현상이 발생합니다. 모델.
1, 명령문 기반 복제 : 마스터 서버 위에서 실행한 문장은 슬레이브 서버에서 다시 실행되는데, 이는 MySQL-3.23 이상 버전에서 지원된다.
기존 문제: 시간이 완전히 동기화되지 않아 편차가 발생할 수 있으며, 명령문을 실행하는 사용자도 다른 사용자일 수 있습니다.
2, 행 기반 복제 : 내용 변경에 신경쓰지 않고 수정된 내용을 메인 서버에 직접 복사하는 구문입니다. MySQL-5.0 버전 이후에 도입되었습니다.
기존 문제: 예를 들어 급여 테이블에 10,000명의 사용자가 있고 각 사용자의 급여에 1,000을 더하면 행 기반 복제가 10,000행의 내용을 복사하므로 오버헤드는 다음과 같습니다. 상대적으로 큰 반면 명령문 기반 복제에는 하나의 명령문만 필요합니다.
3, 혼합 유형 복제 : MySQL은 기본적으로 명령문 기반 복제가 문제인 경우 행 기반 복제를 사용합니다. 복제가 사용되며 MySQL은 자동으로 이를 선택합니다.
MySQL 마스터-슬레이브 복제 아키텍처에서 읽기 작업은 모든 서버에서 수행할 수 있지만 쓰기 작업은 마스터 서버에서만 수행할 수 있습니다. 마스터-슬레이브 복제 아키텍처는 읽기 작업에 대한 확장을 제공하지만 쓰기 작업이 더 많은 경우(여러 슬레이브 서버가 마스터 서버의 데이터를 동기화해야 함) 단일 마스터 복제에서 마스터 서버는 필연적으로 성능 병목 현상이 발생합니다. 모델.
3개의 MySQL 마스터-슬레이브 복제의 작동 원리
아래와 같이:
마스터 서버 위의 모든 수정 사항은 바이너리 로그에 저장됩니다. 서버(실제로는 메인 서버의 클라이언트 프로세스)에서 I/O 스레드를 시작하고 메인 서버에 연결하여 바이너리 로그 읽기를 요청한 다음 해당 내용을 읽습니다. 획득한 바이너리 로그는 로컬 Realy 로그에 기록됩니다. 서버에서 SQL 스레드를 시작하여 Realy 로그를 정기적으로 확인하세요. 변경 사항이 발견되면 즉시 로컬 머신에서 변경된 내용을 실행하세요.
마스터가 하나이고 슬레이브가 여러 개 있는 경우 마스터 라이브러리는 여러 슬레이브 라이브러리에 대한 바이너리 로그 작성 및 제공을 모두 담당합니다. 이때 약간의 조정을 하여 특정 슬레이브에게만 바이너리 로그를 제공할 수 있습니다. 그러면 이 슬레이브는 바이너리 로그를 활성화하고 자신의 바이너리 로그를 다른 슬레이브에게 보냅니다. 또는 단순히 이것은 기록하지 않고 바이너리 로그를 다른 슬레이브로 전달하는 역할만 담당합니다. 이러한 방식으로 아키텍처의 성능이 훨씬 향상될 수 있으며 데이터 간의 지연도 약간 더 좋아질 것입니다. 작동 원리 다이어그램은 다음과 같습니다.
사실 이전 버전의 MySQL 마스터-슬레이브 복제에서는 슬레이브 측이 두 개로 완료되지 않습니다. 프로세스가 하나 하나씩 프로세스가 완료됩니다. 그러나 나중에 이를 수행하는 데에는 다음과 같은 주요 위험과 성능 문제가 있음이 밝혀졌습니다.
먼저 프로세스는 bin-log 로그를 복사하고 로그를 구문 분석하여 자체적으로 실행하는 프로세스를 직렬 프로세스로 만듭니다. 성능에는 일정한 제한이 있으며 비동기 복제의 지연도 상대적으로 발생합니다. 긴.
또한, 슬레이브 측이 마스터 측으로부터 bin-log를 얻은 후 로그 내용을 파싱한 후 자체적으로 실행해야 합니다. 이 과정에서 마스터 측에 많은 변경 사항이 발생했을 수 있으며, 새로운 로그도 많이 추가되었을 수 있습니다. 이 단계에서 마스터 저장소에 복구할 수 없는 오류가 발생하면 이 단계에서 수행된 모든 변경 사항은 절대 복구되지 않습니다. 슬레이브에 대한 압력이 상대적으로 높으면 이 프로세스가 더 오래 걸릴 수 있습니다.
복제 성능을 향상하고 기존 위험을 해결하기 위해 MySQL의 이후 버전에서는 슬레이브 측의 복제 작업을 두 프로세스로 이전합니다. 이 개선안을 제안한 사람은 Yahoo!의 엔지니어인 "Jeremy Zawodny"입니다. 이는 성능 문제를 해결할 뿐만 아니라 비동기 지연 시간을 단축하고 데이터 손실 가능성도 줄입니다.
물론 현재의 2스레드 처리로 전환한 후에도 슬레이브 데이터 지연 및 데이터 손실 가능성은 여전히 존재합니다. 결국 이 복제는 비동기식입니다. 데이터 변경 사항이 하나의 트랜잭션에 포함되지 않는 한 이러한 문제는 존재합니다. 이러한 문제를 완전히 피하려면 MySQL 클러스터만 사용하여 문제를 해결할 수 있습니다. 그러나 MySQL의 클러스터는 인메모리 데이터베이스를 위한 솔루션이므로 모든 데이터를 메모리에 로드해야 하기 때문에 매우 큰 메모리가 필요하고 일반 애플리케이션에는 그다지 실용적이지 않습니다.
또 한 가지 언급할 점은 MySQL의 복제 필터를 사용하면 서버에 있는 데이터의 일부만 복사할 수 있다는 것입니다. 복제 필터링에는 두 가지 유형이 있습니다. 마스터의 바이너리 로그에 있는 이벤트 필터링과 슬레이브의 릴레이 로그에 있는 이벤트 필터링입니다. 다음과 같습니다:
마스터의 my.cnf 파일 구성(중요 구성)/etc/my.cnf
log-bin=mysql-bin server-id = 1 binlog-do-db=icinga binlog-do-db=DB2 //如果备份多个数据库，重复设置这个选项即可 binlog-do-db=DB3 //需要同步的数据库，如果没有本行，即表示同步所有的数据库 binlog-ignore-db=mysql //被忽略的数据库 配置Slave的my.cnf文件(关键性的配置)/etc/my.cnf log-bin=mysql-bin server-id=2 master-host=10.1.68.110 master-user=backup master-password=1234qwer master-port=3306 replicate-do-db=icinga replicate-do-db=DB2 replicate-do-db=DB3 //需要同步的数据库，如果没有本行，即表示同步所有的数据库 replicate-ignore-db=mysql //被忽略的数据库
네티즌들은 말했습니다. Replicate-do-db (http://blog.knowsky.com/19696...) 사용 시 문제가 있을 수 있다고 하는데, 직접 테스트해보지는 않았습니다. binlog-do-db 매개변수는 메인 서버에서 Binary Log를 필터링하여 구성 파일에 복사가 허용되지 않는 데이터베이스, 즉 데이터를 허용하지 않는 작업 로그를 작성하지 않는 데이터베이스를 필터링하는 데 사용되는 것 같습니다. 바이너리 로그에 복사되고, 서버에서 복제 로그를 필터링하여 복사가 허용되지 않는 데이터베이스나 테이블을 필터링하는 데 사용됩니다. 즉, 릴레이 로그에서 작업을 실행할 때 해당 허용되지 않는 수정 작업은 수행되지 않습니다. 이 경우 슬레이브 데이터베이스 서버가 여러 개인 경우: 일부 슬레이브 서버는 마스터 서버의 데이터를 복사할 뿐만 아니라 마스터 서버 역할을 하여 다른 슬레이브 서버에 데이터를 복사하므로 binlog-do-가 존재할 수 있어야 합니다. 동시에 구성 파일에 두 개의 매개변수 db 및 복제-do-db가 정확합니다. 모든 것은 내 예측입니다. binlog-do-db 및 Replicate-do-db의 구체적인 사용법은 실제 개발에서 조금 더 살펴봐야 합니다.
메인 서버에서 복제하는 동안 특정 데이터베이스나 테이블을 무시하지 않는 것이 가장 좋다고 인터넷에서 알려져 있는데, 메인 서버가 이를 무시한 후에는 더 이상 바이너리 파일에 쓰지 않기 때문입니다. 그러나 슬레이브에서는 서버에서 일부 데이터베이스가 무시되더라도 마스터 서버의 작업 정보는 슬레이브 서버의 릴레이 로그에 복사되지만 슬레이브 서버에서는 실행되지 않습니다. 이는 마스터 서버의 binlog-do-db 대신 슬레이브 서버에 Replicate-do-db를 설정하는 것이 좋다는 의미라고 생각합니다.
그리고 블랙리스트(binlog-ignore-db, Replicate-ignore-db)든 화이트리스트(binlog-do-db, Replicate-do-db)든 하나만 적어주세요. 동시에 사용하면 화이트리스트만 적용됩니다.
MySQL 마스터-슬레이브 복제에는 동기 복제와 비동기 복제의 두 가지 상황이 있습니다. 아키텍처는 비동기식 복제입니다.
복제의 기본 과정은 다음과 같습니다.
Slave의 IO 프로세스가 Master에 연결되어 데이터를 요청합니다. 지정된 로그 파일에서 지정된 위치 이후의 로그 내용(또는 처음부터의 로그)입니다.
마스터가 슬레이브의 IO 프로세스로부터 요청을 받은 후 복제를 담당하는 IO 프로세스는 요청에 따라 로그의 지정된 위치 이후에 로그 정보를 읽습니다. 정보를 전송하고 이를 슬레이브 IO 프로세스로 반환합니다. 반환된 정보에는 로그에 포함된 정보 외에도 bin-log 파일의 이름과 반환된 정보가 마스터로 전송된 bin-log의 위치도 포함됩니다.
슬레이브의 IO 프로세스가 정보를 받은 후 수신된 로그 내용을 슬레이브 측의 릴레이 로그 파일 끝에 차례로 추가하고 읽기 마스터 측의 bin-log 파일 이름과 위치는 master-info 파일에 기록되므로 다음에 읽을 때 마스터가 "향후 로그 내용을 어느 위치에서 시작해야 하는지를 시작해야 합니다"를 명확하게 알 수 있습니다. 특정 bin-log를 보내주세요."
Slave SQL 프로세스는 릴레이 로그에 새로 추가된 콘텐츠를 감지한 후 릴레이 로그의 콘텐츠를 실제로 실행 가능한 콘텐츠로 즉시 구문 분석합니다. 마스터 측에서 콘텐츠를 실행하고 자체적으로 실행합니다.
复制通常用来创建主节点的副本，通过添加冗余节点来保证高可用性，当然复制也可以用于其他用途，例如在从节点上进行数据读、分析等等。在横向扩展的业务中，复制很容易实施，主要表现在在利用主节点进行写操作，多个从节点进行读操作，MySQL复制的异步性是指：事物首先在主节点上提交，然后复制给从节点并在从节点上应用，这样意味着在同一个时间点主从上的数据可能不一致。异步复制的好处在于它比同步复制要快，如果对数据的一致性要求很高，还是采用同步复制较好。
最简单的复制模式就是一主一从的复制模式了，这样一个简单的架构只需要三个步骤即可完成：
（1）建立一个主节点，开启binlog，设置服务器id；
（2）建立一个从节点，设置服务器id；
（3）将从节点连接到主节点上。
下面我们开始操作，以MySQL 5.5为例，操作系统Ubuntu12.10，Master 10.1.6.159 Slave 10.1.6.191。
apt-get install mysql-server
Master上面开启binlog日志，并且设置一个唯一的服务器id，在局域网内这个id必须唯一。二进制的binlog日志记录master上的所有数据库改变，这个日志会被复制到从节点上，并且在从节点上回放。修改my.cnf文件，在mysqld模块下修改如下内容：
[mysqld] server-id = 1 log_bin = /var/log/mysql/mysql-bin.log
log_bin设置二进制日志所产生文件的基本名称，二进制日志由一系列文件组成，log_bin的值是可选项，如果没有为log_bin设置值，则默认值是：主机名-bin。如果随便修改主机名，则binlog日志的名称也会被改变的。server-id是用来唯一标识一个服务器的，每个服务器的server-id都不一样。这样slave连接到master后，会请求master将所有的binlog传递给它，然后将这些binlog在slave上回放。为了防止权限混乱，一般都是建立一个单独用于复制的账户。
binlog是复制过程的关键，它记录了数据库的所有改变，通常即将执行完毕的语句会在binlog日志的末尾写入一条记录，binlog只记录改变数据库的语句，对于不改变数据库的语句则不进行记录。这种情况叫做基于语句的复制，前面提到过还有一种情况是基于行的复制，两种模式各有各的优缺点。
slave机器和master一样，需要一个唯一的server-id。
[mysqld] server-id = 2
连接Slave到Master
在Master和Slave都配置好后，只需要把slave只想master即可
change master to master_host='10.1.6.159',master_port=3306,master_user='rep', master_password='123456'; start slave;
接下来在master上做一些针对改变数据库的操作，来观察slave的变化情况。在修改完my.cnf配置重启数据库后，就开始记录binlog了。可以在/var/log/mysql目录下看到一个mysql-bin.000001文件，而且还有一个mysql-bin.index文件，这个mysql-bin.index文件是什么？这个文件保存了所有的binlog文件列表，但是我们在配置文件中并没有设置改值，这个可以通过log_bin_index进行设置，如果没有设置改值，则默认值和log_bin一样。在master上执行show binlog events命令，可以看到第一个binlog文件的内容。
注意：上面的sql语句是从头开始复制第一个binlog，如果想从某个位置开始复制binlog，就需要在change master to时指定要开始的binlog文件名和语句在文件中的起点位置，参数如下：master_log_file和master_log_pos。
mysql> show binlog events\G *************************** 1. row *************************** Log_name: mysql-bin.000001 Pos: 4 Event_type: Format_desc Server_id: 1 End_log_pos: 107 Info: Server ver: 5.5.28-0ubuntu0.12.10.2-log, Binlog ver: 4 *************************** 2. row *************************** Log_name: mysql-bin.000001 Pos: 107 Event_type: Query Server_id: 1 End_log_pos: 181 Info: create user rep *************************** 3. row *************************** Log_name: mysql-bin.000001 Pos: 181 Event_type: Query Server_id: 1 End_log_pos: 316 Info: grant replication slave on *.* to rep identified by '123456' 3 rows in set (0.00 sec)
Log_name 是二进制日志文件的名称，一个事件不能横跨两个文件
Pos 这是该事件在文件中的开始位置
Event_type 事件的类型，事件类型是给slave传递信息的基本方法，每个新的binlog都已Format_desc类型开始，以Rotate类型结束
Server_id 创建该事件的服务器id
End_log_pos 该事件的结束位置，也是下一个事件的开始位置，因此事件范围为Pos~End_log_pos-1
Info 事件信息的可读文本，不同的事件有不同的信息
示例
在master的test库中创建一个rep表，并插入一条记录。
create table rep(name var);
insert into rep values ("guol");
flush logs;flush logs命令强制轮转日志，生成一个新的二进制日志，可以通过show binlog events in 'xxx'来查看该二进制日志。可以通过show master status查看当前正在写入的binlog文件。这样就会在slave上执行相应的改变操作。
上面就是最简单的主从复制模式，不过有时候随着时间的推进，binlog会变得非常庞大，如果新增加一台slave，从头开始复制master的binlog文件是非常耗时的，所以我们可以从一个指定的位置开始复制binlog日志，可以通过其他方法把以前的binlog文件进行快速复制，例如copy物理文件。在change master to中有两个参数可以实现该功能，master_log_file和master_log_pos，通过这两个参数指定binlog文件及其位置。我们可以从master上复制也可以从slave上复制，假如我们是从master上复制，具体操作过程如下：
（1）为了防止在操作过程中数据更新，导致数据不一致，所以需要先刷新数据并锁定数据库：flush tables with read lock。
（2）检查当前的binlog文件及其位置：show master status。
mysql> show master status\G *************************** 1. row *************************** File: mysql-bin.000003 Position: 107 Binlog_Do_DB: Binlog_Ignore_DB: 1 row in set (0.00 sec)
（3）通过mysqldump命令创建数据库的逻辑备分：mysqldump --all-databases -hlocalhost -p >back.sql。
（4）有了master的逻辑备份后，对数据库进行解锁：unlock tables。
（5）把back.sql复制到新的slave上，执行：mysql -hlocalhost -p 把master的逻辑备份插入slave的数据库中。
（6）现在可以把新的slave连接到master上了，只需要在change master to中多设置两个参数master_log_file='mysql-bin.000003'和master_log_pos='107'即可，然后启动slave：start slave，这样slave就可以接着107的位置进行复制了。
change master to master_host='10.1.6.159',master_port=3306,master_user='rep', master_password='123456',master_log_file='mysql-bin.000003',master_log_pos='107'; start slave;
有时候master并不能让你锁住表进行复制，因为可能跑一些不间断的服务，如果这时master已经有了一个slave，我们则可以通过这个slave进行再次扩展一个新的slave。原理同在master上进行复制差不多，关键在于找到binlog的位置，你在复制的同时可能该slave也在和master进行同步，操作如下：
（1）为了防止数据变动，还是需要停止slave的同步：stop slave。
（2）然后刷新表，并用mysqldump逻辑备份数据库。
（3）使用show slave status查看slave的相关信息，记录下两个字段的值Relay_Master_Log_File和Exec_Master_Log_Pos，这个用来确定从后面哪里开始复制。
（4）对slave解锁，把备份的逻辑数据库导入新的slave的数据库中，然后设置change master to，这一步和复制master一样。
由一个master和一个slave组成复制系统是最简单的情况。Slave之间并不相互通信，只能与master进行通信。在实际应用场景中，MySQL复制90%以上都是一个Master复制到一个或者多个Slave的架构模式，主要用于读压力比较大的应用的数据库端廉价扩展解决方案。
在上图中，是我们开始时提到的一主多从的情况，这时主库既要负责写又要负责为几个从库提供二进制日志。这种情况将二进制日志只给某一从，这一从再开启二进制日志并将自己的二进制日志再发给其它从，或者是干脆这个从不记录只负责将二进制日志转发给其它从，这样架构起来性能可能要好得多，而且数据之间的延时应该也稍微要好一些。PS：这些前面都写过了，又复制了一遍。
上图中，Master-Master复制的两台服务器，既是master，又是另一台服务器的slave。这样，任何一方所做的变更，都会通过复制应用到另外一方的数据库中。在这种复制架构中，各自上运行的不是同一db，比如左边的是db1,右边的是db2，db1的从在右边反之db2的从在左边，两者互为主从，再辅助一些监控的服务还可以实现一定程度上的高可以用。
上图中，这是由master-master结构变化而来的，它避免了M-M的缺点，实际上，这是一种具有容错和高可用性的系统。它的不同点在于其中只有一个节点在提供读写服务，另外一个节点时刻准备着，当主节点一旦故障马上接替服务。比如通过corosync+pacemaker+drbd+MySQL就可以提供这样一组高可用服务，主备模式下再跟着slave服务器，也可以实现读写分离。
이 구조의 장점은 중복성을 제공한다는 것입니다. 지리적으로 분산된 복제 구조로 단일 노드 장애 문제가 없으며, 읽기 집약적인 요청도 슬레이브에 배치할 수 있습니다.
이전 MySQL 복제는 비동기 기반으로만 구현할 수 있었습니다. MySQL-5.5부터는 반자동 복제가 지원됩니다. 이전 비동기 복제에서는 일부 트랜잭션을 실행한 후 기본 데이터베이스가 대기 데이터베이스의 진행을 제어하지 않았습니다. 대기 데이터베이스가 뒤쳐지고 불행하게도 기본 데이터베이스가 충돌하는 경우(예: 가동 중지 시간) 대기 데이터베이스의 데이터가 불완전해집니다. 즉, 기본 데이터베이스에 장애가 발생하면 대기 데이터베이스를 사용하여 데이터 일관성 서비스를 계속 제공할 수 없습니다. 반동기 복제(반동기 복제)는 제출된 트랜잭션이 적어도 하나의 대기 데이터베이스에 전송되었음을 어느 정도 보장합니다. 반동기식에서는 트랜잭션이 대기 데이터베이스에 전달되었는지만 확인하고, 대기 데이터베이스에서 실행되었는지는 보장하지 않습니다.
이 외에도 기본 데이터와 보조 데이터가 일치하지 않는 상황이 발생할 수 있는 또 다른 상황이 있습니다. 세션에서 트랜잭션이 기본 데이터베이스에 제출된 후 트랜잭션이 하나 이상의 대기 데이터베이스로 전송될 때까지 기다립니다. 이 대기 프로세스 중에 기본 데이터베이스가 충돌하면 대기 데이터베이스와 기본 데이터베이스가 일치하지 않을 수 있습니다. , 이는 매우 치명적입니다. 활성 및 대기 네트워크가 실패하거나 대기 데이터베이스가 다운된 경우 기본 데이터베이스는 계속하기 전에 트랜잭션이 제출된 후 10초(기본값 rpl_semi_sync_master_timeout) 동안 대기합니다. 이때 기본 라이브러리는 원래 비동기 상태로 다시 변경됩니다.
MySQL이 Semi-sync 플러그인을 로드하고 활성화한 후 각 트랜잭션은 로그를 클라이언트에 반환하기 전에 대기 데이터베이스가 로그를 수신할 때까지 기다려야 합니다. 소규모 트랜잭션을 수행하고 두 호스트 간의 지연이 작은 경우 Semi-sync는 성능 손실을 거의 주지 않으면서 데이터 손실을 전혀 발생시키지 않을 수 있습니다.
위 내용은 이 글의 전체 내용입니다. 모든 분들의 공부에 도움이 되었으면 좋겠습니다. 더 흥미로운 내용을 보려면 PHP 중국어 웹사이트의 관련 튜토리얼 열을 주의 깊게 살펴보세요! ! !
위 내용은 MySql 마스터-슬레이브 복제란 무엇입니까? 구현을 구성하는 방법은 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
