CA API GatewayAPI SECURITYCA API Gateway Precision API Monitoring Module for API Gateway (Layer 7)CA API Gateway Enterprise Service Manager (Layer 7)STARTER PACK-7CA Microgateway
Issue/Introduction
We've recently upgraded API Gateway Appliance to 9.4 and mysql also upgraded to 5.7. We're seeing below warning messages in mysqld.log while starting mysql. Need to understand about the impact of the problem that the message is pointing at, changes suggested by it and the effect of the potential change.
2020-05-05T08:06:42.218889Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details). I've already gone through https://dev.mysql.com/doc/refman/5.6/en/upgrading-from-previous-series.html and understood the changes its bringing. Can you please confirm if not using explicit_defaults_for_timestamp would impact us anyway from Gateway/SSG DB perspective. Same questions if we imlement explicit_defaults_for_timestamp ?
2020-05-05T08:06:42.393275Z 0 [Warning] RSA private key file not found: /var/lib/mysql//private_key.pem. Some authentication plugins will not work. 2020-05-05T08:06:42.393284Z 0 [Warning] RSA public key file not found: /var/lib/mysql//public_key.pem. Some authentication plugins will not work. I've gone through https://bugs.mysql.com/bug.php?id=70736. Please confirm if we are good if we don't implement the suggestions from Virtual Appliance perspective.
2020-05-05T08:11:50.893111Z 1 [Warning] Storing MySQL user name or password information in the master info repository is not secure and is therefore not recommended. Please consider using the USER and PASSWORD connection options for START SLAVE; see the 'START SLAVE Syntax' in the MySQL Manual for more information. I tried with start slave USER='****' PASSWORD='****'; It says "Sending passwords in plain text without SSL/TLS is extremely insecure." Please suggest what we need implement further ? Also, everytime we restart mysql it will try to connect taking inputs from master.info. How can we provide user/password during that ?
2020-05-08T16:33:42.448433-00:00 51636 [Warning] Slave SQL for channel '': If a crash happens this configuration does not guarantee that the relay log info will be consistent, Error_code: 0 What does this warning signify ? Is it safe to ignore ? Else, how can we mitigate this ?
Environment
Release : 9.4
Component : API GATEWAY
Resolution
2020-05-05T08:06:42.218889Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
>> First you don't need to change anything yet. Those nonstandard behaviors remain the default for TIMESTAMP but as of MySQL 5.6.6 are deprecated and this warning appears at startup. Now if you want to move to new behaviors you have to add this line in your my.cnf in the [mysqld] section to avoid this noise. >> explicit_defaults_for_timestamp = 1
2020-05-05T08:06:42.393275Z 0 [Warning] RSA private key file not found: /var/lib/mysql//private_key.pem. Some authentication plugins will not work. 2020-05-05T08:06:42.393284Z 0 [Warning] RSA public key file not found: /var/lib/mysql//public_key.pem. Some authentication plugins will not work.
>> Doesn't require any changes ..
2020-05-05T08:11:50.893111Z 1 [Warning] Storing MySQL user name or password information in the master info repository is not secure and is therefore not recommended. Please consider using the USER and PASSWORD connection options for START SLAVE; see the 'START SLAVE Syntax' in the MySQL Manual for more information.
>> The io thread reconnect messages are a known noisy behavior so no actions are required
2020-05-08T16:33:42.448433-00:00 51636 [Warning] Slave SQL for channel '': If a crash happens this configuration does not guarantee that the relay log info will be consistent, Error_code: 0
>> There is nothing scary about this error. A common request is to have replication crash-safe in the sense that the replication progress information always is in sync with what has actually been applied to the database, even in the event of a crash. Although transactions are not lost if the server crashes, it could require some tweaking to bring the slaves up again.