Thursday, June 9, 2016

How to fix "ERROR 1067 (42000): Invalid default value for tableName" occur even after removing 'DEFAULT 0' when two timestamp columns are defined.

In MySQL 5.7 'DEFAULT 0' is not accepted for when defining timestamp columns as 'NO_ZERO_DATE' mode is enabled by default.

I get "ERROR 1067 (42000): Invalid default value for 'REG_LAST_UPDATED_TIME' error when creating the table below, even after removing 'DEFAULT 0' in
EX: 'REG_CREATED_TIME    TIMESTAMP NOT NULL DEFAULT 0,'

1. Issue description

CREATE TABLE IF NOT EXISTS REG_RESOURCE(
            REG_PATH_ID         INTEGER NOT NULL,
            REG_NAME            VARCHAR(256),
            REG_VERSION         INTEGER NOT NULL AUTO_INCREMENT,
            REG_MEDIA_TYPE      VARCHAR(500),
            REG_CREATOR         VARCHAR(31) NOT NULL,
            REG_CREATED_TIME    TIMESTAMP NOT NULL,
            REG_LAST_UPDATOR    VARCHAR(31),
            REG_LAST_UPDATED_TIME    TIMESTAMP NOT NULL,
            REG_DESCRIPTION     VARCHAR(1000),
            REG_CONTENT_ID      INTEGER,
            REG_TENANT_ID INTEGER DEFAULT 0,
            REG_UUID VARCHAR(100) NOT NULL,
            CONSTRAINT PK_REG_RESOURCE PRIMARY KEY(REG_VERSION, REG_TENANT_ID)
)ENGINE INNODB;

When creating above table "ERROR 1067 (42000): Invalid default value for 'REG_LAST_UPDATED_TIME' error occurred and table didn't get created. Please note that this error shows only when there are two timestamp columns (REG_CREATED_TIME and REG_LAST_UPDATED_TIME) in the table.

2. What happens when there are two time stamp columns?

According to [1] when we have two timestamp columns not declared an explicit 'DEFAULT' or 'ON UPDATE' clause, first column is automatically assigned the DEFAULT CURRENT_TIMESTAMP and ON UPDATE CURRENT_TIMESTAMP attributes, while the second one is assigned the '0000-00-00 00:00:00' (the “zero” timestamp).

3. Why are we getting the Error explained In issue description?

When 'strict SQL mode' and ' NO_ZERO_DATE' mode is enabled in MySQL server the “zero” timestamp is not allowed and it gives an error [2]. In MySQL 5.7 by default 'NO_ZERO_DATE' mode is enabled.

4.Fix

1) Recommended way of doing is replacing "DEFAULT 0" with "DEFAULT CURRENT_TIMESTAMP" .

2) You can also fix it by changing mysql modes

E.g. Setting MySQL mode to  'ALLOW_INVALID_DATES' [3].

> SET SQL_MODE='ALLOW_INVALID_DATES';


[1]. http://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_explicit_defaults_for_timestamp
[2]. http://dev.mysql.com/doc/refman/5.7/en/sql-mode.html#sqlmode_no_zero_date
[3]. http://dev.mysql.com/doc/refman/5.7/en/sql-mode.html#sqlmode_allow_invalid_dates


Tuesday, May 24, 2016

How to sync time between servers.

Recently when I was working with a WSO2 Identity server cluster I needed server time to be sync between all nodes (servers). I used Centos and below are the steps I used.

1. Install ntpdate using

sudo yum install ntpdate

2. Synced time with 'sltime.org' time server

3. Created a shell script to run above command every 6 hours.


  • Create a file given .sh as the extension  (vi synctime.sh)
  • Add below into the created file. (This loop runs 120 times. System is syncing time to time server every 6 hours.)

for i in {1..120}
do
  sudo ntpdate sltime.org
  sleep 6h
done

  • Give execute permission to 'synctime.sh' file created before. 
  • Run the shell script in background.
./synctime.sh &

When I searched I also came across below blog post which I think is a better approach. Also check that our :)

http://www.cyberciti.biz/faq/howto-install-ntp-to-synchronize-server-clock/
http://www.pool.ntp.org/zone/lk

Monday, April 4, 2016

How to troubleshoot SVN-Based Deployment Synchronizer issues in WSO2 products.

Observation

Recently when I was setting up a WSO2 API manager cluster which had publisher/store/key manager in a one node, gateway manager and gateway worker node having clustering and SVN-Based Deployment Synchronizer [1] enabled. The issue I faced was even though all my nodes started with no errors after publishing an API my API invocation failed with below error message in the carbon log of gateway worker node. 

[2015-09-16 17:36:29,279]  INFO - LogMediator STATUS = Message dispatched to the main sequence. Invalid URL., RESOURCE = /api1/1.0.0/customerservice/customers/123

Possible cause of the issue

  • This issue can occur when synapse configuration of the particular API is not in the /repository/deployment/server/synapse-configs/default/api synapse folder of the worker nodes. 

How to troubleshoot Deployment synchronisation issues 

1. Check /repository/deployment/server/synapse-configs/default/api folder for the API synapse config in each of the worker node.

If you cannot find the synapse config in the specified location there should something wrong with the deployment synchronisation.

As the next step you can check whether particular synapse file is in the SVN server repo. (URL of the SVN repo should be configured in 'DeploymentSynchronizer' section in _repository/conf/carbon.xml file in gateway worker nodes as well as gateway manager nodes.)

What configurations I should check?

Scenario 01 : Say you can see the synapse files in svn server location but not inside /repository/deployment/server/synapse-configs/default/api folder of the worker node

This means your manager node is successfully committing configurations into the SVN location yet worker nodes does not checkout the files.

This can happen due to incorrect configuration in 'DeploymentSynchronizer' section in  /repository/conf/carbon.xml file in gateway worker nodes. In the worker nodes make sure you have set 'AutoCommit' parameter to false and 'AutoCheckout' parameter to true.

Scenario 02 : Say configuration files are not committed to svn server location.

This means gateway manager node is not doing his work of committing artefact to the svn location.

This can happen due to incorrect configuration in 'DeploymentSynchronizer' section in /repository/conf/carbon.xml file in gateway manager node. In the manager node make sure you have set both  'AutoCommit' parameter and 'AutoCheckout' parameter to true.

For more information please refer to [1].

Note: 
Another possible reason for svn based deployment synchronization to not work is that your cluster is not configured properly. Normally when gateway manager commits an artifact to svn server location a cluster message is sent to worker nodes and once it is received workers check out the changes from the svn location. If everything is working fine, relevant messages should get printed on carbon logs of gateway manager and workers.

If you cannot see these messages check clustering configurations done under clustering section of the /repository/conf/axis2/axis2.xml file in all three nodes.  Verify that you have given the same domain name in all nodes and defined well known members correctly in the member section.

[1] https://docs.wso2.com/display/CLUSTER420/SVN-Based+Deployment+Synchronizer