文章目录

  • 一、做一下相关文件的备份
    • 1.OCR备份
    • 2.grid用户profile备份
  • 二、修改VIP
    • 1.修改节点应用配置nodeapps
    • 2.重启节点一CRS并修改/etc/hosts中节点1的vip地址
  • 三、修改VIP完成后验证
  • 三、非同网段vip地址替换
  • srvctl modify nodeapps -n <node> -A <new_vip_address or new_vip_hostname>/<netmask>/<[if1[if2...]]>
  • srvctl modify nodeapps -n <nodename>1 -A <nodename>1-nvip/255.255.255.0/<if_name>
  • srvctl modify network -k <network_number>] [-S <subnet>/<netmask>[/if1[|if2...]]
  • srvctl modify network -k 1 -S 110.XX.XX.0/255.255.255.0/<if_name>
  • srvctl modify network -k 1 -S 110.XX.XX.0/255.255.255.0/<if_name>
  • srvctl modify network -k 1 -S 110.XX.XX.0/255.255.255.0
  • srvctl modify network -k 1 -S 110.XX.XX.0/255.255.255.0/<if_name>2
  • crsctl modify res ora.<nodename>.vip -attr USR_ORA_VIP=<nodename>1-nvip
  • crsctl stat res ora.<nodename>1.vip -p |grep USR_ORA_VIP

一、做一下相关文件的备份

1.OCR备份

[root@zydb1 ~]# cd /u01/11.2.0/grid_11204/bin
[root@zydb1 bin]# ./ocrconfig -manualbackup

2.grid用户profile备份

[grid@zydb1 peer]$ ls
profile_orig.xml  profile.xml
[grid@zydb1 peer]$ cp profile_orig.xml profile_orig.xml.bak
[grid@zydb1 peer]$ cp profile.xml profile.xml.bak
[grid@zydb1 peer]$ pwd
/u01/11.2.0/grid_11204/gpnp/profiles/peer
--这两个文件记录了集群的基本配置信息,何节点信息

二、修改VIP

1.修改节点应用配置nodeapps

--修改前nodeapps配置
[grid@zydb1 peer]$ srvctl config nodeapps
Network exists: 1/192.168.0.0/255.255.255.0/enp0s3, type static
VIP exists: /zydb1-vip/192.168.0.13/192.168.0.0/255.255.255.0/enp0s3, hosting node zydb1
VIP exists: /zydb2-vip/192.168.0.14/192.168.0.0/255.255.255.0/enp0s3, hosting node zydb2
GSD exists
ONS exists: Local port 6100, remote port 6200, EM port 2016
--修改nodeapps的vip地址
[root@zydb1 bin]# pwd
/u01/11.2.0/grid_11204/bin
[root@zydb1 bin]# ./srvctl modify nodeapps -n zydb1 -A 192.168.0.23/255.255.255.0/enp0s3
[root@zydb1 bin]# ./srvctl config nodeapps
Network exists: 1/192.168.0.0/255.255.255.0/enp0s3, type static
VIP exists: /192.168.0.23/192.168.0.23/192.168.0.0/255.255.255.0/enp0s3, hosting node zydb1
VIP exists: /zydb2-vip/192.168.0.14/192.168.0.0/255.255.255.0/enp0s3, hosting node zydb2
GSD exists
ONS exists: Local port 6100, remote port 6200, EM port 2016--修改nodeapps的监听地址
SQL> show parameter local_listener; NAME                  TYPE    VALUE
------------------------------------ ----------- ------------------------------
local_listener               string   (DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.0.13)(PORT=1521))))SQL> alter system set local_listener="(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.0.23)(PORT=1521))";System altered.SQL> show parameter remote_listener;NAME                    TYPE    VALUE
------------------------------------ ----------- ------------------------------
remote_listener              string

检查并修改listener.ora和tnsnames.ora文件,如果这两个文件里有使用旧的vip地址的需要改掉

cd $ORACLE_HOME/network/admin
cat listener.ora
cat tnsnames.ora

2.重启节点一CRS并修改/etc/hosts中节点1的vip地址

[root@zydb1 bin]# ./crsctl stop crs修改/etc/hosts
[root@zydb1 ~]# vi /etc/hosts
[root@zydb1 ~]# cat /etc/hosts
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
192.168.0.11 zydb1
192.168.0.12 zydb2192.168.56.104 zydb1-priv
192.168.56.103 zydb2-priv#192.168.0.13 zydb1-vip
192.168.0.23 zydb1-vip
192.168.0.14 zydb2-vip192.168.0.15 zydb-scan[root@zydb1 bin]# ./crsctl start crs
CRS-4124: Oracle High Availability Services startup failed.
CRS-4000: Command Start failed, or completed with errors.--这里启动失败了,我重启服务器后恢复正常

三、修改VIP完成后验证

--节点启动正常后,新改的节点vip地址此时应该就能ping通了
[root@zydb1 ~]# ip a    --vip地址已经变成23
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00inet 127.0.0.1/8 scope host lovalid_lft forever preferred_lft foreverinet6 ::1/128 scope host valid_lft forever preferred_lft forever
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000link/ether 08:00:27:76:a6:45 brd ff:ff:ff:ff:ff:ffinet 192.168.0.11/24 brd 192.168.0.255 scope global noprefixroute enp0s3valid_lft forever preferred_lft foreverinet 192.168.0.23/24 brd 192.168.0.255 scope global secondary enp0s3:1valid_lft forever preferred_lft foreverinet6 fe80::6c87:b777:fe5b:1f6d/64 scope link noprefixroute valid_lft forever preferred_lft forever
3: enp0s8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000link/ether 08:00:27:f1:51:ed brd ff:ff:ff:ff:ff:ffinet 192.168.56.104/24 brd 192.168.56.255 scope global noprefixroute dynamic enp0s8valid_lft 391sec preferred_lft 391secinet 169.254.255.236/16 brd 169.254.255.255 scope global enp0s8:1valid_lft forever preferred_lft foreverinet6 fe80::4017:466a:ade1:ea15/64 scope link noprefixroute valid_lft forever preferred_lft forever[grid@zydb1 crsd]$ oifcfg getif -global
enp0s3  192.168.0.0  global  public
enp0s8  192.168.56.0  global  cluster_interconnectgrid@zydb1 crsd]$ srvctl config nodeapps
Network exists: 1/192.168.0.0/255.255.255.0/enp0s3, type static
VIP exists: /192.168.0.23/192.168.0.23/192.168.0.0/255.255.255.0/enp0s3, hosting node zydb1
VIP exists: /zydb2-vip/192.168.0.14/192.168.0.0/255.255.255.0/enp0s3, hosting node zydb2
GSD exists
ONS exists: Local port 6100, remote port 6200, EM port 2016

三、非同网段vip地址替换

--这个没有试过,抄的作业如有需求的可以试试。--查看当前配置:oifcfg getif -global
日志如下:ens192  100.1.0.0  global  public
ens161  100.1.7.0  global  cluster_interconnect
--删除当前配置./oifcfg delif -global eth0
--添加当前配置./oifcfg setif -global eth0/100.16.0.0:public
./oifcfg setif -global eth1/192.168.0.0:cluster_interconnect
--查看当前配置:oifcfg getif -global
eth0  100.16.0.0  global  public
eth1  192.168.0.0  global  cluster_interconnect

这篇文章参考了:陈举超,Oracle ACE、Oracle 11g OCM,OCMU 用户组成员、ITPUB博客地址: http://blog.itpub.net/29785807/ 公众号: IT 小Chen,有兴趣可以关注原作者。

下面是几种情况的修改案例操作: 1.修改public hostname 2.public IP or VIP
How to Modify Public Network Information including VIP in Oracle Clusterware (文档 ID 276434.1)
APPLIES TO:
Oracle Cloud Infrastructure - Database Service - Version N/A and later
Oracle Database Backup Service - Version N/A and later
Oracle Database Cloud Exadata Service - Version N/A and later
Oracle Database Cloud Service - Version N/A and later
Oracle Database - Enterprise Edition - Version 10.1.0.2 and later
Information in this document applies to any platform.
PURPOSE
The purpose of this note is to illustrate how to change a public hostname, public IP, a Virtual IP Address (VIP), VIP hostname or other VIP attributes in an Oracle Clusterware/Grid Infrastructure environment.

SCOPE
Oracle Database 10g and 11g use VIPs (Virtual IP) in clustered environments for clients to connect to the database. These VIPs are static IP addresses associated with (virtual) hostnames and resolved through DNS (except when using 11gR2 GNS).

During the installation of the Oracle Clusterware users are prompted to enter a Virtual IP and Virtual hostname for each of the node in the cluster. These are stored within the OCR (Oracle Cluster Registry) and different components within the HA framework depend on these VIPs. If for some reason the need arises to change either the VIP, the VIP hostname, or the subnet, netmask etc, this procedure should be followed.

For changes associated with private network/cluster interconnect, please refer to Note 283684.1
DETAILS
Case I. Changing public hostname
Public hostname is recorded in OCR, it is entered during installation phase. It can not be modified after the installation. The only way to modify public hostname is by deleting the node, then adding the node back with a new hostname, or reinstalling the clusterware or following the clone procedure to reconfigure the clusterware.

Case II. Changing public IP or VIP only without changing interface, subnet or netmask or changing MAC address only without changing anything else
If the change is only public IP or VIP address and the new ones are still in the same subnet, same interface, or if the change is only for public IP MAC address, IP/interface/subnet/netmask all remain the same, nothing needs to be done at clusterware layer, all changes need to be done at OS layer to reflect the change.

  1. Shutdown Oracle Clusterware stack
  2. Modify the IP address at network layer, DNS and /etc/hosts file to reflect the change or modify the MAC address at network layer
  3. Restart Oracle Clusterware stack

Above change can be done in rolling fashion, eg: one node at a time.

Case III. Changing public network interface, subnet or netmask
If the change involves different subnet(netmask) or interface, delete the existing interface information from OCR and add it back with the correct information is required. In the example here, the subnet is changed from 10.2.156.0 to 10.2.166.0 via two separate commands - first a ‘delif’ followed by a ‘setif’:

% $CRS_HOME/bin/oifcfg/oifcfg delif -global <if_name>[/]
% $CRS_HOME/bin/oifcfg/oifcfg setif -global <if_name>/:public

For example:
% $CRS_HOME/bin/oifcfg delif -global eth0/10.X.156.0
% $CRS_HOME/bin/oifcfg setif -global eth0/10.X.166.0:public
Then make the change at OS layer. There is no requirement to restart Oracle clusterware unless OS change requires a node reboot. This can be done in rolling fashion.

Once public network is changed, its associated VIP and SCAN VIP are also required to change, refer to CASE IV and CASE V.

Note: for 11gR2, above command requires clusterware RUNNING on ALL nodes, otherwise PRIF-33 and PRIF-32 will be reported, i.e.
[grid@racnode1 bin]$ ./oifcfg delif -global <if_name>/192.168.1.0
PRIF-33: Failed to set or delete interface because hosts could not be discovered
CRS-02307: No GPnP services on requested remote hosts.
PRIF-32: Error in checking for profile availability for host 2
CRS-02306: GPnP service on host “2” not found.

Case IV. Changing VIPs associated with public network change
Planning for VIP changes
In general, a complete outage is only required for pre-10.2.0.3 release. From 10.2.0.3 onwards, the ASM/database instance dependency on the VIP resource is removed, so the VIP could be modified without having to take down the ASM/database instance, only client connections to the database will be affected when VIP is down. If the modification is a node specific, then only connection to that node will be affected during the time of change.

Please follow Case III to ensure public network changes are made first. If there is a node reboot or Clusterware restart after the OS network change, vip will not start, please skip to step “Modifying VIP and its Associated Attributes”.

Gathering Current VIP Configuration

  1. Gather the existing setup
    for 10g and 11gR1, as Oracle Clusterware owner:

$ srvctl config nodeapps -n -a

eg:
$ srvctl config nodeapps -n 1 -a
VIP exists.: /1-vip/101.XX.XX.184/255.255.254.0/<if_name>

for 11gR2, as Grid Infrastructure owner:

$ srvctl config nodeapps -a

eg:
$ srvctl config nodeapps -a
Network exists: 1/101.17.80.0/255.255.254.0/<if_name>, type static
VIP exists: /racnode1-vip/101.17.XX.184/101.17.80.0/255.255.254.0/<if_name>, hosting node 1
VIP exists: /racnode2-vip/101.17.XX.186/101.17.80.0/255.255.254.0/<if_name>, hosting node 2

  1. Verify VIP status

10.2 and 11.1:
$ crs_stat -t

11.2:
$ crsctl stat res -t

  • it should show VIPs are ONLINE

$ ifconfig -a
(netstat -in for HP and ipconfig /all for Windows)

  • VIP logical interface is bound to the public network interface

Stopping Resources
3. Stop the nodeapps resources (and all dependent resources ASM/DB only if required):

10g and 11gR1, as Oracle Clusterware owner:

$ srvctl stop instance -d <db_name> -i <inst_name> (optional for 10.2.0.3+)
$ srvctl stop asm -n <node_name> (optional for 10.2.0.3+)
$ srvctl stop nodeapps -n <node_name>

eg,
$ srvctl stop instance -d -i
$ srvctl stop asm -n 1
$ srvctl stop nodeapps -n 1

11gR2, as Grid Infrastructure owner:

$ srvctl stop instance -d <db_name> -n <node_name> (optional)
$ srvctl stop vip -n <node_name> -f

eg,
$ srvctl stop instance -d -n 1
$ srvctl stop vip -n 1 -f

Note 1: The -f option is required for 11gR2 to stop listener resource, otherwise following error will occur:
PRCR-1014 : Failed to stop resource ora.1.vip
PRCR-1065 : Failed to stop resource ora.1.vip
CRS-2529: Unable to act on ‘ora.1.vip’ because that would require stopping or relocating ‘ora.LISTENER.lsnr’, but the force option was not specified

  1. Verify VIP is now OFFLINE and the interface is no longer bound to the public network interface

$ crs_stat -t (or $ crsctl stat res -t for 11gR2)

$ ifconfig -a
(netstat -in for HP and ipconfig /all for windows)

Modifying VIP and Its Associated Attributes
5. Determine the new VIP IP/subnet/netmask or VIP hostname, make the network change on OS first, ensure the new VIP is registered in DNS or modified in /etc/hosts (for Unix/Linux) and \WINDOWS\System32\drivers\etc\hosts file (for Windows). If the network interface is changed, ensure the new interface is available on the server before proceeding with the modification.

For example:
New VIP is: 110.XX.XX.11 1-nvip
new subnet is 110.11.70.0
new netmask is 255.255.255.0
new interface is <if_name>

  1. Modify the VIP resource, as root user:

srvctl modify nodeapps -n -A <new_vip_address or new_vip_hostname>//<[if1[if2…]]>

eg:

srvctl modify nodeapps -n 1 -A 1-nvip/255.255.255.0/<if_name>

Note 1: Starting with 11.2, the VIPs depend on the network resource (ora.net1.network), the OCR only records the VIP hostname or the IP address associated with the VIP resource. The network attributes (subnet/netmask/interface) are recorded with the network resource. When the nodeapps resource is modified, the network resoure(ora.net1.network) attributes are also modified implicitly.

From 11.2.0.2 onwards, if only subnet/netmask/interface change is required, network resource can be modified directly via srvctl modify network command.
as root user:

srvctl modify network -k <network_number>] [-S /[/if1[|if2…]]

eg:

srvctl modify network -k 1 -S 110.XX.XX.0/255.255.255.0/<if_name>

There is no need to modify VIP or SCAN if other attributes are not changed.

Note 2: For 12.1.0.1 release, due to unpublished Bug 16608577 - CANNOT ADD SECOND PUBLIC INTERFACE IN ORACLE 12.1, the srvctl modify network command fails with:

srvctl modify network -k 1 -S 110.XX.XX.0/255.255.255.0/<if_name>

PRCT-1305 : The specified interface name “<if_name>2” does not match the existing network interface name “<if_name>1”

Workaround is to modify network resource with an empty interface name, then modify it again with the desired interface name, eg:

srvctl modify network -k 1 -S 110.XX.XX.0/255.255.255.0

srvctl modify network -k 1 -S 110.XX.XX.0/255.255.255.0/<if_name>2

The bug has been fixed in 12.1.0.2 and above.

  • A special case for 11gR2 modifying the VIP hostname only without changing the IP address.

For example: only VIP hostname changes from 1-vip to 1-nvip, IP and other attributes remain the same.

If IP address is not changed, above modify command will not change the USR_ORA_VIP value in ‘crsctl stat res ora..vip -p’ output. Please use the following command:

crsctl modify res ora..vip -attr USR_ORA_VIP=1-nvip

Verify the changes for USR_ORA_VIP field:

crsctl stat res ora.1.vip -p |grep USR_ORA_VIP

Note: For Windows platform, the interface name needs to be in quote (") if there is a space in between, eg:
As administrator user or software install user:

srvctl modify nodeapps -n -A 110.XX.XX.11/255.255.255.0/“Local Area Connection 1”

  1. Verify the change

$ srvctl config nodeapps -n -a (10g and 11gR1)
$ srvctl config nodeapps -a (11gR2)

eg:
$ srvctl config nodeapps -n 1 -a
VIP exists.: /1-nvip/110.11.70.11/255.255.255.0/<if_name>2
Update the crsconfig_params
8. Other tools like fpp or rhp use this file and it needs to be keep current.

Editing the network resources is allowed.

cd $GI_HOME/crs/install and backup the crsconfig_params file
cp $GI_HOME/crs/install/crsconfig_params $GI_HOME/crs/install/crsconfig_params.orig

Then edit the file as the root user

vi $GI_HOME/crs/install/crsconfig_params

change only the addresses and subnet addresses for CRS_NODEVIP, NETWORKS, and NEW_NODEVIPS

Save the file.

Restarting Resources
9. Start the nodeapps and the other resources

10g and 11gR1, as Oracle Clusterware owner:

$ srvctl start nodeapps -n <node_name>
$ srvctl start asm -n <node_name> (optional for 10.2.0.3+)
$ srvctl start instance -d -i (optional for 10.2.0.3+)

eg:
$ srvctl start nodeapps -n 1
$ srvctl start asm -n 1
$ srvctl start instance -d -i 1
11gR2, as Grid Infrastructure owner:

$ srvctl start vip -n <node_name>
$ srvctl start listener -n <node_name>
$ srvctl start instance -d <db_name> -n <node_name> (optional)

eg,
$ srvctl start vip -n 1
$ srvctl start listener -n 1
$ srvctl start instance -d -n 1
Note: if the network attributes are changed, i.e. netmask changed, restart the nodeapps

  1. Verify the new VIP is ONLINE and bind to the public network interface

$ crs_stat -t (or $ crsctl stat res -t for 11gR2)

$ ifconfig -a
(netstat -in for HP or ipconfig /all for windows)

  1. Repeat the same steps for the rest nodes in the cluster only if the similar change is required.

Others
12. Modify listener.ora, tnsnames.ora and LOCAL_LISTENER/REMOTE_LISTENER parameter to reflect the VIP change if necessary.

Note, LOCAL_LISTENER for ASM and DB are set automatically by Grid Infrastructure. The VIP change in LOCAL_LISTENER should take effect automatically. Due to Bug 22824602, under some race condition, the LOCAL_LISTENER for ASM instance might not reflect the VIP change. The workaround is to restart the Clusterware on the affected node.

Case V. Change SCAN VIP associated with public network change
With Grid Infrastructure 11gR2, SCAN and SCAN VIP are introduced for client connections. To modify the SCAN VIP, please refer to

Note 952903.1 How to update the IP address of the SCAN VIP resources (ora.scan.vip)
Note 972500.1 How to Modify SCAN Setting or SCAN Listener Port after Installation

Note: if rolling back the change is required, repeat the commands which have been run, replace the new value with original value to restore the original configuration.

11.2.0.4修改RAC单节点VIP相关推荐

  1. Oracle 11.2.0.4 x64 RAC扩展存储空间

    1. 数据库信息 操作系统版本  : OEL6.5 x64    数据库版本    : Oracle 11.2.0.4 x64 RAC      本文针对oracle 11.2.0.4 x64 RAC ...

  2. AIX 6.1 安装 Oracle 11.2.0.4 ASM RAC PSU 最佳实践

    AIX 6.1 安装 Oracle 11.2.0.4 ASM RAC PSU 最佳实践 近期自己在AIX 6.1平台上安装过多次RAC,碰到过各种坑,究其原因大多是因为配置不对,权限问题等没有遵循官方 ...

  3. oracle_ofsd,Oracle 11.2.0.4 x64 RAC扩展存储空间

    1. 数据库信息 操作系统版本  : OEL6.5 x64 数据库版本    : Oracle 11.2.0.4 x64 RAC 本文针对oracle 11.2.0.4 x64 RAC for OEL ...

  4. 构建适用于Oracle 11.2.0.x的Linux单数据库实例的DataGuard

    构建适用于Oracle 11.2.0.x的Linux单数据库实例的DataGuard 使用脚本自动化构建Oracle DataGuard 下载脚本 git clone https://github.c ...

  5. 为11.2.0.2 Grid Infrastructure添加节点

    在之前的文章中我介绍了为10g RAC Cluster添加节点的具体步骤.在11gr2中Oracle CRS升级为Grid Infrastructure,通过GI我们可以更方便地控制CRS资源如:VI ...

  6. oracle rac单节点恢复,如何Oracle_RAC恢复一个节点总结

    Rac1 已坏 Rac3 正常 先在rac3上把rac1的信息删干净,然后重新填加rac1 步骤如下: 1,在rac1上运行DBCA,删除instance; 2,如果有ASM,删除ASM实例, srV ...

  7. linux dump命令 异机,Oracle 11.2.0.4 从单实例,使用RMAN 异机恢复到RAC

    Oracle 11.2.0.4从单实例,使用RMAN异机恢复到RAC 注意: (1)迁移的2个db版本版本要一致.包括小版本. (2)RMAN异机恢复的时候,db_name必须相同.如果说要想改成其他 ...

  8. asm冗余 oracle_oracle 11.2.0.1 rac 修改asm磁盘组的冗余模式(redundancy mode)为normal

    oracle 11.2.0.1 rac 修改asm磁盘组的冗余模式(redundancy mode)为normal 背景介绍: oracle 11.2.0.1 linux rac , ocr和vote ...

  9. oracle 11G 11.2.0.4 RAC环境打补丁

    一.准备工作 1,数据库环境 操作系统版本  : RedHat 7.2 x64    数据库版本    : Oracle 11.2.0.4 x64 RAC     Grid          : 11 ...

最新文章

  1. PHP 实现无限分类
  2. python面向对象总结_python面向对象总结
  3. 查看Linux 硬件配置
  4. 如何解决Git中的合并冲突
  5. 【提权思路】绕过SecureRDP限制远程连接
  6. 【学员分享】深度学习计算机视觉,两个星期从入门到上线
  7. 循环尝试,不释放CPU
  8. 【小程序】微信小程序开发实践
  9. Divergent series
  10. 选择数据分析工具应考虑4个因素
  11. 毕设——社区志愿者信息管理系统
  12. topaz滤镜 V1.31中文版
  13. 稳压电源: 电路图及类型
  14. 商业智能知识分享:BI的4大核心技术
  15. IOS开发之——TOM猫(19)
  16. 无线传感器网络实验与作业总结
  17. android蓝牙浅析
  18. AUTOSAR DiagnosticLogAndTrace DLT(三)-- 消息的发送、DLT命令的发送与接收
  19. 振弦传感器计算公式推导及测量原理
  20. JAVA体育用品在线商城系统-springboot【数据库设计、论文、源码、开题报告】

热门文章

  1. Dell iDrac试用许可下载
  2. 测试笑话看着看着哭完了
  3. Android组件化和插件化开发
  4. js 中 Maximum call stack size exceeded
  5. php ech,php,初学者问你!
  6. 开发中遇到的问题 JSON转义字符 String转小写 SQL查询
  7. Python爬虫怎么挣钱?解析Python爬虫赚钱新方式
  8. storm drpc实例
  9. TP-LINK 703N无线路由器开启IPV6功能
  10. 情人节特献:有心之函数必然就有分手函数